OFBiz › OFBiz - Dev

Accounting Audit Trail

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

BJ Freeman

Accounting Audit Trail

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.

Jacopo Cappellato-4

Re: Accounting Audit Trail

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.
>

smime.p7s (3K) Download Attachment

BJ Freeman

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

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.

Vince Clark

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

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
[hidden email]
(303) 493-6723

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
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:

--
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

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

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
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> 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.

BJ Freeman

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

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
>> [hidden email]
>> (303) 493-6723
>>
>> ----- Original Message -----
>> From: "BJ Freeman" <[hidden email]>
>> To: [hidden email]
>> 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.

Vince Clark

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

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
[hidden email]
(303) 493-6723

----- Original Message -----
From: "BJ Freeman" <[hidden email]>
To: [hidden email]
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:

--
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

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

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
> [hidden email]
> (303) 493-6723
>
> ----- Original Message -----
> From: "BJ Freeman" <[hidden email]>
> To: [hidden email]
> 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
>>> [hidden email]
>>> (303) 493-6723
>>>
>>> ----- Original Message -----
>>> From: "BJ Freeman" <[hidden email]>
>>> To: [hidden email]
>>> 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.

BJ Freeman

Re: Accounting Audit Trail

In reply to this post by BJ Freeman

maybe what is missing in this is the reason for an audit trail.
Audits are done from many angles to make sure all the ways prove out to
the same result.
it is the proof that no one has tampered with the accounting records and
possibly embezzled or misdirected funds.
Yes I know there are other ways to embezzle, but this is proof the
accounting is in good shape.

BJ Freeman sent the following on 7/4/2009 10:00 PM:

> 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
>> [hidden email]
>> (303) 493-6723
>>
>> ----- Original Message -----
>> From: "BJ Freeman" <[hidden email]>
>> To: [hidden email]
>> 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
>>>> [hidden email]
>>>> (303) 493-6723
>>>>
>>>> ----- Original Message -----
>>>> From: "BJ Freeman" <[hidden email]>
>>>> To: [hidden email]
>>>> 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.