Re: Thoughts on Voiding Invoices

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

The issue is not in the accounting transactions but of supporting an
API to an application that is in the process of being re-engineered.
However, I am not trying to discourage work on this, just warn that it
may not be extremely easy and that if conservation of energy is more
important than immediate need, then it might be better deferred.

A ledger transaction is a ledger transaction.  However a lot of
functionality goes beyond the accounting functionality.  For example:

1)  What if I want to retrieve data about a customer?  What happens if
the underlying API changes in profound ways because we decide that
storing customers and vendors in different tables makes no sense?

2)  What if I want to retrieve data about a sales order or Quotation?

3)  What if I have extended the invoice structure in order to store
information about, say, the mileage log of the truck that made the
delivery?

4)  Suppose I want to retrieve a part but because I am a retailer that
sells alcohol and/or tobacco, some additional data is extended wrt the
parts table?

Now, a major part of the problem is that as the invoice handling,
contact handling, and extended fields handling is rewritten to make it
better, you may find that the API gets profoundly broken in the mean
time.  In these cases, we either have to keep things relatively
backwards-compatible, or we have to accept that an API may be slightly
unstable during the process of re-engineering the application.

Not that this is the end of the world.  These are not unsolvable
problems, and the maintainer of the API layer could handle them.  It
is just that I think it is going to be much easier to do this if we
wait until some key database issues are worked out.  In particular,
the custom field capabilities might be extended in upcoming releases.

Just my viewpoint though.

Best Wishes,
Chris Travers

On 9/26/06, Tony Fraser <..hidden..> wrote:
> On Tue, 2006-09-26 at 09:49 -0700, Chris Travers wrote:
> > In reality, a stable API is probably going to have to wait for a
> > stable DB schema...
>
> I disagree... Accounting is accounting, how the data is stored (DB
> Schema) is an implementation detail.
>
> If the API is designed to meet the needs of accounting rules/best
> practices/GAAP then how the data needs to be stored will become more
> clear.
>
> --
> Tony Fraser
> ..hidden..
> Sybaspace Internet Solutions                        System Administrator
> phone: (250) 246-5368                                fax: (250) 246-5398
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel