Re: For those interested in the CRM/Entity management

["Chris Travers" <..hidden..>]

On 6/20/07, Jeff Kowalczyk <..hidden..> wrote:
> --- ..hidden.. wrote:
> > +1.  An argument could even be made that an invoice, once produced,
> > should become an opaque blob of data.  I can't think of any reason to
> > modify a produced invoice.  Any amending of an invoice should surely
> > create a new, separate document?
>
> True, that reversal-only policy is the stated direction for LedgerSMB.
>
> +1 for snapshotting lookup data into finalized documents such as invoices, and
> providing a SP interface for data introspection and verification (*) only, no
> modification (which was the intent all along, I believe).

Also the data may not strictly be "lookup data."  For example, suppose
I order a part for one of my customers and ask that the bill be sent
to a temporary address (but still against my credit account) because I
am expecting to be at that customer's site when the bill arives.

> (*) If there is any sensible way to digitally sign a finalized document (e.g. a
> hash of the canonical plaintext or XML, YAML representation of an invoice),
> that might be an interesting feature to users.

That can be problematic.  If we add a field to the XML or plaintext,
we invalidate the signature on db lookup.  On the other hand, I am not
one for storing data in the db in non-reational ways.  A better
approach IMO is simply to use db tools to forbid updates.  I am sure
we would start just by locking down permissions, but one could also
use rules triggers to prevent updates selectively (i.e. allowing
information to be changed about a record relating to its state in the
appliation but not allowing document information to change).

Best Wishes,
Chris Travers