Hi,
Regards the “Posting Date” of a payment / applying entry being before the Posting Date of the invoice / entry to be applied …
This has been blocked on purpose to avoid differences between the General Ledger /Receivables Account / Payables Account) and the Sub Ledger (Customer or Vendor).
If you apply afterwards from the Entry pages (instead of the journal), the Date at which the application will be posted is always the later date, never the earleir date of the (pre)payment.
Without the block the following can happen.
You have a currency invoice.
You have a payment date in December and an invoice in January … each with different currency exchange rates.
With the application of the invoice by the payment you post the realized gain or loss (reflected on G/L Accounts and in Detailed Customer/Vendor Ledger Entries).
Problem is that in this situation you will most probably have G/L Entries with the Posting Date of the Payment (in December) and corresponding Detailed Customer/Vendor Ledger Entries with the Posting Date of the Invoice (January) … still all with the same Transaction No..
If you now run the Trial Balance / Balance to Date report in G/L and in Customer Ledger / Vendor Ledger with the Ending Date = 31.12.x you do not get the same total amount.
This is not good and will most probably show up in fiscal year ending activities and external audits.
And the way to “solve” this was to block the direct application with the “earlier” Posting Date.
Of course you can change the code / remove the check / work around it individually … but that will most probably take you back into the outlined situations with the “differences” in G/L and Subledger.
Another example, maybe not applicable for all countries, but for UK and mainly for AT, CH, DE (and No) is the use “Adjust VAT for Paym. Disc." feature.
In this case on posting the payment with payment discount a VAT correction for the applied invoice is posted.
Here the VAT posting in G/L would again go with the Payment Date but the Posting Date of the VAT Entry would go with the Invoice Date … that is also bad … it is actually worse that the temp. differences in G/L and Subledger.
That’s why there is this blocking code ... on purpose.
Hope this clarifies the background for this check,
