CC Meeting Full 20070403
teo_sarca: hello all
vpj-cd: Hello
vpj-cd: Teo
croo: hi Teo, Victor
vpj-cd: hi croo
* CarlosRuiz (n=Carlos@200.118.214.233) has joined #adempiere-team
* vpj-cd_ (n=Horus@erp.sismode.com) has joined #adempiere-team
* vpj-cd has quit (Read error: 113 (No route to host))
teo_sarca: hi colin
* croo_ has quit (Read error: 110 (Connection timed out))
croo: hi teo ... is that new RFE for GL distrbution different to the one to select summary accounts? looks different just wondering if i misunderstood the first :)
teo_sarca: hi croo , that is another RFE
teo_sarca: there are 2 RFE about GL Distribution
croo: ok ... looks like a good idea that
croo: although the original post does act as a reference .... a log of what the original post was ... just in case there are issues with it's distribution
teo_sarca: but these are 2 different RFEs
teo_sarca: IMHO they have nothing in common
croo: i was talking of the replace
croo: well they were both about GL distribution!
teo_sarca: ah! ok
teo_sarca: What you think about:
teo_sarca: https://sourceforge.net/tracker/index.php?func=detail&aid=1675490&group_id=176962&atid=879335
teo_sarca: https://sourceforge.net/tracker/index.php?func=detail&aid=1670025&group_id=176962&atid=879335
teo_sarca: btw, CarlosRuiz AYT ?
CarlosRuiz: yes?
teo_sarca: CarlosRuiz, what you think about the previous FRs ?
teo_sarca: [17:53] <teo_sarca> https://sourceforge.net/tracker/index.php?func=detail&aid=1675490&group_id=176962&atid=879335
teo_sarca: [17:53] <teo_sarca> https://sourceforge.net/tracker/index.php?func=detail&aid=1670025&group_id=176962&atid=879335
croo: teo, to be honest I don't know a whole lot about the modelValidator but on the face of it they look like reasonable enhacements.
croo: i can see how they would be useful!
CarlosRuiz: Teo, are you considering backward compatibility, I mean is better not to change (or at least preserve) the old names of previous events
CarlosRuiz: I duplicated some of the "names" on the document events in order to preserve backward compatibility
teo_sarca: i did not change them
teo_sarca: i just added new ones
CarlosRuiz: ok, looks good, I saw your changes on PO
teo_sarca: ok
teo_sarca: and the other FE ?
teo_sarca: FR?
CarlosRuiz: do you mean for "personalized" preferences?
CarlosRuiz: or what is intended for?
teo_sarca: yes
teo_sarca: https://sourceforge.net/tracker/index.php?func=detail&aid=1670025&group_id=176962&atid=879335
teo_sarca: In ModelValidator we need a method that will be called after the
teo_sarca: preferences are loaded (org.compiere.util.Login.loadPreferences).
teo_sarca: This will let you to do specific tasks or to add specific variables to
teo_sarca: context, based on current context.
vpj-cd_: ok we can start?
CarlosRuiz: just trying to understand, in after login the current context is still not set? but in after load preferences it is
teo_sarca: it lets you the posibility to add custom context variables, after all is loaded
teo_sarca: fo example
teo_sarca: for
CarlosRuiz: croo, teo_sarca, vpj-cd_ , Deathmeatn, jsSolutions : ok, if you want we can start the meeting
croo: ok with me
teo_sarca: ok
CarlosRuiz: ok, I just have one theme - if you have more please just mention it :-)
CarlosRuiz: my theme is about the strategy of releasing 3.2
vpj-cd_: ok
teo_sarca: k
CarlosRuiz: we were talking with Heng Sin about this the other day
CarlosRuiz: and we thought that maybe we're committing a mistake
CarlosRuiz: because it can be priority 9 bugs that nobody needs because functionality is not used
vpj-cd_: yes I think need to solve
CarlosRuiz: and it could be priority 3 bugs with high impact because is a functionality widely used
vpj-cd_: the cash issue
vpj-cd_: and allocation issue
CarlosRuiz: so, maybe the prioritization table could take account of this variable (I mean if functionality is big impact)
CarlosRuiz: I think the specific issue was related with costing
croo: yes I was thinking the same .... those project level 9s for example ... i wonder if they are really core and certainly no worth holding up the project for. Even some 1s can be very annoying and better resolved
croo: well costing is pretty core .. I wouldnt like to see serious costing bugs in the stable release
CarlosRuiz: looks like there are big problems with average costing, but most people is using standard costing
croo: there will be some no matter what I guess but
teo_sarca: i use FIFO...
croo: ok but then those problem areas not considered "used" should be marked beta
croo: ?
croo: at least someone would know when the selected it
croo: most peopel for example ar using standard cost because until recently that was the only option!
CarlosRuiz: in fact I think costing methods different from standard can have big issues to be used in production :-(
croo: well to be honest I intended to use standard cost... there is a lot of testing before I would have confidence
croo: but I thoght hengsin addressed those average PO costing issues ... they look good to me know?
CarlosRuiz: I think the best would be to have a page with "Known issues" and "Beta functionalities"
croo: ok
CarlosRuiz: Colin, the problem I see with average PO is that there is no a mechanism to repeat the costing with same results
croo: there might not be much left though :)
croo: oh this is the issue of when the postings happen .... yeah I spoke with hengsiin about that too
croo: actually .. while testing the other problems
CarlosRuiz: yes, if you repost an accounting period or even some documents, I think the costing can become a mess
vpj-cd_: wnat is issue with AVG cost?
croo: i found that if you did a "reset accounting" it worked out correct ... but you couldn;t do that!
* trifon (n=Trifon@home-213-240-227-143.megalan.bg) has joined #adempiere-team
CarlosRuiz: because the order of posting the documents is important
vpj-cd_: are caculate bad the result
croo: but perhaps the workflow could be changed to ensure certain steps only happen after others!
CarlosRuiz: but is not only the order in documents
CarlosRuiz: is also about the order of posting on documents of the same type
CarlosRuiz: combined with posting on documents of different type, this is messy
CarlosRuiz: in other words, m y conclusion looking this problem is that average costing can work while you don't make a repost (or reset as you pointed)
croo: yes.. but there were problems
CarlosRuiz: if you repost or reset the results of accounting can be big different
vpj-cd_: haaa
croo: but perhaps that is accepted with average costings .... I don't know to be honest
croo: yes the order in which you post makes a difference
croo: and when you reset you will most likely get a different number
croo: i'd need to look at my notes ... which I posted to some bug report
CarlosRuiz: ok, so must we declare average costing as beta???
croo: but other systems do it so there must be a way of doing this
vpj-cd_: croo the isse with AVG cost is
CarlosRuiz: in last compiere manual they state that
croo: for now yes I think so
vpj-cd_: because lost the average when you repost
vpj-cd_: what do you think you only have to only elemnt of materia in standard cost
vpj-cd_: what happen if I need have another element
croo: I'm just saying that when (and in which order) you process the documents can effect the CoGs figures
* AFalcone (n=AFalcone@190.49.102.132) has joined #adempiere-team
AFalcone: Hi all
croo: so sales are made with non-correct calculations of CogS because not all docs have been processeed
AFalcone: do we have meet today?
jsSolutions: no matter what, cogs is messed up in a repost, right?
jsSolutions: for anything where the cost has changed
jsSolutions: over time
jsSolutions: it's not a standard/avg cost issue
jsSolutions: because it can be true with standard cost
jsSolutions: hi alejandro :-)
AFalcone: hi Joel
croo: yes well the most basic avg costing does not work out the same ....
croo: it may ... but then again it may not ...
croo: it depends on when the accounting processor runs
croo: brb
jsSolutions: really, to be right, the cost records need validity dates
jsSolutions: start and end
jsSolutions: with no overlap allowed
jsSolutions: then you could recreate the cost
jsSolutions: but very hard to work with
vpj-cd_: the avegage cost and fifo should canculate from tier of cost
jsSolutions: seems like we turned the cc meeting into FR meeting :-)
vpj-cd_: in the standard cost adempiere should take also another element
vpj-cd_: the feature the use element no is use in standard cost
vpj-cd_: only to land cost
vpj-cd_: landent cost
CarlosRuiz: Joel is right, but at least standard costing give closer management to the accountant
CarlosRuiz: so he could "play" with the costs while reposting
jsSolutions: in some ways, i have thought it would be better that the system only use Standard Costing to post
jsSolutions: and that the accountant
jsSolutions: has tools to compare the AVG costs
jsSolutions: and update before posting
jsSolutions: as Victor says, you could add elements
jsSolutions: like shipping automatically
croo: i think the problem is costing has become an accounting processor process while it should be a realtime calc, i.e. not done in batch
CarlosRuiz: as part of complete workflow?
croo: not sure yet ... i did't give it that much thought yet, but the issue I found were related to WHEN the different docs were processed
croo: if I shipped something before I processed (in Accounting terms) the PO, receipt & Invoice then I could get different values for average cost
CarlosRuiz: so, returning to the original discussion :-) we must declare costing different from standard as beta
croo: yes .. I think so
croo: but is the NEW standard cost well tested? :)
croo: by new I mean since 253
CarlosRuiz: not sure, I just saw that old costing is marked as deprecate, but tables are still being filled
* teo_sarca has quit (Read error: 104 (Connection reset by peer))
CarlosRuiz: so, do you agree with the strategy change?
croo: yes
croo: otherwise we never get to stable
jsSolutions: (y)
CarlosRuiz: and how could we manage that?
CarlosRuiz: maybe priority is not the solution, or we can change the priority table
croo: well if the functionality is beta it's not a 9 ... but 3 asthe work around is don't use it!
CarlosRuiz: or we could use "Group" field on bugs for the purpose of marking impact
croo: a "beta" group
CarlosRuiz: I think even you can have type "9" bugs on non-beta functionalities, but impact very low
CarlosRuiz: or even impact defined on a project basis
CarlosRuiz: if a specific project don't use the webstore, then bugs on webstore are unsignificant for them
* teo_sarca_ (n=teo_sarc@89.137.176.152) has joined #adempiere-team
croo: ok so non-beta and core functionality
croo: =9
CarlosRuiz: even if you have a 9 webstore bug, that version will be "stable" for those projects not using webstore
croo: core being the Quote->Invoice,Req->Invoice,OpenItems,Material, Performance Analysis
croo: ?
CarlosRuiz: I think maybe we could keep the current prioritization table
CarlosRuiz: but not state that stable release is a non-9 bugs
CarlosRuiz: I think depending on the bugs
CarlosRuiz: we could release a stable release with known issues
croo: ok so the bug remains 9
CarlosRuiz: most software houses do that
croo: but only core-9 bugs stop a stable release?
croo: ok with me
CarlosRuiz: yes, definitely there are showstoppers
CarlosRuiz: but normally those are solved immediately
croo: well I think this first release is a little unusual as we are still debugging really.... our foundation has foudn to be wanting
CarlosRuiz: more opinions about this? AFalcone? DeathMeat? jsSolutions? teo_sarca_? trifon? vpj-cd_?
jsSolutions: sounds reasonable to me
trifon: about what?
croo: :)
croo: what defines a stable release
trifon: for me it is just a matter of saying...
trifon: there is no stable release
trifon: we can consider some release for stable.
croo: there is no release with zero bugs but is our 3.1.6 more stable than 2.5.3a?
trifon: yes, definately.
AFalcone: yes, sure
vpj-cd_: yes , very very stable
croo: so at what point is good to say we have done enough ... this version is useable
croo: is the question carlos asks
vpj-cd_: I think only need solve the issue with payment
vpj-cd_: and cash jounral is very very stable
trifon: we have free migratoin so our users can migrate to any future version. That's why i think that it is not so important for us to pay so much attentionh to stable/unstable.
trifon: if all agree and are happy with curent version then we can make it.
CarlosRuiz: Trifon, I think people always need to know the "status" of a version
CarlosRuiz: when we release we must say if it's "production ready", "unstable", "just for testing" - etc
jsSolutions: the proposal is that we will not aannounce a release that has level 9 bugs in core functionality?
trifon: i like more frequent issuing of new version then stbale/unstable, but this is just my opinion.
trifon: ok. i agree with both.
CarlosRuiz: Joel, it depends so much on the bug type
croo: and I think upgrading an ERP is something nobody wants to do ... it's a risky business. i doubt you will not see companies upgrading every months, or even every 3 months ... one a year I would say.
AFalcone: How many bugs with level 9 we have now?
CarlosRuiz: yes, 1 a year is most used
CarlosRuiz: 15 -> http://sourceforge.net/search/index.php?group_id=176962&words=group_artifact_id%3A%28879332%29+AND+priority%3A%289%29+AND+status_id%3A%281%29&type_of_search=artifact&pmode=0&limit=15
croo: joel, yes that was the original plan. no level 9s
croo: no we have proposed no level 9s in core functionality
croo: but some functionality is declared beta ... such as costings other than standard
croo: no=now
croo: AFalcone, 14 level 9s
croo: 15
croo: :)
AFalcone: ok, and how many of them are difficult to solve?
jsSolutions: it would be good to have some standard, but then CC can choose to release with exceptions
CarlosRuiz: but there are points in discussion there too
CarlosRuiz: i.e. I put 9 for a report that is showing problems in spanish
CarlosRuiz: but I'm not sure if a report is a priority 9
CarlosRuiz: a report always have a workaround and is not core, is not damaging data
AFalcone: i agree
croo: well to a great extent Trifon, is correct that we are our own boss... the rules are guidelines ... if we feel that a level 9 shouldn't hold back the release then we can just choose to release anyway!
croo: level 9 reports - well if someone deemed it a necessary report. say for example the invoice printing didn't work ... that's a report of a type but you woldn't want to release with a problem in it
croo: not sure about the report you mention ...
jsSolutions: one nice thing about a standard like 'no level 9s' is the visibility
croo: yes
jsSolutions: to all the developers to try to rally around a release goal
croo: and to would be users!
croo: that's why I suggested originally downgrading! :) a problem in beta is not 9 :)
croo: but now 9 means there is no work around in the app ... so i think it's better to keep the 9
teo_sarca_: (ok, i will need to go, but i will let my computer open to record this chat, bye bye)
croo: what about the group type beta ... we leave the 9 but place the bug in a special beta group (i.e. instead of 3.1.6 or whatever)
croo: bye teo
AFalcone: bye teo
croo: I guess it all depends on the effort required to fix it too!
CarlosRuiz: yes, definitely there are reports critical, and reports that can be considered just as presentation :-)
CarlosRuiz: about the group
CarlosRuiz: yes, really the version number is not adding value to the management of bugs
CarlosRuiz: and lastly Group is not being filled
CarlosRuiz: so we can think on a better usage for Group field
CarlosRuiz: maybe impact?
CarlosRuiz: beta, core, presentation
CarlosRuiz: module specific
croo: well modules can be the category
croo: plus we also have the data type field
croo: well actually its used
AFalcone: yes, I thing this way is a better organization
CarlosRuiz: ok, so how can we manage the Group? ideas?
vpj-cd_: I sorry Carlos
vpj-cd_: what is idea with field group?
CarlosRuiz: to change from version to something like impact
CarlosRuiz: I think we can start with Beta, Core, Report
croo: so all non-core are considerd beta then?
CarlosRuiz: and "Module Specific"
CarlosRuiz: if Module Specific, the affected module is marked in Category
croo: ok yes good idea
AFalcone: i agree too
croo: ok so stable release policy is all priority 9s in core
CarlosRuiz: good :-) do you have other themes that you want to discuss?
croo: fixed
CarlosRuiz: yes, agree
AFalcone: yes Colin, I thing so
croo: we will need to review all existing bugs and set their new group :(
CarlosRuiz: at least priority 9 bugs
croo: yes good point :)
AFalcone: yes Carlos, all level 9 in core
vpj-cd_: yes I agree
vpj-cd_: 9 is core
AFalcone: nop, 9 IN core
AFalcone: :)
croo: the category has currently many many entries ... should we reduce to a smaller list?
CarlosRuiz: Ready, groups added
croo: Sales, Purchases, Inventory, Manufacturing, Finance, WebStore, etc
CarlosRuiz: yes, I think a list by module will be better
AFalcone: yes the category list is very extensive now
croo: ok I'll reduce it to the basic modules perhaps with one or two technical like persistence
croo: we can then add to it if need be
AFalcone: and many of them are overlaped by functionality
croo: hopefully we can delete
AFalcone: Colin, don't forget to mantain the Posterita categority
CarlosRuiz: no, it can't be deleted :-(
croo: damn
AFalcone: :)
AFalcone: hehe
CarlosRuiz: posterita have an independent data type
CarlosRuiz: libero too
AFalcone: and postgres?
CarlosRuiz: no, postgres is core, it is a category
AFalcone: ups, sorry
croo: that means we can't get rid of te version numbers for the group either ... that's a real pain
CarlosRuiz: ok, Victor, are you going to add the column to Accounting Schema for "allow negative posting" ?
CarlosRuiz: I think is a good option, I would recommend to discuss solutions in forums before being implemented
CarlosRuiz: discussion and ideas for implementations of fixings are very enriched when posted in forums
croo: yes irc is two small a time window for all to comment
trifon: yes sf.net is the best.
croo: also I think it would be a good rule of thumb that changes are always adding never removing .... that way there is compatibility
trifon: i preffer to see discussion prior actions
CarlosRuiz: agree both opinions
vpj-cd_: yes Carlos
vpj-cd_: I am agree
vpj-cd_: I need you help to add new element to AD
vpj-cd_: and set the id to this feature
CarlosRuiz: for 3.2? or after 3.2? what do you think?
croo: i think pre 3.2 .. some would consider negative posts a bug!
CarlosRuiz: ok Victor, I'll add the column/field and element to c_accountingschema
vpj-cd_: yes
CarlosRuiz: then you generate the model and add the code for that
CarlosRuiz: ok?
vpj-cd_: excellent
vpj-cd_: yes Carlos thanks
vpj-cd_: I need you sugestion about how need pach
vpj-cd_: the issue with cash journal
vpj-cd_: in this moment I have issue with the pach of Teo in tax
CarlosRuiz: yes Victor, I think is better to post in forums the discussion you had on IRC
vpj-cd_: with your pach I can no complete shipmnet and receipts
vpj-cd_: ok the I please I need your beed back
vpj-cd_: the problem with forum is
vpj-cd_: no all commnet
vpj-cd_: the bugs
croo: are we talking about the voiding of invoices paid in cash?
vpj-cd_: croo exisit severe issue
vpj-cd_: with journal cash
croo: yes I see that
croo: I think moyses answer is correct - you should not be able to cancel a paid invoice.
CarlosRuiz: Victor, the forums are needed, even if nobody answer is like an implicit agreement
CarlosRuiz: most of the reverts could be avoided if discussed previously on forums
vpj-cd_: but this in all the system
CarlosRuiz: IRC has very little visibility to be considered as discussed
vpj-cd_: when yoo have invoice paid
vpj-cd_: or a payment are into bank statement
CarlosRuiz: I agree to include the validations on the system, as we talked yesterday, but it's better to ventilate the issue in forums and wait for opinions one or two days
croo: ok are we done?
CarlosRuiz: I think so, thank you very much
CarlosRuiz: welcome again Colin to the CC, good to have your help
vpj-cd_: ok
vpj-cd_: I agree
vpj-cd_: I have problem with the pach the Teo
vpj-cd_: in tax
croo: thx carlos
CarlosRuiz: the second patch?
vpj-cd_: the current pach
vpj-cd_: the issue is try delete the tax
vpj-cd_: but fiald then return false and supend the transaction
vpj-cd_: here is the problemm
vpj-cd_: /**
vpj-cd_: * Recalculate order tax
vpj-cd_: * @param oldTax true if the old C_Tax_ID should be used
vpj-cd_: * @return true if success, false otherwise
vpj-cd_: *
vpj-cd_: * @author teo_sarca [ 1583825 ]
vpj-cd_: */
vpj-cd_: private boolean updateOrderTax(boolean oldTax) {
vpj-cd_: MOrderTax tax = MOrderTax.get (this, getPrecision(), oldTax, get_TrxName());
vpj-cd_: if (tax != null) {
vpj-cd_: if (!tax.calculateTaxFromLines())
vpj-cd_: return false;
vpj-cd_: if (tax.getTaxAmt().signum() != 0) {
vpj-cd_: if (!tax.save(get_TrxName()))
vpj-cd_: return false;
vpj-cd_: }
vpj-cd_: else {
vpj-cd_: if (!tax.is_new() && !tax.delete(false, get_TrxName()))
vpj-cd_: return false;
vpj-cd_: }
vpj-cd_: }
vpj-cd_: return true;
vpj-cd_: }
vpj-cd_: Sorry set this here
vpj-cd_: the issue is that try cancualte the tax
vpj-cd_: always you save the MOrder
vpj-cd_: this is a problem from shipment or receipt
vpj-cd_: always are execute this methos
vpj-cd_: updateOrderTax
croo: shipment & receipts update the ordertax??
* CarlosRui1 (n=Carlos@200.118.214.233) has joined #adempiere-team
vpj-cd_: yes
CarlosRui1: I got disconnected
vpj-cd_: with new pach of Teo
vpj-cd_: yes
vpj-cd_: I am review the code
vpj-cd_: he set private boolean updateOrderTax(boolean oldTax) {
vpj-cd_: this is call in aftersave
croo: ok .... well revert it and make an entry in the RFE or BUG report ... or just fix it and make an entry!
croo: I need to sync before I can test it
vpj-cd_: when you update receipt or shipment
vpj-cd_: the system save again the MOrder
vpj-cd_: then try recalculate
vpj-cd_: what revision?
CarlosRui1: but if reverted other bug arises
croo: aha with the qty delivered ... yes
CarlosRui1: because the teo patch was to solve other bug
croo: true ... looks like victor will have to fix it :)
vpj-cd_: I get 1925
vpj-cd_: I have stop now my customer :-(
vpj-cd_: in shipment
vpj-cd_: the issue is
vpj-cd_: this line
vpj-cd_: if (!tax.is_new() && !tax.delete(false, get_TrxName()))
vpj-cd_: the tax.delete return false
croo: looks like it would have been tricky to find !
vpj-cd_: then this methos return false
vpj-cd_: and workflow stop
CarlosRui1: why the tax.delete returns false?
CarlosRui1: where is that? MOrderLine?
vpj-cd_: yes
vpj-cd_: Carlos
CarlosRui1: hmmm, after calling tax.delete you must call also tax.save
vpj-cd_: line 910
vpj-cd_: the issue is do not force the tax.delete
vpj-cd_: if (!tax.is_new() && !tax.delete(false, get_TrxName()))
vpj-cd_: I change this to if (!tax.is_new() && !tax.delete(true, get_TrxName()))
vpj-cd_: and now are working
vpj-cd_: but is rigth that calculate always the tax
vpj-cd_: also when we make a shipment or receipt
vpj-cd_: ?
CarlosRui1: is not needed to call tax.save after tax.delete ?
vpj-cd_: I do not
vpj-cd_: Teo now recalculate tax
vpj-cd_: always you save orderline
vpj-cd_: when you update a shipment you update qty delibery
vpj-cd_: delivery
vpj-cd_: then you save the line and lautch calculatetax
vpj-cd_: again
vpj-cd_: I think this is error
croo: perhaps tax rules say the tax rate at the point of delivery of receipt is the tax that applies?
croo: imagine you enter an order for something and next month when the tax rates have changes you ship it!
croo: what tax rate should apply????
CarlosRui1: sounds strange, the force parameter on delete just return false if the record is Processed
vpj-cd_: yes
vpj-cd_: I noe change to force true
vpj-cd_: this way work fine
vpj-cd_: but my question
CarlosRui1: yes, but the record is processed when the order is completed, not?
vpj-cd_: yes
CarlosRui1: and if the order is completed, the taxes must not be changed, not?
vpj-cd_: but with false this fiald
vpj-cd_: faild and the workflow stop
croo: i guess at the end of the day it;s the invoice tax that is important!
vpj-cd_: yes I think is rigth
CarlosRui1: is replicable in GardenWorld?
vpj-cd_: no but I am use the standard version
* CarlosRuiz has quit (Read error: 110 (Connection timed out))
* CarlosRui1 is now known as CarlosRuiz
CarlosRuiz: why can't be replicated in GW? have you customized workflow?
vpj-cd_: no
vpj-cd_: Carllos is standard
vpj-cd_: I propoause this
vpj-cd_: cahnge in after save
vpj-cd_: / Recalculate Tax for old Tax
vpj-cd_: if(m_parent.getDocStatus()!=MOrder.DOCACTION_Complete)
vpj-cd_: if (!updateOrderTax(true))
vpj-cd_: Waht do you think?
* jsSolutions (n=jsSoluti@ip72-197-81-229.sd.sd.cox.net) has left #adempiere-team
vpj-cd_: Sorrye // Recalculate Tax for old Tax
vpj-cd_: if(m_parent.getDocStatus()!=MOrder.DOCSTATUS_Completed)
vpj-cd_: if (!updateOrderTax(true))
vpj-cd_: return false;
vpj-cd_: What do you thnik?
CarlosRuiz: hmmm, I can't opine on a problem not understood
CarlosRuiz: it's very difficult if we can't replicate that in GW
CarlosRuiz: because it can be specific from your installation
croo: i think victor means he hasn't tested in GW ...is that correct victor?
croo: victor makethe change you need locally ... add to the bug report in SF and reopen.... then we can all test and review
croo: when fixed you can just sync with svn and overwrite yur local fix
CarlosRuiz: yes, and please put the whole test case, sales order -> shipment -> change xx in field xx
vpj-cd_: yes I have not in GW
vpj-cd_: yes Croo I have
vpj-cd_: revision 1925
vpj-cd_: to OrderLine
croo: ok
vpj-cd_: the issue is easy
vpj-cd_: the calculate methos no detect change in imp
vpj-cd_: then try exuecute Tax.delete but this is not force
vpj-cd_: then the method return
CarlosRuiz: not in code Victor, in business, where is the error triggered
CarlosRuiz: when you make what event?
CarlosRuiz: shipping a quantity lower than order?
vpj-cd_: I I try complete a shipment or receipt
CarlosRuiz: I just tested this and worked:
CarlosRuiz: Sales Order for Patio -> 5 Patio Chairs with tax CT Sales - complete
vpj-cd_: please you can make a receipt
vpj-cd_: yes try with a receipt
CarlosRuiz: then make a shipment for that sales order shipping just 3 chairs -> complete
vpj-cd_: is more easy
vpj-cd_: set a PO
vpj-cd_: yes but my shipment is manul
vpj-cd_: manual
vpj-cd_: I need create the shipmet use Shipmet(customer)
CarlosRuiz: I entered the doc Shipment (Customer)
vpj-cd_: manuality
vpj-cd_: yes
vpj-cd_: or you entry a receipt is same issue
CarlosRuiz: and completed without problems
vpj-cd_: and your test complete?
CarlosRuiz: yes, sales order completed ok, shipment customer completed ok shipping 3/5 chairs
CarlosRuiz: I'm making same test with PO
vpj-cd_: Carlos please
vpj-cd_: my sales is exent
vpj-cd_: the tax is %o iva
vpj-cd_: :-)
vpj-cd_: %0 iva
CarlosRuiz: PO was ok too, going to test with exempt
vpj-cd_: nad are working
CarlosRuiz: yes, error with tax Exempt
vpj-cd_: this my issue
vpj-cd_: now
vpj-cd_: :-)
vpj-cd_: the I may solve or set in tax.delete(true)
vpj-cd_: or with this logic
vpj-cd_: // Recalculate Tax for old Tax
vpj-cd_: if(m_parent.getDocStatus()!=MOrder.DOCSTATUS_Completed)
vpj-cd_: if (!updateOrderTax(true))
vpj-cd_: return false;
vpj-cd_: what is rigth?
CarlosRuiz: better look for the Processed flag
CarlosRuiz: if (!m_parent.IsProcessed()) -> updateOrderTax
CarlosRuiz: ok
vpj-cd_: ok
CarlosRuiz: Testing, ok, I think we can finish the meeting, Victor we can continue this issue on #adempiere
vpj-cd_: ok
vpj-cd_: yes
croo: one more point
croo: i'm just answering a question from someone on migration
croo: they have a binary version but the migration scripts are only available with from svn with source ... right?
CarlosRuiz: Compiere migration? which version?
croo: should be update the package build scripts to include the migrate scripts? would that be resonable
croo: 314->315
croo: or are they included already? I only use source so I assume they were not
CarlosRuiz: don't understand clearly
CarlosRuiz: but scripts must be applied manually, there is no a program that applies scripts (still)
croo: in the binary release there are no migration scripts include
CarlosRuiz: and yes, they must be downloaded from SVN, we're not packaging migration scripts (good point)
croo: you must manually checked them out
croo: I suggest it would be easier for people if we modify the packaging scripts to include the migration below utils seems like a ideas
croo: opps you got there before me :)
croo: yes that's what I meant
CarlosRuiz: yes, but as you pointed normally people wait for several versions to migrate
CarlosRuiz: so maybe we must include all migration scripts?
CarlosRuiz: or just some past versions?
croo: yes well we provide the whole migration directory
croo: they can then migrate from version to version .... it stillleaves lots of manual work
croo: but at least all the code is included
croo: yes ... again I didnt read your answer correctly
croo: yes i mean include the whole directory
croo: later we can make a better perhaps gui migration tool .. for now I think simply inlcuding the scripts is enough
CarlosRuiz: or we can package all of them and release it on migration packages on sf
croo: yes.. that too!
CarlosRuiz: some people asked to if we can release packaged sources
croo: and that 3 .... it will increase our SF ranking :)
CarlosRuiz: yep
CarlosRuiz: that will be easy, just zip file of migration directory :-)
croo: ok well that was it .... of course if we included it in the bbinary release we would just hav eto make some small changes to the build.xml and do no more ... we wouldn't hav eto remmber when a new version comes to make also a migration release
CarlosRuiz: thta's true, and for users, just one single download, although the size of .tar.gz is bigger everyday
CarlosRuiz: ok, Colin please open a FR with that
CarlosRuiz: "package migration scripts" - maybe we can add other for "package sources when releasing version"
CarlosRuiz: Colin or Victor, can you please send me the whole log after finishing? I got disconnected from a while
croo: ok carlos will do
