[Advacs-discuss] Modules

[Helmut Wollmersdorfer]

[redirected to the list.
  If you feel this is impolite, I apologize in advance.]

Oliver Elphick wrote:
> On Wed, 2004-09-01 at 10:48, Helmut Wollmersdorfer wrote:

>>David Palmer wrote:

>>>In this way we could develop a scenario whereby even ecommerce could be 
>>>hooked directly into the accounts structure (sales ledger?). 

>>That's a question of interface design. I assume that an additional modul 
>>like a webshop should not update the database directly. It should better 
>>use a provided invoice interface to sales ledger.

> 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.

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 
(Sales Ledger). This means that SL provides the basic rules and logic to 
create simple invoices, print and view them, record them, create the 
corresponding entries in GL or other Sub-Ledgers, create open items.

SL updates the database directly(?).
This is the first interface - data backend on SQL level.

Then it needs interfaces for input and output.
This can be a User Interface application (providing additional 
conveniences), a batch interface (e.g. a driver reading a file), user 
developed (third party) billing systems.

I assume this structure:

Database
    |
    | SQL
    |
   SL
    |
    | Invoice Interface
    |
Applications

For the invoice interface I would like to support XML, as this provides 
flexibility meeting nearly all thinkable requirements. XML can be mapped 
from or to Python Objects with standard functionality. It can be used 
with different style sheets to create PDF, PS, HTML etc., even from or 
to GUIs. It can be sent to customers or received from suppliers. If we 
use the open standard for invoices - OpenTrans http://www.opentrans.org 
- then we save a lot of time in designing the invoice object. This 
standard reflects nearly all requirements that I can imagine. That does 
not mean, that we should support all entities of it in first versions.
The standard provides mandatory and optional elements.
It also defines the other documents of business transactions like

- request for quotation
- quotation
- order
- orderchange
- order response
- dispatch notification
- receipt acknowledgement
- invoice

This can be very usefull for the other satellites.

Shall I add the documents to CVS/advacs/docs/opentrans? They are 
available in EN and DE, each 4 MB zipped. The license[1] is free and 
seems compatible with debian policy, but to be secure the debian license 
experts should proof this. Do you know the email of them?

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

[1] The original text:
Fraunhofer IAO and the University of Essen hereby grant you the 
permanent, non-exclusive, royalty-free, world-wide right and the license 
to use the openTRANS® Specification and to use, copy, publish and 
distribute same in compliance with the copyrights indicated in the 
specification. Fraunhofer IAO and the University of Essen hereby declare 
themselves willing to grant you a royalty-free license, in accordance 
with copyright laws, for the implementation and use of the openTRANS® 
Tags and Guidelines for the creation of computer programs in accordance 
with these guidelines. This license is granted under the condition that 
you do not assert any copyright claims vis-a-vis Fraunhofer IAO and the 
University of Essen BLI or other companies for their implementation. 
Fraunhofer IAO and the University of Essen BLI expressly retain all 
other rights to the material and the subject of the specifications. 
Fraunhofer IAO and the University of Essen BLI expressly decline any 
type of guarantee for the specification, including guarantees that this 
specification or its implementation does not infringe on the rights of 
third parties. If you publish, copy or distribute this specification, it 
must carry a copyright reference. If, however, you alter the 
specification, the name of the altered specification may under no 
circumstances contain the term "openTRANS® " and the following reference 
must be contained in the amended version: "Parts of this specification 
are based on the openTRANS® Standard V1.0 (Copyright © 2000-2001 
Fraunhofer IAO and University of Essen BLI").

We reserve the right to make changes to the information contained in 
this document without prior notice.

Helmut Wollmersdorfer