[Advacs-discuss] Modules

[Oliver Elphick]

On Wed, 2004-09-01 at 13:51, Helmut Wollmersdorfer wrote:
> [redirected to the list.
>   If you feel this is impolite, I apologize in advance.]

Not at all.  I selected the wrong reply option and had to resend the
same message to the list later on.

> Oliver Elphick wrote:
> > We should provide an interface (I'm trying to work that out at the
> > moment) and I would expect that any add-on modules of our own would use
> > it, just as a remote package might interface to it in order to make
> > entries to the system.
>=20
> Invoice interface was just an example.
> But we can use it as an example to discuss the interface architecture.
> As I understand invoicing is one of the basic functionalities of SL=20
> (Sales Ledger). This means that SL provides the basic rules and logic to=20
> create simple invoices, print and view them, record them, create the=20
> corresponding entries in GL or other Sub-Ledgers, create open items.
>=20
> SL updates the database directly(?).
> This is the first interface - data backend on SQL level.

I haven't managed to work this out yet.  Should each module have its own
interface?  I was trying to design an extensible core interface, because
we have to be able to handle inter-module journals.  I don't want to be
forced to generate a fake invoice in order to do a write-off of =A30.01
left on some dead account; and, of course, cashbook entries can affect
any other ledger.=20

However, I've had a lot of difficulty inventing what I want.  So a new
idea is to have a special middleware program to receive postings and
generate the necessary entries.  My current thinking is that posting
lines in a transaction must be entered BEFORE the transaction entry
itself (the necessary foreign keys are flagged DEFERRABLE INITIALLY
DEFERRED) and the transaction itself is entered last, whereupon it will
run a trigger to check that the whole transaction is consistent.  The
permissions of all the tables must be such that no one can change them;
all changes must be done by functions that will run with the permissions
of the database owner.

Of course, there is little that we can do to protect against the
database owner himself; he is like the root user in Unix.  All I have
been able to come up with is to generate an MD5 checksum on the whole
transaction, in the expectation that it will be printed by the
application program.  From an auditor's point of view, I would suggest
that paper records must be kept; but I would always be aware that
someone could re-run the program (even on another machine) and generate
a piece of paper that could replace the original one.

> Then it needs interfaces for input and output.
> This can be a User Interface application (providing additional=20
> conveniences), a batch interface (e.g. a driver reading a file), user=20
> developed (third party) billing systems.
>=20
> I assume this structure:
>=20
> Database
>     |
>     | SQL
>     |
>    SL
>     |
>     | Invoice Interface
>     |
> Applications

To me, the sales ledger is part of the database.  I see it like this:

        Applications --->  Input interface --->  Database
             ^                                      |
             |                                      |
             +-----------(accept or reject)---------+
       =20
        Database -----(direct queries)-----> Applications

Now PostgreSQL has a contrib module (which I have never explored) that
can output XML -- of what quality, I do not know.  Similarly it can
output TeX or HTML, and then there are external modules like DBI (Perl)
and Pygresql (Python).

> For the invoice interface I would like to support XML, as this provides=20
> flexibility meeting nearly all thinkable requirements. XML can be mapped=20
> from or to Python Objects with standard functionality.=20

That seems fine; but I see it as only one of many ways to request data
from the database, as I explained above.

> It can be used=20
> with different style sheets to create PDF, PS, HTML etc., even from or=20
> to GUIs. It can be sent to customers or received from suppliers. If we=20
> use the open standard for invoices - OpenTrans http://www.opentrans.org
> - then we save a lot of time in designing the invoice object. This=20
> standard reflects nearly all requirements that I can imagine. That does=20
> not mean, that we should support all entities of it in first versions.
> The standard provides mandatory and optional elements.

We need to include all fields that we support in the Sales Ledger schema
or in the add-on modules: I will take a look at it.

> It also defines the other documents of business transactions like
>=20
> - request for quotation
> - quotation
> - order
> - orderchange
> - order response
> - dispatch notification
> - receipt acknowledgement
> - invoice
>=20
> This can be very usefull for the other satellites.
>=20
> Shall I add the documents to CVS/advacs/docs/opentrans? They are=20
> available in EN and DE, each 4 MB zipped.=20

I think you should put in a short document with the links; otherwise we
will have to worry about keeping our CVS up to date with them.  I would
regard the relationship as a dependency rather than as incorporating
their work into ours.  (But I haven't had time to look at it yet.)

> The license[1] is free and=20
> seems compatible with debian policy, but to be secure the debian license=20
> experts should proof this. Do you know the email of them?

The debian-legal list is the one; however, the licence you set out below
is DFSG compatible, so you don't really need to bother them.

> For dealing with XML to User Interfaces GNUe=20
> http://www.gnuenterprise.org/ seems to have a general solution (Python).=20
> Maybe we can take some ideas.

Or even use it directly...  That's another one for me to look at.

Thanks very much.

Oliver