IDempiere/FullMeeting20150408

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2015-04-08

CarlosRuiz: Good Morning
nmicoud: Bonjour
a42niem: Guten Tag
nmicoud: Could you have a look at https://groups.google.com/d/msg/idempiere/ykc9dB-FdHs/y4qIfBo4-XoJ please ? I'd like to know what is the best practice
CarlosRuiz: sure - brb - give me 5 min
nmicoud: thanks
CarlosRuiz: nmicoud, I get it - but it sounds like a bad practice to use X instead of M
nmicoud: how should i do if i just want to update a record ?
CarlosRuiz: why is that? I didn't understand -> "as i didn't want to control update"
nmicoud: i don't want to get into the beforeSave method
nmicoud: as it could failed
nmicoud: in fact,i just need to do a "update c_invoice set... = abc where c_invoice_id = 123;"
CarlosRuiz: ok, I'll change LCO according to that
nmicoud: but means that it should be done in all plugins, right ?
CarlosRuiz: yes - I have seen the same bug if somebody tries to use GenericPO
nmicoud: in my plugin, i just check for the table name, never on the object itself. So, maybe instead of making a tableName.equals("C_Invoice"), we should do a po instanceof MInvoice
nmicoud: i also see it :D
nmicoud: Besides, i haven't had the time to review the ticket for updating the print format name. Just do the https://idempiere.atlassian.net/browse/IDEMPIERE-2554 (add acknowledgement of receipt on email). If you could see if is ok to integrate. Also, you send me your POC on Special Editor (ability to update fields for processed records). I think i will try to implement it for our instance. Would you be ok to publish it on bitbucket i
Vyrlokar: nmicoud, heya
nmicoud: hi
Vyrlokar: You're interested in having payments work on a fixed day, with X days delay, right?
nmicoud: yes, date invoiced + x days and then take the last day of month
Vyrlokar: I'm the guy who replied to your post on the google group
nmicoud: ah ok :)
Vyrlokar: Our use cases are slightly different, as you're interested in payments without schedule, while I'm interested in payments with schedule.
Vyrlokar: but we could definitively try and solve both use cases
nmicoud: sure
Vyrlokar: payments without schedule are handled exclusively by database functions AFAIK
CarlosRuiz: sure nmicoud - please publish that
nmicoud: yes, there is no field "due date" on c_invoice (could be interesting, but that's another debate :))
nmicoud: ok, Carlos, will do that
Vyrlokar: nmicoud, well, there is, you only need to define a payment term schedule with a single payment term
Vyrlokar: the database function for your use case is paymenttermduedate(paymentterm_id numeric, docdate timestamp with time zone)
Vyrlokar: nmicoud, it's weird (but not that unusual, it's IMHO similar to how there's a swing client and a ZK client) that there are two ways to do the same thing, with different features
Vyrlokar: schedules don't handle fixed days, at all
CarlosRuiz: nmicoud, committed and compiled
CarlosRuiz: http://ci.idempiere.org/job/globalqss-iDempiere-LCO/
nmicoud: thanks carlos, need to update mine now :)
Vyrlokar: nmicoud, On my side, things would be much simpler if the part where due date is calculated was in a function outside of the constructor, as that way, it could be overridden in a module, via a model factory
a42niem: we once created a paymenttermbasedate for a customer so he got some flexibility for strange paymentterm constructs
nmicoud: not simple to implement as it would change the behaviour which was created since compiere times
a42niem: it needed a callout to set it from invoicedate and change some views
nmicoud: but perhaps we could add a DueDate on C_Invoice (in trunk, using a jira ticket). This would be filled with the sql function. And then you will be able to update it in plugin
Vyrlokar: nmicoud, if you're replying to me, then yes, it would be a simple matter of making the constructor call something like "set due date" for the payment term, as that could be then overridden
nmicoud: yes Vyrlokar
Vyrlokar: nmicoud, invoices don't necessarily have a single due date, that's why making it a field of c_invoice would not work for me
nmicoud: a42niem : as it need to update views, it's hard to maintain in plugin
nmicoud: Vyrlokar : due dates could be found on C_Invoice or C_InvoicePaySchedule
nmicoud: according to the payment term
Vyrlokar: nmicoud, my usual use cases are X% immediate, Y% 30 days, and X% 30 days, Y% 60 days
Vyrlokar: all dates with possible fixed day
nmicoud: when you say 'fixed day', is it equal to 'last day of month' ?
Vyrlokar: again, I solve this with an event handler (not the most elegant solution, but I believe it is the only way it can work without hacking core)
Vyrlokar: Last day of month is one possibility
Vyrlokar: common fixed days are 25th, last day of month, and 1st
aguerra: buenos dias a todos!!!
Vyrlokar: buenos dias aguerra
nmicoud: hi aguerra
CarlosRuiz: Hi Alejandro
aguerra: Salu2 a @Vyrlokar @nmicoud @CarlosRuiz
CarlosRuiz: nmicoud, I think maybe taking FixMonthDay=31 as last day of month
nmicoud: seems it could have problem with february
nmicoud: see https://groups.google.com/d/msg/idempiere/VA3707UDwN8/rQxjrgbehJ4J
CarlosRuiz: yes - I mean - changing the DB function to use 31 as LDOM
nmicoud: i don't understand :(
nmicoud: you want to change the db function ? or just put a differnt value in c_paymentterm ?
CarlosRuiz: I think actual algorithm doesn't make sense - to say duedate=05/02/15 when you said FixMonthDay = 30 & FixMonthCutOff = 30
Vyrlokar: CarlosRuiz, what would be the right course of action for requesting a small refactoring of MInvoicePaySchedule, so the dates are handled in a separate function that is then called by the constructor that takes a MInvoice and a MPaySchedule? That way, that function would be overriddable in a plugin, to incorporate advanced functionality
CarlosRuiz: Antoni, where is it being calculated actually?
Vyrlokar: right now, lines 164 to 167 of org.compiere.model.MInvoicePaySchedule in the org.adempiere.base project
Vyrlokar: those 4 lines right now handle the due date calculation for schedules, in a simple way (just add days, no fixed date, no next business day)
Vyrlokar: CarlosRuiz, as the calculation it done in a nonstandard constructor, I don't see a way to override it in a plugin
Vyrlokar: WB CarlosRuiz
Vyrlokar: nmicoud, at least we can curse weird business requirements together ;)
nmicoud: :D
CarlosRuiz: and c_paymentterm.afterdelivery is not used anywhere - another candidate for inactivate
CarlosRuiz: Antoni, so you can create an EventHandler (ModelValidator) to change the date on beforeSave as I see
Vyrlokar: CarlosRuiz, That's how I've done it, but it's hackish
CarlosRuiz: paymenttermduedate is not taking into account the p.IsNextBusinessDay flag
Vyrlokar: CarlosRuiz, as it will overwrite user input on the first save, when created manually, IIRC
Vyrlokar: CarlosRuiz, I created a plugin that extends MInvoicePaySchedule, adds some extra fields and an updateDueDate function, and then use an EventHandler to call that function on PO_AFTER_NEW
Vyrlokar: I'm testing it right now
Vyrlokar: CarlosRuiz, MOrderPaySchedule looks like a copy of MInvoicePaySchedule with some minor changes, with the original copyright left intact, even if that file never existed in Compiere
CarlosRuiz: check http://www.adempiere.com/FS01_Commitment_AR_AP
Vyrlokar: CarlosRuiz, thanks, interesting. However, since dates are calculated from order date for orders, and from invoice date for invoices, unless invoice date==order date, the schedules will not match...
nmicoud: gtg, (if you have the time CarlosRuiz, could you look at https://idempiere.atlassian.net/browse/IDEMPIERE-2554) please ? thanks and cu later
Vyrlokar: gtg, cya everybody
norbertbede: hi alls
CarlosRuiz: bye Antoni - hi norbertbede
Vyrlokar: hi norbertbede and bye
norbertbede: looking for experience zk7/idempiere3/nginx(gzip). im getting extremly frequently message Unexpected token < (Syntax Error)
norbertbede: reported> https://idempiere.atlassian.net/browse/IDEMPIERE-2496
norbertbede: im totally confused :( how to catch
norbertbede: i found lot topics about potential issues with javascripts
norbertbede: when a googled
norbertbede: when i googled
hieplq: hi @CarlosRuiz. i has a issue relate "allow null for city when "Allow Cities out of List = false". not sure it's issue or feature,
hieplq: maybe you can confirm https://groups.google.com/forum/#!topic/idempiere/7IDj_fnrQEE
CarlosRuiz: so, your question is if city must be mandatory?
CarlosRuiz: I think it must - a location without a city is untraceable
hieplq: @CarlosRuiz it's ok if always mandatory but when i "Allow Cities out of List = true" it's don't request input city
CarlosRuiz: and the city field is filled?
hieplq: no.
hieplq: i fill same case "Allow Cities out of List = false"
CarlosRuiz: allow cities out of list = false -> must force to choose a city from the list - is an autocomplete list so it shows the cities when you type the first letters
CarlosRuiz: allow cities out of list = true -> it means it allows you to type a city in that field that is not on the list
hieplq: thanks, just confirm to know it's issue or feature.
hieplq: with me it still is a issue :D
CarlosRuiz: is it working that way?
hieplq: i know what you mean. but my case is "Allow Cities out of List = false" => user can don't input city and location save success
hieplq: "Allow Cities out of List = true" => user don't input city (null) and location save unseccess
hieplq: in "Allow Cities out of List = true", user even input nothing in city text.
hieplq: i test in location window (exact from init client) not from location dialog
CarlosRuiz: ah - that's intended for location dialog
CarlosRuiz: you would need to add validations on initial client setup to control that
hieplq: ok. i want ask other issue relate config hazelcast.
hieplq: i explain at https://groups.google.com/forum/#!topic/idempiere/aWgia827mZ0
CarlosRuiz: hieplq, haven't tested using two different ports in adempiere simultaneously
CarlosRuiz: but it doesn't sound as hazelcast - maybe zk session?
hieplq: mabey hazelcast effect session
CarlosRuiz: you can try disabling the hazelcast plugin to check if that's the cause
hieplq: it's ok when i access my local instance and demo instance in same browse
hieplq: but it's not importace, will investigate late.
hieplq: about IDEMPIERE-1752 i will re-test it.
hieplq: hi @CarlosRuiz, what NPE message you see when test IDEMPIERE-1752.
hieplq: if at org.adempiere.base.callout.CostAdjustmentCalloutFactory$CostAdjustmentLineProduct.start(CostAdjustmentCalloutFactory.java:69)
nmicoud: CarlosRuiz, i will publish Special Editor sources soon. But i can't find the email you sent me - neither the google forum thread i create for explaining the purpose - could you send me it again please ? as everything was well explain in it, i will copy/paste the content
hieplq: you must resolve IDEMPIERE-1744 to see cast issue of IDEMPIERE-1752
hieplq: and patch in IDEMPIERE-1752 is for cast issue not NPE issue
CarlosRuiz: IDEMPIERE-1744 doesn't have a patch
CarlosRuiz: nmicoud, is an email from 28/02/2014
CarlosRuiz: two emails indeed
nmicoud: i think i've deleted it :(
nmicoud: or i move it somewhere, but seems a very dark place
CarlosRuiz: resent both
nmicoud: thanks
CarlosRuiz: brb - @ lunch
nmicoud: bon ap' :)
norbertbede: hi nmicoud are you running already version 3 or still 2,1
nmicoud: hi norbert 2.1
norbertbede: are you planning to upgrade ?
nmicoud: not now
nmicoud: maybe near the end of year, but nothing is planned
norbertbede: ok.
norbertbede: thanks
nmicoud: oh! thanks for integrating #2235 Carlos :)
CarlosRuiz: thanks to you for developing that
nmicoud: :)