This is a very important discussion because this applies to voiding any type of document that has accounting consequences, not just payments. We need to get this right.
As far as I can tell from scanning the code the only thing being "thrown away" are payment applications to the invoice. The original payment document is being set to a VOID status and the accounting transaction is being "reverted". Looking at the copyAcctgTransAndEntries service it makes a copy of the original entries with opposite debit and credit. Our testing will confirm, but I assume the new accounting transaction will also have the paymentId. So if we were to look at all the gl transactions for this voided payment we would see the original D/C and the reversal. I have worked in other systems that made a copy of the payment and tied the reversing entries to the new document. I personally do not care for this approach but am not qualified to say which is proper accounting practice. Seems to me that as long as all the gl entries can be tied back to the original payment document we have an audit trail. Regarding payment applications, it is possible that rather than delete the payment application it should also be treated as a void and retained for audit trail. But from what I can tell in OFBiz the Payment Application is not what relieves AR. So Payment Applications have no accounting consequences. The invoice gets the payment application entries. So as long as everything associated with the invoice is reversed, and as with the payment, all those new entries are tied to the original invoice, we should have an audit trail. I think the main outstanding question is whether or not to create a copy of the original document (payment) and tie the reversing entries to that document rather than tie all entries to the original payment. Vince Clark [email protected] (303) 493-6723 ----- Original Message ----- From: "BJ Freeman" <[email protected]> To: [email protected] Sent: Thursday, July 2, 2009 7:40:25 PM GMT -07:00 US/Canada Mountain Subject: Re: Accounting Audit Trail to further this, most accountants take a snapshot of the Database just before they post the transaction to the GL. I see the copyAcctgTransAndEntries happening just before the posting to the GL that is a snapshot of the transactions. it is then frozen and no other interaction with that snapshot can be made. BJ Freeman sent the following on 7/2/2009 2:48 PM: > Vince the answer to this is if you walked in cold ,as an auditor and run > the audit would you know what happened. Would you know when the original > invoice happened and when the cancel entries happened. > could you trace the original invoice and when and how the new entries > that reversed it happened? > Normally, in the past, you leave the records in then you post new > entries that cancel with notes to the previous entries that they are > posting against. > This also affords the original date of the transaction and the date it > was effectively canceled. > > In the paper world the the service you mention would be the equivalent > of throwing away the original paper work and putting a note in place > that I canceled the invoice. > > Unless I missed something. > > > > > Vince Clark sent the following on 7/2/2009 1:31 PM: >> According to the patch the service being called in voidPayment is: >> <call-service service-name="copyAcctgTransAndEntries" >> in-map-name="copyAcctgTransCtx"/> >> >> I have not looked at the code in that service but would assume it is making >> additional AcctgTransEntry records that are the exact opposite Debit/Credit >> from the original entries. Is this not an audit trail? >> >> >> Vince Clark >> [email protected] >> (303) 493-6723 >> >> ----- Original Message ----- >> From: "BJ Freeman" <[email protected]> >> To: [email protected] >> Sent: Thursday, July 2, 2009 11:48:10 AM GMT -07:00 US/Canada Mountain >> Subject: Re: Accounting Audit Trail >> >> r790606. >> voidPayment simple method does not have any audit trail to show these >> actions were taken. >> I did not find any SECA or EECA on payment entity that cover this. >> >> Based on this someone can come in are reverse payment and pocket the >> money with no trace of how it happened. >> >> >> there is couple more but I will have to dig for them when I have time. >> >> >> Jacopo Cappellato sent the following on 7/2/2009 9:36 AM: >>> Hi BJ, >>> >>> could you please be more specific about the revision number of the commits? >>> >>> Jacopo >>> >>> On Jul 2, 2009, at 9:26 AM, BJ Freeman wrote: >>> >>>> http://en.wikipedia.org/wiki/Audit_trail >>>> http://www.dummies.com/how-to/content/the-importance-of-a-bookkeeping-audit-trail.seriesId-107023.html >>>> >>>> http://www.oasis-open.org/committees/download.php/16709/Tax%20XML%20AuditTrail_60215.doc. >>>> >>>> >>>> I see code going in to accounting where entries are removed and no audit >>>> trail is kept. >>>> this goes against all accounting practices. >>>> >>>> >>>> >>>> -- >>>> BJ Freeman >>>> http://www.businessesnetwork.com/automation >>>> http://bjfreeman.elance.com >>>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro >>>> >>>> Systems Integrator. >>>> > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
