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

Re: Thoughts on payment handling in 1.4.x

On 4/29/07, David Tangye <..hidden..> wrote:

On Sat, 2007-04-28 at 09:40 -0700, Chris Travers wrote:
> 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: [snip]
Its a bit of a problem in a way, that the implied business operational
model and rules is one cast-in-stone set from the mind of one sql-ledger
creator, who has been noted for uttering such sentiments as 'this is how
business should work'.


I didn't get that feeling from Ed's email.  I thought he was saying
"here is how my process works" and we need to be able to support
(custom solution-wise or by default) his process.


While it does work for a good % of folks, it does
not suit many others. It always occurred to me that a little more
flexibility would be nice in some cases.


Well, I think we need to separate out the base-line target from the
platform.  We ought to have LedgerSMB be a *platform* for accounting
solutions as well as a nice solution in itself fr many users.

The reason for making the application handle a single common case very
well but allow for add-ons, customizations by implementors, etc. is
that many vertical markets have special requirements.  If a truck
repair shop needs to store VIN's on invoices, we don't want everyone
else to have to do the same.

One of my personal pet peaves with SQL-Ledger is that the application
tries to be everything to everyone.  Someone wants a POS module, so
this is included by default.  (We will be making it an add-on once the
code is in better shape.)  The result is a cluttered interface with
too many data entry fields.  It is better to make it be able to be
anything to anyone (i.e. be customizeable to meet any business need.
However, doing so requires a lot of careful thought.

Now, back to Ed's workflow:  prepayments are commonplace and we need
to support them properly (we don't now).



BTW: Huge flexibility can be achieved by defining a model at a higher
level of abstraction, where we deal in entities such as 'Business Event'
and 'Business Event Flow Rule', where Order and Invoice etc are
instances of 'Business Event', and 'Order must preceed Invoice' or
'Order optionally preceeds Invoice' are instances of 'Business Event
Flow Rule'.


Abstraction is a two-edged sword.  If done poorly, you get the wrong
kind of flexibility.  And we do not want the wrong kind of flexibility
in an application like this.  I tend to use a "back to the basics"
form of abstraction.  Basically, you have the following items that are
used as as the basis for support.

* GAAP (IASB and/or FASB mandated) process rules

* Legal documents and their definitions.  Orders, invoices, cheques,
receipts, vouchers, and quotations are all legal documents with
specific definitions, for example.

* Other regulatory compliance and/or best-practice-related requirements.

I believe that workflow should be entirely separate from the above
basic requirements.  In short, the above areas need to behave as
required.  What you do with them is your own business's
responsibility.  And while we can provide a default workflow that can
meet the most common scenarios, we should not try to force anyone to
adopt a certain workflow.


This is how workflow systems as designed. However its a
nightmare for many people to set up as an accounting system, and instead
common business domain expertise is expected to be encoded (enforced in
code) into an accounting system to some degree. Its all a question of
how many,  how tight and therefore how restrictive those rules are.


My vote is for: No rules other than common (stricter of FASB or IASB,
etc) regulatory compliace rules.  No rules other than *accounting*
best practices.

The above is for the platform.

For the application, process rules should only adopt the simplest
possible application of the abive regulatory rules.  If people need to
add their own rules, they can add a Perl programmer to do that and we
can make sure that such rules are upgrade-safe.



> Ok, let us define the document states:
>
> An invoice is a document which states that the goods and services have
> been provided at a specific price.
My stab: An invoice is a claim against a customer for money, supported
by a description of goods or services of monetary value supplied which
are the basis of the claim. (I think the word 'claim' is significant
legally.) There must be a url somewhere that defined all this sort of
stuff properly.


In accounting terminology, an invoice is a "source document."  Other
source documents may be cheques, receipts, bank transfer receipts,
credit card statements, and the like.

You can find a definition and explenation on that concept at:
http://www.dwmbeancounter.com/tutorial/lesson04.html

For the sake of clarity, let us stick to accounting terms as much as
possible.  I am sure that some legalese terms may have misleading
accounting homonyms.

Best Wishes,
Chris Travers