Debtor Payments - dealing with a Short Payment

Payment Discrepancies

There are 2 ways of entering a payment that doesn't match an invoice exactly. One will reduce the amount owing on that invoice and hence the aged balances; the other doesn't.

Entering Payment Amount and Allocating to Invoice

You manually type the amount into the receipt window for that invoice.

The transaction looks like this:-

Note the 'P' for the transaction type.

The aged balance has also been adjusted for this payment.

Entering Payment Amount as a Journal

Whilst this allows you to 'allocate' the payment against an invoice, it does not reduce the value owed. Rather, it sits on the account simply as a payment.

Note that this is a manual journal; you may or may not enter an invoice or sales order reference against this journal. But it is just that, a reference. No values will be changed on any invoice outstanding.

And the transaction:-

Note, the payment in this case has not been 'allocated' to the invoice, the type is 'PO', and there is no audit number displayed (It does, of course, have an audit no.).

The aged balance, in this case, will only reflect the payment in the current balance, not the period in which the invoice sits.

Background Notes

This code posts G/L transaction file, banking list file and then reads through the open item transaction file for the client and gets those with a paid amount and uses that to write new open item records for the documents paid. When finished, it then reads through the records again and zeros out the WIP amounts. It is done in two passes to avoid read/write trampling existing record values.
While doing this it accumulates the payments by age balance group so that it may then update the debtor master age summary totals.
Finally, it reads through the open items again, accumulates by document number and sets up to delete those that are complete. That way they will not show up again in receipt payment.

Also note... when an overpayment is done in receipting it writes the detail record to DBOI and we do not want to do it a second time. Therefore when reading payment records it checks the TRTYPE flag and if 'PO' (no... not for piss off...) does not write a detail record. When detail records are read again to zero the receipt in progress payment field DBOI:WIPAMT it detects the TRTYPE for overpay and moves this value to the DBOI:TRAMT field before zeroing it out.