If the 5th customer invoice was in error and gets reversed then should
you not reverse the $1 widget back into stock and not the 11th one for $10?
If you were tracking things like serial numbers you would get screwed by
swaping widget 5 for widget 11.
I can see your argument about deleting transactions but rolling back
transactions and making them invisible would give you almost the same
end effect.
I empathize with the issue of trying to track what is owed and not from
a system that shows all the bad transactions.
We use to have an accounting system which was not ours but belonged to
the company of a major share holder.
The guy who processed the orders would now and then get a complex order
that would have 10 or more reversals before the final invoice was issued
to the customer.
Trying to wade through the invoices and credit notes was a major pain in
the ass.
We currently delete transactions when they are screwed up or need to be
fixed.
That being said we don't have stock or anything really complex.
Yes we have been bitten on the ass by the wrong invoice getting deleted
but the pain is much less than the CM/DM issues we had.
I think the question should change from "how do I delete an invoice" to
"how do I make it look like the invoice has been deleted".
But I am not an accountant.
I am just the geek that has to help keep the books clean.
On 08/31/2012 08:35 AM, Chris Travers wrote:
Just so everyone understands the accounting problems here.
Suppose I buy 10 widgets for $1 each and then 1 more widget for $10
each. My FIFO cost queue looks like this:
$1 $1 $1 $1 $1 $1 $1 $1 $1 $1 $10
My inventory account shows $20 in debits and I have credited my AP
account to compensate.
I then sell the 11 parts to 11 different people.
The first 10 invoice show a $1 credit against inventory and a $1 debit
against COGS
The 11th invoice shows a $10 credit against inventory and a $10 credit
against COGS
and now inventory is down to 0.
Now the 5th customer invoice turns out to be in error. We never
shipped this one. The customer never ordered it. it was a data entry
error. Translation, we now have one in stock.
If we void the invoice properly, we will reverse the last sale, and
put $10 back in inventory.
If we delete the invoice, we will just remove the $1 removed. But we
don't really know which one was sold and so we de-allocate the $10 sale.
So now our books are $9 off of what they should be. They show a
balance of $1 in inventory, and $19 in cogs. They should show $10 in
each. The worse is still to come however.
Now we sell the item we had in stock. This brings our (empty!)
inventory value to -$9 and our COGS value to $29. Our books are still
$9 off and we now have impossible, nonsensical values. Delete and
re-enter a few more invoices and you can inflate the COGS as far as
you'd like. This doesn't work.
Worse, this can't be fixed. You can't make a deletion behave just
like a reversal and still keep your books transparent
auditability-wise. Even if it could be fixed mathematically (which it
can't), there isn't any agreement as to what the proper behavior
should be (except 'don't do that'). So it isn't possible to support
the workflow "properly" because "properly" can't be defined.
So unless someone can show that the above issues are incorrect, I
don't see how we can support deleting invoices after they are posted
to the books.
The alternative is the draft/voucher system which is supported in 1.3
for all non-inventory transactions and will be supported for inventory
transactions in 1.4. In this system, in the paper world, the clerk
fills out a piece of paper with the information that will be entered
as an invoice, and this is eventually gets entered and checked by
someone else. Both papers are kept in paper systems for
reconciliation purposes but typically we tend to assume they are the
same (this may be changing and we may be keeping both copies if they
are changed in the future). In this model, the voucher is not an
invoice. It is simply a piece of paper that represents what will be
on the invoice. It is subject to review, and may ultimately be denied.
So in this system we do *not* calculate extrinsic financial movements
for documents until they post. This includes COGS. If a draft
invoice or invoice voucher is deleted before it is approved it has
none of the problems above. Once approved though, it is a part of the
permanent record. This guards against data entry errors because a
second person can review the data before it is posted (either in bulk
or individually). Additionally this guards against theft by ensuring
that a single individual cannot individually enter everything
necessary to cover for theft, etc.
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
--
Alvin Starr || voice: (416)585-9971x690
Interlink Connectivity || fax: (416)585-9974
[email protected] ||
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
