Altering invoices again - applying a business rule or not - importing data - architecting a hierarchy of application of rules.

[David Tangye <..hidden..>]

Hi folks,

This is revisiting the discussion of a while back about changing
invoices. I bring it up because I have been doing some invoicing in SL
lately, and think I realised a couple of things that are obvious now,
and that might not have been discussed before.

The general agreement was that invoices, being effectively legal
documents, should not be changed once sent. That's fine. The problem is
that the 'Post' button on the invoice screen is taken to mean 'Sent',
and I believe that this is not necessarily true.

In SL I have been creating an invoice and 'posting' it. By 'posting' I
mean using the 'Post' button. I think of this as 'posting' in database
terminology, ie posting the record to the database. OK its also 'posted'
to the accounts, but I ignore that aspect :-). That's the way I like it.
It lets me work the way I want to work. Later I want to refine it, then
when I am happy with it, ideally I then want to print/send it, 'post' it
to the accounts and freeze it. I understand that there are some who want
the system to not allow this workflow, ie that the 'Post' button means
'Post to accounts', ie freeze the invoice, so changes are not possible.

In my opinion, the objective of the system needs to be clearly stated.
If its to enforce what many contend is 'best practice' then invoices
need to be not changeable at all. However in this case, all invoice data
should be stored and not later derivable via lookups to data, eg
customer and product/service tables which may change after the invoice
is sent out. I would not then be able to progressively build up and
refine an invoice. Instead I would need to do this sort of thing via
building a sales order, and generating it only when I am ready to commit
to its contents and send it out. I guess I can live with that. However I
am wondering how good it would be to have the system able to work either
way. This could be done quite easily via an options (checkbox) to allow
the system to slacken off on enforcing this business rule.

Furthermore, maybe there should be a checkbox on each invoice to
explicitely 'post to accounts and freeze' each invoice. When the invoice
is 'checked' the AP/AR records are created. This might be a one-way
checkbox, ie it cannot be unchecked.

Moreover maybe a few other key areas might be handled in a similar way
as well. That way, any user administrator that does not agree with a
business rule has as a last resort the ability to turn it off. I guess
what I am getting at here is that many business rules might need to be
added into an 'accounts rules matrix' admin screen, where each rule can
be turned off (maybe from the default 'on'). Turning a rule on needs to
be handled carefully. If its allowed, does current get rechecked, and
what happens if data fails the rule? Does an error report get generated
for errant rows. In other words this is a typical data-scrubbing
mechanism, just like that used for importing data during data migration
from others systems.

The more I think about it the more I think this would be a cool feature
to have that would be very easy to implement, and will need to be built
in for data migration/import functionality at some time in the future
anyway.

Irrespective of how the above ideas are or are not handled, I think that
the key issue to to architect the product so that it has accounts
recording functions (few business rules), accounting practice/audit
functions (apply accounting best practice rules), and business
operational functions (eg build an invoice, ok lets call it an
unposted/unsent-invoice), each building on top of each other.