maybe terminology will help.
there should be "reversal" of a transaction.
this would be a transaction entry that cancels the original entry with
notes in the reversal of why and the transaction this relates to.
So the transaction file would show the original transaction and a reversal.
This is true audit trail.
Now once the transaction file has been balances and before it is posted
to the GL, a copy of this Transaction file is copied and frozen.

The paymentapplication is an important piece of data. it links payments,
 invoices, and billingAccounts.
all those should have a reverse entry that matches the original.
so no matter where you start you can trace back and come up with same
totals.



Vince Clark sent the following on 7/3/2009 2:25 PM:
> 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.

Reply via email to