[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on payment handling in 1.4.x

Hi Ed;



I can't help wondering if the current Quotes/Order/Invoice model isn't
slightly too few states for some business.

My model is:

- Customer calls and gets quote
- Customer calls back and places order
- Customer either hands over CC details on the phone or enters them into
the website
- Only once we have payment do we ship the order
- Then we raise the invoice (possibly in the same step as the above)

One of the steps which I find clumsy is that recording of payments taken
against orders.


Ok, accounting-wise, an order is not a financial transaction, so it is
not associated with a journal entry itself, but a payment is.

A prepayment may also be associated with an order in the system you
describe.  Please file a feature request so we don't forget about it
:-)  Note that this would be the proper way to track down payments on
services rendered, since invoices are supposed to be posted when the
business's obligations to the customer are fulfilled (yes, you can
invoice up front, and adjust later as well, but it would be nice to
get rid of as many adjustment points as possible).


 For example it's fairly straightforward for the case of
customer using a valid CC and the order immediately dispatches.  But
sometimes they give CC numbers which are declined and I need to keep the
order hanging around to chase for several days until they get in touch
again.  Or else we get bank transfers / Cheques that we need to wait
for, etc.


Ok, let us define the document states:

A quotation is an offer to provide goods and services at a specific
price.  A Request for Quotation should be self-explanetory in this
area.

A sales order is an offer by a customer to puchase goods and services
at a specific price.  A purchase order is an offer to purchase goods
and services from a specific vendor at a specific price.

An invoice is a document which states that the goods and services have
been provided at a specific price.

While all three may be legal documents, only an invoice qualifies as a
document which indicates a completed financial transaction.

Note that prepayments against orders have different financial rules
than payments against invoices:

When a sales invoice posts, an A/R journal entry is made, indicating
that a given customer now owes us a specific amount of money.  This
goes into an A/R asset account.  Appropriate COGS and income
transaction postings are also made.  A payment also comes in against
that A/R asset account.  In essence, a sales invoice increases your
accrued assets, while a payment against a posted invoice transfers
those assets from a collectable (debt-based) asset into the
appropriate account (for example, a bank account).

A prepayment is handled very differently.  It increases both assets
and liabilities because it incurrs obligations with the payment
(either you have to do the work or refund the money).  So the payment
would get entered into the appropriate cash or bank account and also
something like a "unearned income" or "prepayments" liability account.
When the invoice posts, you would then decrease that liability in
lieu of increasing the appropriate asset.

This can all be done in LedgerSMB at the moment with the exception of
tracking the order connected to a payment.  There is the added
limitation that one cannot properly enter a prepayment at the same
time you pay off an existing invoice since both would go into the same
asset account and that is not GAAP compliant.  Perhaps we should track
the summary A/R and A/P accounts as connected to the orders (orders
would default to a liability account, invoices to an asset account)
and invoices  and not assign them at payment time?  That would make
more sense to me.

Hope this makes things more clear.

Any ideas?



It's quite hard to follow the progress of orders which are really firm,
but we are waiting on payment versus speculative quotes, etc.


Perhaps a status field on the order would help?  That might be an
important feature request too (please file it ;-) ).


 Also we
may sometimes take payment, but ship a few days later (for various
reasonable reasons) and again it's a case of tracking those orders
effectively.

Quite easy now that we are only doing a few orders, but it gets very
hard as the volume rises

Also there are a couple of severe bugs in the current implementation
involving the code for shipping "Orders" before they are invoiced.  If
you do certain actions then the system starts to loose stock...

...Then lets introduce partial payments, partial shipping, partial
refunds (or complete refunds), returned for RMA repairs, etc...

Any thoughts?


Ideally, when you post an invoice, any prepayments should be detected
and the appropriate unearned income accounts should be handled
appropriately.  This cannot be done at the moment, but I think we
should look at doing it.

Best Wishes,
Chris Travers