CRITICAL / Allocation Date Issue
Description
Environment
production / official demo/ 2.0.0.v20140320-0304
Attachments
causes
Activity
Daniel Tamm October 22, 2014 at 5:36 PM
Agree that it's not a big deal. My problem occured when a user had changed the accounting date on the invoices but not the document date. The accounting date was after the document date which made the invoices impossible to allocate to eachother (one credit note and one normal invoice).
If the same situation happens to some other user all they will see is an error message that says "Wrong allocation date". They won't be able to figure out what's wrong unless they check the code. This is because the dates they see isn't the accounting dates but the document dates and they "look right".
At least the side effect is now documented in this thread
Carlos Ruiz October 22, 2014 at 1:49 PM
, I think the current code makes sense - we're showing to user the date of the transaction on payments and invoices which I think is what he/she expects to see - we assign by default that date of trx to the accounting date - but the user can change it to another date, so, not a big deal.
Regards,
Carlos Ruiz
Daniel Tamm October 17, 2014 at 9:57 AM
I just had to look a bit deeper in the code since I know the allocation issue was a problem in ADempiere but we fixed it with a patch.
The problem was as described, that the allocation header date wasn't always set to the latest of all the allocation lines (invoices/payments).
The current code (idempiere 2.0) sets the allocation header date from the "Date" field of the allocation form.
The "Date" field is in turn set to the highest of the selected date in any of the date columns.
As I see it, it works as it should.
For this particular issue it's the values of the date that must match the date that's used for validation. Either we use dateTrx/dateInvoiced or dateAcct. We can't use different dates at different times.
Attaching an image.
Daniel Tamm October 17, 2014 at 8:12 AMEdited
The allocation header date is set earlier in the code so the actual first fix in this issue I don't think is a fix, it's just an added validation.
The validation however checks the accounting date when the allocation header date is set from the document / trx date. So the validation validates the wrong date unless my suggested commit is applied.
In most cases this situation doesn't occur because normally document date and accounting date is the same. Problems occur when the dates aren't the same which is how I discovered the problem.
IMHO this issue isn't complete without doing my suggested change.
Carlos Ruiz October 16, 2014 at 9:50 PM
Daniel, seems like an improvement, maybe a new improvement ticket is better than reopening a critical bug.
Details
Assignee
Carlos RuizCarlos RuizReporter
Norbert BedeNorbert BedeLabels
Components
Affects versions
Priority
Major
Details
Details
Assignee
Reporter
Labels
Components
Affects versions
Priority
Major
we are doing audit with international BDO in adempiere and i re-test scenarios in latest idempiere version. The problem is still in idempiere
Symptom: users are create allocation with lot of lines (usually 20-30 lines) without validate payment allocation date. they allocate payment to invoice with allocation date older then payment. (use case 1)
I will try to describe the problem:
Steps to reproduce
1. Create invoice Customer 31.12.2013
2. Create AR payment 1.1.2014
3. Create Allocation to 01.11.2013 - by Payment Allocation window
*yep logically it is not standard, but inside a big transaction with lot of lines
what happening - Account receivable will be cleared in previous period. Means If you print aging report sales=y, accounting date: selected to 20.12.2013 and compare it balance of invoice debtors - will doesn’t fit. (has credited allready) The same behaviour is for Vendor invoices and AP payment and Related Allocations.
Now when auditor asking for documents YTD and balance for a specific account, then we run first the follow selects, make manual changes in database. This take in case of AP2500+AR2500 invoices approx 3-5 days. Terrible.
--select identify when invoice date is earlier then allocation date #Use case:
--SELECT h.documentno, h.dateacct AS allocatedate, P .dateacct AS invoicedate FROM c_allocationhdr h, c_allocationline l, c_invoice P WHERE h.c_allocationhdr_id = l.c_allocationhdr_id AND P .c_invoice_id = l.c_invoice_id AND h.dateacct < P .dateacct AND h.dateacct < '2014-01-01' AND P .dateacct > '2013-12-31' ORDER BY invoicedate
-->>select identify when payment date is earlier then allocation date #Use case:
--SELECT h.documentno, h.dateacct AS allocationdate, P .dateacct AS paymentdate FROM c_allocationhdr h, c_allocationline l, c_payment P WHERE h.c_allocationhdr_id = l.c_allocationhdr_id AND P .c_payment_id = l.c_payment_id AND h.dateacct < P .dateacct AND h.dateacct < '2014-01-01' AND P .dateacct > '2013-12-31' ORDER BY paymentdate
Potential Solutons i suggest.
1. Payment allocationWindow: validate date when click to process button - allocation date can’t be older then payment date. (opt1. its mandatory (would be helpful sys. config enable/disable) opt2. just warning)
i'm looking for another use cases, see attached XLS file, describing accounting consequences.
norbert