Need help on a tricky payment term

[Nicolas Micoud]

Hi,

I need to implement a payment term that will do the following :

Date A = invoice day + 65 days

Result = the last day of the month of Date A

Test 1 :

IsDueFixed = Y

FixMonthDay = 28

FixMonthCutOff = 30

FixMonthOffset = 2

Here's the results of my tests :

Date Invoiced DueDate Result

01/15/15 03/28/15 false

02/15/15 04/30/15 true

03/15/15 05/28/15 false

Test 2 (same setup, just change FixMonthDay 28 -> 30) :

IsDueFixed = Y

FixMonthDay = 30

FixMonthCutOff = 30

FixMonthOffset = 2

Here's the results of my tests :

Date Invoiced DueDate Result

01/15/15 03/30/15 true

02/15/15 05/02/15 false

03/15/15 05/30/15 true

I don't understand what should i put in the FixMonthDay field.

Or maybe the tip is elsewhere ?

Thanks,

Nicolas

[Antoni Ten Monrós]

On Tuesday, April 7, 2015 at 4:55:44 PM UTC+2, Nicolas Micoud wrote:

Hi,

I need to implement a payment term that will do the following :

Date A = invoice day + 65 days

Result = the last day of the month of Date A

snip

 

I don't understand what should i put in the FixMonthDay field.

Or maybe the tip is elsewhere ?

Thanks,

Nicolas

Dear Nicolas

Your requirement is very similar to one of mines (mine's a bit more general). I've been asked to have payment terms that works as follows:

With
  X->Number of days of delay
  N->A day of month

Candidate date=current date+X days
Final date= The next Nth day of the month that follows candidate date

For example, 30 days, on the 15th
  X->30
  N->15

This needs to work on the payment schedule level, so you could have 50%, 30 days, on the 15th, and 50%, 60 days, on the 15th

After investigating the functionality present in iDempiere, I came to the conclusion that none of the available options allowed me to fulfill my requirements. The fixed due date doesn't take a number of days as an argument for the calculation, only a month offset (so, it's "in two months, on the Nth", not "in 60 days, on the Nth", and on top of that, AFAIK, doesn't work for payments with payment schedules.

I decided to create a module, but I found it's non-trivial to do so. The relevant code for schedules is in the MInvoicePathSchedule class, under the MInvoicePaySchedule (MInvoice invoice, MPaySchedule paySchedule) constructor. However, it is not possible to override this constructor via a model factory, as you can only override the standard constructors defined in IModelFactory interface. In the end, I'm trying to implement the functionality via an EventHandler, adjusting the due date in the PO_AFTER_NEW event. My implementation is unfinished, and needs some refactoring anyway if it's going to be used outside of the company I work for (We're end users, not implementors, we simply decided that iDempiere was the most suitable alternative for our needs, and proceeded to adapt it where necessary), but I would be happy to point you to how I did it if I ever get it working to my satisfaction. If you solve the problem before I do, I would appreciate if you would share how you did it.

[Nicolas Micoud]

Hi Antoni,

Thanks for answering.

I would like to avoid using payment schedule.

I mean, all other payment terms (which are already implemented) are not using them and i don't want to update all reports.

I would prefer to solve the issue just by updating the sql function 'paymentTermDueDate' and/or adding new fields on C_PaymentTerm table.

Perhaps a checkbox 'get the last day of the month of the candidate date' (to reuse your example) can do the job.

WDYT ?

[Antoni Ten Monrós]

On Tuesday, April 7, 2015 at 10:35:15 PM UTC+2, Nicolas Micoud wrote:

Hi Antoni,

Thanks for answering.

I would like to avoid using payment schedule.

I mean, all other payment terms (which are already implemented) are not using them and i don't want to update all reports.

I would prefer to solve the issue just by updating the sql function 'paymentTermDueDate' and/or adding new fields on C_PaymentTerm table.

Perhaps a checkbox 'get the last day of the month of the candidate date' (to reuse your example) can do the job.

WDYT ?

The problem with updating the database stored function is that AFAIK, there is no way to properly do so as a plugin, meaning that from that point forward, you're on your own when it comes to applying updates to iDempiere. It's the general problem with hacking the core, in fact. Of course, you always have the option to try to get your changes incorporated into iDempiere propper. Otherwise, you will have a system that breaks each time migration scripts update the function, meaning that from that point onward, each migration script batch will have to be checked for modifications to that database function, and those that do will need to be updated by yourself. Been there, done that, didn't like the maintenance burden. You might think it's not so bad, until this kind of stuff starts accumulating, and the worse part is, this kind of things are hard to integrate into source control.

As for adding new fields to the C_PaymentTerm table, they don't change what I wrote above. You would still need to update that function to use them. The reason I went with payment term schedules even for payment term schedules with a single payment term is that they allow me to treat all cases equally, and I've got to deal with split payments anyway, with or without fixed payment days. Also, they are more flexible, in that they can be changed by the user (in the schedule tab) for those corner cases that you can't always treat in the code (like when the customer calls and requests an extension and wants it to appear on the documents - again that might not be possible in your case, bt it certainly is in mine), and can be checked via the standard UI, without needing to generate a report.

[Nicolas Micoud]

I totally agree with you.

Modifying bd objects (view, function, ...) is a very bad idea if you want to follow trunk updates.

In my case, the customer is still on a old Compiere version. And they will never update. So it is not an issue to modifying those db objects.

Anyway, as i was not able to solve the problem on Compiere, I also try on iDempiere.

And as it seems it is not possible at the moment, and wa are at least 2 having this matter, it may be considered as a common requirement and could be a candidate for a jira ticket.