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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users