IDempiere/FullMeeting20121024

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2012-10-24

CarlosRuiz: Good morning
nmicoud: Bonjour
CarlosRuiz: Nicolas - I created the peer review status on JIRA
CarlosRuiz: and created this search
CarlosRuiz: http://jira.idempiere.com/secure/IssueNavigator.jspa?mode=hide&requestId=10300
nmicoud: Fine
nmicoud: That will be clearer
CarlosRuiz: will try today to review fixed assets
nmicoud: ok, if you got some times, could you please have a look at http://jira.idempiere.com/browse/IDEMPIERE-463 ?
Edwin_Ang: hi everyone
CarlosRuiz: ah yes - I have seen that problem with Table reference
CarlosRuiz: Hi Edwin_Ang
nmicoud: Hi
CarlosRuiz: with references you just can display Name and there is a checkbox for Value
nmicoud: you can choose what column to show (Name, DocumentNo, ...) and only a checkbox for Value
nmicoud: Maybe adding a new checkbox to say "Show identifiers" or if ID is selected, show table identiers
CarlosRuiz: yes - I don't like that
CarlosRuiz: :-) was thinking the same - flag to "Show identifier"
hengsin: nmicoud, "Display=C_Invoice_ID" so it only show ID
CarlosRuiz: hmm - the ID also sounds ok - as that's usually how an ID is shown
nmicoud: yes
nmicoud: for hengsin and carlos
CarlosRuiz: just made some tests on demo.idempiere.com - effectively choosing the ID - shows just the ID :-) as expected
nmicoud: :d
CarlosRuiz: I guess that sounds like a good approach - ID shows the identifier
CarlosRuiz: Edwin_Ang, how are things going with the M_Storage changes?
Edwin_Ang: to be honest i haven't made any good progress
Edwin_Ang: i am not very sure with the design yet
Edwin_Ang: currently, i believe that the issue is only with qtyreserved
Edwin_Ang: even if we don't drop M_Storage it won't be any issue
Edwin_Ang: what we should do is take out qtyordered and qtyreserved and find a place for both
CarlosRuiz: yes - M_StorageReservation
Edwin_Ang: qtyordered won't present any issue, even if we just use sum(qtyordered) from c_orderline, it should be of no issue
CarlosRuiz: yes - most of the problems are on sales
CarlosRuiz: but still don't get what is the design doubt
Edwin_Ang: test
Edwin_Ang: sorry, connection problem
CarlosRuiz: np - I was saying that "still don't get what is the design doubt"
Edwin_Ang: well last week, hengsin told me that product reservation must really mean that: those products are "claimed"
Edwin_Ang: they cannot be transacted by other document
Edwin_Ang: do we agree with that?
CarlosRuiz: partially - there are still rules to "Force" using inventory
CarlosRuiz: but yes - that's the idea of reservation
red1: i think previously 'availability' was more important
red1: reservation need not be tightly 'reserved' but still open to be taken by a confirmed SO
red1: that means if reservation = 3, available = 2. Then an SO will make it res = 2 available = 2
red1: sorry i think its res = 3 .. available = 1
red1: available is more important category to watch
Edwin_Ang: well.. if you put in on a user's perspective
Edwin_Ang: let say i am the user
Edwin_Ang: i have successfully reserved 1 unit of item X
Edwin_Ang: but then, the warehouse staff told me that they are out of stock
Edwin_Ang: because some other guy has put one big order and rushed to the warehouse to take those items
Edwin_Ang: then what is the meaning of reservation?
CarlosRuiz: I think standard orders don't allow the other guy to reserve more than available
CarlosRuiz: but the force rule - and other types of orders can override that check
Edwin_Ang: ow, sorry wrong case.. trying to remember past cases :D
Edwin_Ang: how bout if the other guy move those items to another warehouse?
CarlosRuiz: yep - movements and internal use are not checking reservations
fjvr: Movement between warehouse should use reserve
CarlosRuiz: but we can add that in a future step - trying to keep it simple on this first step
Edwin_Ang: actually i want to do as you suggest - keep it simple on the first step
fjvr: Ticket ID-385 says that the table is locking up. What does that mean and how can it be recreated?
Edwin_Ang: but then if movement or internal use should check reservation then M_StorageReservation should have M_Locator_ID
Edwin_Ang: and the query will be very different from only using M_Warehouse_ID
CarlosRuiz: I think in future movement and internal use could check reservation at warehouse level
CarlosRuiz: so, you can move items within your warehouse - but not out
CarlosRuiz: sorry - that's for movement :-)
CarlosRuiz: internal use must check in future at warehouse level too - to avoid negative availability on a warehouse
Edwin_Ang: why do you prefer check at warehouse level than locator?
Edwin_Ang: i think the issue with IDEMPIERE-385 is because reservation and onhand is on the same table
Edwin_Ang: somehow i see the relation between storage and reservation is one to many
CarlosRuiz: in most cases - at reservation time you don't know (and don't need to know) which locator will attend the shipping
CarlosRuiz: and indeed what happens on idempiere (since compiere times) is that you put the reservation on a locator - and then attend the shipping with a different locator
CarlosRuiz: leading to those confusing negatives
Edwin_Ang: yes.. in case of sales order, i agree with you
Edwin_Ang: that's why i agree with the addition of M_ReserveLocator_ID on M_Warehouse
Edwin_Ang: to serve this purpose
Edwin_Ang: but for movement and internal use?
CarlosRuiz: ah - I see you already committed code for this on your repository :-)
Edwin_Ang: just partial work
CarlosRuiz: movement and internal use - can check in future that the global warehouse availability for a product cannot be negative
Edwin_Ang: well.. then how do we calculate qtyavailable for this case: 1 warehouse have 2 locators
Edwin_Ang: locator A have 30 units of product X, locator B have 20 units of product X
Edwin_Ang: reservation is 15 units of product X
Edwin_Ang: what is the qtyavailable for locator A and locator B?
fjvr: jeje
CarlosRuiz: what is the qtyavailable for warehouse? -> 35
CarlosRuiz: so - suppose we implement this in future - if you try to consume (internal use) 16 items - that will error
CarlosRuiz: same if you try to move 16 items out of that warehouse
CarlosRuiz: but you can be allowed to move 16 items from locator B to A without problem
CarlosRuiz: in the end - availability per locator is useless - we're adding M_ReserveLocator_ID just as backward compatibility on reports - but is unnecessary
Edwin_Ang: you mean 36 or 16?
CarlosRuiz: ah yes - I made all the calcs as if reserv=35 :-) sorry
hengsin: availability per locator is too fine grained in practise - you just need to make sure you don't oversell what is in your warehouse.
hengsin: i means most of the time that's what the user want. so to keep it simple at least initially, we should only cater for this.
Edwin_Ang: ok, if there is no qtyavailable at locator level then i am ok with it
Edwin_Ang: and hengsin, i would like to ask you about that forUpdate() method
Edwin_Ang: it is not implemented in adempiere361, so i just get it from idempiere
Edwin_Ang: is there any downside of this locking?
Edwin_Ang: and how should i set the timeout parameter?
hengsin: you need locking to ensure you are not working with stale data.
hengsin: Edwin_Ang, you means what should the appropriate value for timeout ?
Edwin_Ang: yes, what is the appropriate value?
Edwin_Ang: i am seeming many places need these kind of locks.. open balance, bank account balance, storage, reservation
fjvr: What is the effect of a lock?
hengsin: so that people can't change it while you use the number to perform calculation
fjvr: Ah, gotcha, ok, understood
hengsin: Edwin_Ang, we can try with 30 seconds but that's usually something you need to fine tune for your production site.
fjvr: Definately if a document is complete you should not be able to change. Maybe even if it is in the prepared state you should not be able to change it.
Edwin_Ang: so, this should be parameterized?
Edwin_Ang: like a sysconfig parameter?
CarlosRuiz: that timeout is to give up if it cannot get the lock
CarlosRuiz: Edwin_Ang, do you have the URL where I can get your published Fixed Assets manual?
CarlosRuiz: I think you posted that on forums but cannot get it
Edwin_Ang: a moment pls
CarlosRuiz: ah - found it
CarlosRuiz: https://bitbucket.org/edwin_ang/fixed_assets/downloads
fjvr: Good writing style btw. It is an enjoyable read.
hengsin: Edwin, yes, good to make that a sysconfig parameter.
fjvr: The idea of the assets emerging out of projects was very good and definately a must.
Edwin_Ang: @fjvr: thx for the compliment :)
Edwin_Ang: so the timeout does not control the lock?
Edwin_Ang: the lock is automatically released at what event?
hengsin: commit or rollback
fjvr: good bye fellows, have a good day/afternoon or night !
Edwin_Ang: i see
Edwin_Ang: so just executing save() should do that rite?
CarlosRuiz: no - when committing the trx
CarlosRuiz: if is out of trx (trx=null) then save do the commit
Edwin_Ang: i see
Edwin_Ang: any reason why forUpdate() is not committed to 361?
Edwin_Ang: cos i think it is critical
CarlosRuiz: is not backported
CarlosRuiz: there are many improvements on idempiere that have not been backported - and no plans to do that
CarlosRuiz: but I see you integrated forUpdate in your branch - so - you're backporting it
Edwin_Ang: yes
Edwin_Ang: and actually i want to propose that 361 being released as iDempiere 1.0
Edwin_Ang: the current iDempiere as iDempiere 2.0
nmicoud: gtg, bye bye
CarlosRuiz: thanks Nicolas
Edwin_Ang: is it possible to do so?
CarlosRuiz: I think the two project are too different - 361 is more like an Adempiere-Transition than an iDempiere by itself
CarlosRuiz: so IMHO it would be confusing
red1: Edwin_Ang: on another matter, the FA.. are you going to release the changes as 2Pack?
red1: if so i can help make it into a plugin for iDempiere
red1: then we can see the benefit of OSGi in action
red1: but your DB changes should not alter core tables or remove any field
Edwin_Ang: i think FA should be included in the core
CarlosRuiz: red1 - the plan is to integrate FA in core
red1: yes.. but the idea is as a modular plugin rite?
red1: so if that is the case (in core) i guess the DB changes can be permanent
red1: that will make it a core plugin
Edwin_Ang: @Carlos: but you should think of a solution for the existing installations
red1: i was thinking of a more transient plugin where other FA plugins can interchange later
Edwin_Ang: iDempiere is a major change
Edwin_Ang: and many new users are still trapped with 370
Edwin_Ang: only developers know how to find 361
CarlosRuiz: Edwin - we could try to make a "final" release of 361 if that ease things for some people
Edwin_Ang: and that final release will be named as adempiere of idempiere?
CarlosRuiz: I would call that Adempiere-Transition
CarlosRuiz: I'm not too concerned about people that chose 370 - is their choice - and our goal is not to kill adempiere :-)
CarlosRuiz: good if people have choices
Edwin_Ang: many choose because lack of knowledge
Edwin_Ang: it is good if we can do them a favor
Edwin_Ang: being able to choose a stable product to use rite?
CarlosRuiz: I would say more like "lack of marketing" from our side :-) but I'm not interested on doing that - it would be for community to share such knowledge on forums
Edwin_Ang: we can do that.. but we need a tag release for that
Edwin_Ang: not everyone should learn mercurial :D
CarlosRuiz: that's the good thing about recent red1's work
CarlosRuiz: but yes - I understand your concerns
Edwin_Ang: yes.. red1's windows installer is a very good thing
Edwin_Ang: but we still need that tag release
CarlosRuiz: I'm trying to avoid politics on this weekly meeting space - so I would just suggest - be happy that you have the knowledge about what is happening - share that knowledge if possible - and be patient ;-)
Edwin_Ang: it is better for community building
CarlosRuiz: hehehe - partially joking there - I hope you understand
Edwin_Ang: no.. don't get it wrong. this is not politics
Edwin_Ang: i don't like that thing too
CarlosRuiz: anyways - I think we're close to tag a first release
CarlosRuiz: or better for a first preview release
CarlosRuiz: the biggest changes I think are done - so is worthy to work on that
CarlosRuiz: another thing that we want to implement (suggestion from hengsin) is to stop reserving the migration numbers - and use a datetime prefix instead
CarlosRuiz: that would be applicable after the first release
Edwin_Ang: and what is your plan for 361 after the first release?
CarlosRuiz: just bug fixes
Edwin_Ang: bug fixes are enough
CarlosRuiz: although 361 can serve for some time for the purpose of receiving contributions from people that still haven't migrated (it is serving such purpose actually)
Edwin_Ang: it is still the most stable version
Edwin_Ang: and existing installation won't migrate very soon to the new iDempiere
Edwin_Ang: because there are too many major changes
CarlosRuiz: yep - sure there will be a long transition time - that's why some bug fixes maintenance is important
CarlosRuiz: if you call something LTS - the idea is to provide support - not just tag something 370LTS and do not provide any patch ;-)
CarlosRuiz: ah sorry - 370 is just an example I could have said 978 - hehehe
CarlosRuiz: Edwin_Ang, I already merged your FA commits - and I'm in the process of reviewing - thanks a lot for that work
Edwin_Ang: ah.. i won't comment on that :D
CarlosRuiz: thanks everybody for attending the meeting - I need to move out for a while
Edwin_Ang: ok
Edwin_Ang: i got to go too
Edwin_Ang: thanks for the meeting
Edwin_Ang: bye everyone