Re: Thoughts on Voiding Invoices

[Tony Fraser <..hidden..>]

On Thu, 2006-09-28 at 10:37 -0700, Joshua D. Drake wrote:
> Tony Fraser 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.
> 
> How the data is stored is fundamental to the development of a stable
> API. It is likely that any API developed will be a wrapper on top of
> function calls and stored procedures that are built within the
> database
> itself.

OK, so your vote is to use DB function calls and stored procedures as
the API. Cool!

Now, what interface do you propose that these function calls and stored
procedures have? This is what I mean by the API needs to come before the
data modelling. I guess I'm kind of agreeing with David Tangye that we
need to set some scope/requirements _before_ we start hacking and
chopping at the schema.

> Thus without having a stable, normalized data structure the API would
> be
> meaningless.

I still disagree... Posting an invoice is posting an invoice, it's a
document that records the action of "a business" supplying "some goods"
to "a customer" in return for "some remuneration". The information that
_needs_ to be on an invoice is pretty much specified by law/GAAP; who
cares how the system stores that information. What we need to do is
specify how we are going represent that information at the point where
we separate the business logic and the display. When I say display I
mean it in a very general way... It may be the Web interface that's part
of the project. It might be an XML/EDI document parser/generator. It
might even be a webstore (Interchange/osCommerce) that has chosen to
interface directly. Who knows how the API will be used in the future.

I think SQL Ledger not having that very clear separation is a big part
of what has limited its adoption as a business infrastructure module.

-- 
Tony Fraser
..hidden..
Sybaspace Internet Solutions                        System Administrator
phone: (250) 246-5368                                fax: (250) 246-5398