Page 1 of 1

Removing an activated creditor payment row

PostPosted: Wed Apr 05, 2017 11:05 am
by neil.interactit
Hi guys,

I have a requirement to be able to remove a batch line item from an already activated creditor payment batch. The need for this requirement is complex, but essentially due to an audit cycle which occurs and must occur after payment activation. So essentially the requirement is to rollback all changes associated with that line item when if was activated ... as though it had been removed prior to activation.

I'm guessing as this breaks some business logic, that there are no procedures I can call to apply this, so I have started looking at table data changes.

Aside from the obvious removal from CR_BatchPayLines, I have identified that I need to remove a CR_Trans record (on TransID) and a CR_TransAlloc record (on DebitTransID), and to adjust both a debit row amount and a credit row amount in GL_Transactions (on GLSetID via GL_Sets on SourceID).

As reverse engineering is never totally comprehensive, and I really don't want to break any accounting, could you let me know what I have missed?

Cheers,
Neil.

Re: Removing an activated creditor payment row  Topic is solved

PostPosted: Wed Apr 05, 2017 9:31 pm
by Mike.Sheen
neil.interactit wrote:I really don't want to break any accounting, could you let me know what I have missed?


To preserve the audit and integrity the system already has, I suggest not trying to remove the line from the payment batch once activated.

Instead, you can deallocate the payment to whatever invoice transaction is was allocated to using our existing business logic in creditors, then create a new credit adjustment and allocate the payment you want to negate to that.

Then create a new creditor payment and allocate that new payment to the invoice which is now unallocated.

This way there is an audit of what happened and when - and things will still reconcile. Trying to alter transactions once posted to the GL is generally bad practice and we deliberately enforce this in our business logic to prevent that - instead we expect adjustment transactions to be made instead to preserve the integrity of the system - and to leave an audit trail.