IDempiere/FullMeeting20120523

From WikiQSS
Revision as of 10:51, 23 May 2012 by CarlosRuiz (talk | contribs) (full meeting)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Table of Contents | Full Meeting Minutes | Full Meeting 2012-05-23

CarlosRuiz: Morning
Nicolas_: Hello
mzuniga_ergio: Hi Carlos
tbayen: Daarestiet!
hahmed: Hi Carlos
CarlosRuiz: Hi, I'll be checking some pending JIRA tickets - please feel free to interrupt at any moment
tbayen: How can I create a language pack from a working installation where I did my changes?
CarlosRuiz: you can export it using the option "translation import/export"
hahmed: CarlosRuiz: A minor ticket http://jira.idempiere.com/browse/IDEMPIERE-162 if you can review it, it can be closed
hahmed: and will also close related ticket http://jira.idempiere.com/browse/IDEMPIERE-66
tbayen: Hrmpf! Sorry for the stupid question. I really did not see that the same menu entry also exports... :-)
CarlosRuiz: good Hesham - will take a look to that one
CarlosRuiz: Hesham - I see you don't have centralized ID password - just let me know in case you want one assigned
hahmed: CarlosRuiz: It would be great to have it.
hahmed: I wanted to discuss an issue somewhat similar to http://jira.idempiere.com/browse/IDEMPIERE-235
hahmed: and also related to subscription
CarlosRuiz: ready, centralized ID password sent to your mailbox
hahmed: CarlosRuiz: thanks received already
CarlosRuiz: yes - we stopped the fix for IDEMPIERE-235 until we have more clarity - we found there are two options to solve it
hahmed: CarlosRuiz: well my requirement is not directly related to the issue but somewhat related
hahmed: I am starting work on new functionality for Shipment Schedule, similar to Invoice Schedule, it would require addition of a new table m_inoutschedule and a new tab to Sales Order Window
hahmed: also would require modification to Generate Shipment process
hahmed: the idea is to allow a single order line to be scheduled to ship according to shipment schedule
hahmed: very similar to invoice schedule
hahmed: this is very useful for any company working with subscriptions as subscriptions have a single orderline for multiple shipments, e.g. magazines
hahmed: also useful for companies that deal with very large quantity orders that are shipped over many days/weeks or even months
CarlosRuiz: sounds interesting
a42niem: hi Carlos, hi all
CarlosRuiz: actually you can do that - but you need to open several order lines with different delivery dates
hahmed: hi a42niem
CarlosRuiz: Hi Dirk
tbayen: Hi a42niem
hahmed: CarlosRuiz: yes but that is not a suitable option for subscriptions magazines, internet service etc. where a fixed price for yearly subscription is charged and shipments done over many months. It would be difficult to divide 9.99 by 12 for magazines for example
a42niem: i like to get some feedback concerning a customer request
a42niem: besides filed so_creditused they like to have another field where they can see the open order value
a42niem: does anyone find this of general interest?
a42niem: c_bpartner.so_creditused that is
a42niem: the sales process takes a lot of time before they send out the invoice and they want to know how much is open with the customer order-wise
CarlosRuiz: yes Hesham, your proposal sounds good, just pointing to one not very good alternative
hahmed: CarlosRuiz: I already have some very alpha work, so I will create a JIRA ticket and attach the work once its ready for testing
CarlosRuiz: Dirk - it sounds related to http://www.adempiere.com/FS01_Commitment_AR_AP
a42niem: ah ok, i have a look
CarlosRuiz: not a solution, just pointing to a similar case
CarlosRuiz: as you state - so_creditused is just for invoices, and you need to keep balance for open orders (similar to the need of that building company described in the FS)
CarlosRuiz: I think it can be general interest
a42niem: yes, i was just reading it, it is related somehow
a42niem: my first idea was to solve it with a table validation
CarlosRuiz: table validation?
a42niem: or should it be in the document processing?
CarlosRuiz: a new column for so_openorder ?
CarlosRuiz: sounds like must be affected when completing / closing / voiding sales orders
a42niem: the value must be recalculated whenever there is a change in doc state and when all or a part of the order has been invoiced
CarlosRuiz: and the "validate bpartner" process must take into account that also
a42niem: new column - yes
a42niem: and they want to see the value in the info line below the order
CarlosRuiz: so, your idea is that when invoiced the value moves from so_openorder to so_creditused ( subtract from first and add to second, right? )
a42niem: yes
a42niem: otherwise it would be calculated twice
CarlosRuiz: in such case you need to take into account also invoice completing / voiding to subtract/add the column
a42niem: yes, it needs kind of a callout which works in all these cases
a42niem: therefor my thinking of table validation or sth similar
CarlosRuiz: nope, sounds like on completeIt / reverse*It methods
CarlosRuiz: or in a document model validator in case we want it like an extension
a42niem: yes and no
a42niem: it is related to order complete/reverse/void and reopen
a42niem: and to whenever orderline is changed due to part of the line qty has been invoiced
a42niem: or the invoice voided
CarlosRuiz: ah, I see why you say table validator
CarlosRuiz: it's a formula sum ( (c_orderline.qtyordered - qtydelivered) * priceactual )
a42niem: plus taxes...
hahmed: a42niem: would it not be enough if its a computed field instead of a DB field using the formula Carlos mentioned
a42niem: hahmed yes i was thinking about that also
a42niem: makes it somehow easy to sum up all quantities which have not been invoiced and where the related order is in state CO
a42niem: mthat y feeling is just adding the correct taxes is easier in java
a42niem: mthat y = my
CarlosRuiz: for line taxes sounds ok
CarlosRuiz: but for doc taxes doesn't sound easy
a42niem: we are using doc taxes here
CarlosRuiz: so, you need to be careful when a line is partially invoiced, right?
a42niem: yes
a42niem: MInvoice.completeIt does orderline.setQtyInvoiced for all related orderlines. so orderline.afterSave could be a good place to trigger the recalculation of so_openorder WDYT?
CarlosRuiz: Hesham - tests for IDEMPIERE-162 went fine - excellent, thanks for the contribution
hahmed: CarlosRuiz: Welcome Carlos
CarlosRuiz: a42niem, yep - sounds fine
a42niem: great, thanks for your input, i will create a ticket then
CarlosRuiz: another option would be to add it as a model validator
a42niem: ahaa, that is what i called a table validation, sorry for the confusion
a42niem: my feeling was that model validator is mor for a customisation, not for core!?
CarlosRuiz: yes - or for extensions
CIA-101: iDempiere: globalqss * 77e46768d471 r7280 /migration/ (4 files in 4 dirs): IDEMPIERE-249: Moving files to correct folder
CIA-101: iDempiere: Hesham S. Ahmed * c53abbbc7033 r7281 / (4 files in 4 dirs):
CIA-101: iDempiere: IDEMPIERE-162 Let Process Role Access Update honor previous modifications to permissions
CIA-101: iDempiere: http://jira.idempiere.com/browse/IDEMPIERE-162
CIA-101: iDempiere: Peer reviewed, tested and integrated by Carlos Ruiz - globalqss
CIA-101: iDempiere: globalqss * 888de2559a41 r7282 /migration/360lts-release/ (2 files in 2 dirs): IDEMPIERE-249 Fix migration script
a42niem: ok, interesting idea, so i might create it as an extension, lets call it for example a42_openorder
a42niem: it contains a validator
a42niem: and whoever wants to use it has to use the related migration script to create table column and window field and enable the validator
a42niem: and i have to check if it always works with a new version and may have to provide different variants
a42niem: and there is a "market place" wher such extensions could be found
hahmed: a42niem: great idea, having a market for iDempiere extensions (and some mechanism within idempiere client to easily install extension packages)
CarlosRuiz: that's the goal with OSGi
tbayen: an App store like in android with free versions with integrated advertising and spyware would be nice.
tbayen: :-)
a42niem: :-D
CarlosRuiz: good opportunity for an antivirus :-D
a42niem: "get the new iDempiere. Now with AntiVirus extension"...
CarlosRuiz: HAHAHA
hahmed: and with the bragging right. iDempiere with 300,000+ extensions (e.g. extension to add Mr. title to BP)
CarlosRuiz: ala OpenERP :-)
tbayen: I would like to be the first one who writes a real idempiere Virus. It should multiply by sending an infected invoice to another idempiere-driven company.
tbayen: Don't tell red1 what we talked about last - he would destroy our business model and share free antivirus solutions.
tbayen: :-)
CarlosRuiz: free antivirus with advertising - every necessity is an opportunity :-D
CarlosRuiz: or like google - I give you free extensions - but I can read and analyze your data to give you better advertising :-D
hahmed: imagine getting advertisement from competing garden manufacturers to GardenWorld users
a42niem: tbayen: and then all your invoices are melting away like in the movie Disclosure
tbayen: We could keep advertising out of the free version if we use the ERP the right way. How about transfering every purchase discount to our bank account?
hahmed: tbayen: dangerous, can be traced back
hahmed: tbayen: maybe transfer every purchase discount to WU user in Nigeria
a42niem: but someone may peer review my code and detect the virus i have planted
a42niem: who can texh me stegano-virus development?
a42niem: teach
tbayen: May be a problem with peer review. It's too good here. :-( Perhaps I should go away from this place and join adempiere380. :-)
hahmed: adempiere380 is born already???!!!!
CarlosRuiz: hmmm - please don't mention the w**
tbayen: Not yet born. The right time to inject some code...
hahmed: CarlosRuiz: maybe we should, after the w** things were moving very actively, they're becoming a little slow lately! :D
buildmaster: Project iDempiere build #191: SUCCESS in 22 min: http://jenkins.idempiere.com/job/iDempiere/191/
buildmaster: * globalqss: IDEMPIERE-249 Fix migration script
buildmaster: * Hesham S. Ahmed: IDEMPIERE-162 Let Process Role Access Update honor previous modifications to permissions
buildmaster: http://jira.idempiere.com/browse/IDEMPIERE-162
buildmaster: Peer reviewed, tested and integrated by Carlos Ruiz - globalqss
buildmaster: * globalqss: IDEMPIERE-249: Moving files to correct folder
Nicolas_: got to go, don't get time today to participate ; Carlos, if you have some time can you review ticket 264 (Import Reference) and cancel pull request #13 ; bye bye
tbayen: If we think about it for a second we should do it here. They will copy the code anyway.
CarlosRuiz: interesting - they'll copy the virus too :-D
CarlosRuiz: gtg too - thanks for the meeting - bye
tbayen: if(version.startsWith('ADempiere')){bank.transfer(accounting.calculateBalance().getProfit())*0,1)}
tbayen: bye
CarlosRuiz: HAHAHA
CarlosRuiz: that's a new concept
CarlosRuiz: open virus
red1: hm…
tbayen: red1, you came in a microsecond too late...
red1: oh ok.. then i will wait for the logs
hahmed: red1 do you by any chance know whats the status of FA stabilization?
tbayen: We invented the open source virus including peer review and infection-by-codestealing.
red1: ah.. a conspiracy
red1: its good thing i was not around :D
tbayen: A Conspiracy is hidden. This is all open. Open Source - Open Virus!
hahmed: bye everyone