Forum OpenACS Development: Invoicing and Payments

Posted by Malte Sussdorff on
I'm in the process of creating an invoicing package for OpenACS based on Project/Open (taking intranet-costs, intranet-invoices and intranet-payments). I looked in E-Commerce for a functionality to track invoices and cost items, but did not find any at a first glance, so I'm not incorporating ideas from there.

Yesterday the expenses package has been committed to HEAD which is very .LRN centric (storing the community_id, class_key aso.). Other than that it is a minimal subset of intranet-costs.

If you are aware of any other invoicing and expense / cost items tracking and creation tools in OpenACS or are developing them, please reply in this thread. I think we should have a general solution that is split up into:

- Costs / Expenses. Module to track single costs / expenses, similar to the "cost" category of logger or the expense package, but with the enhanced functionality of intranet-costs.

- Invoices and payments. Module to create invoices and track payments.

In Project/Open these three components are seperate packages. I'm not sure if we should keep it that way, as costs, invoices and payments are highly integrated objects and you can still make use of the costs part even if you do not care about invoices. What do you think ?

Besides our project specific use case (We need to provide an invoice to our clients that is based on the tasks that we did, which are logged in Project Manager using logger entries that have to relate to cost entries depending on the agreed upon hourly rate), I forsee this package useful for:

- E-Commerce. Instead of writing your own invoicing and payment tracking system within e-commerce, this package could do the trick for you.
- Expenses. Though it was just committed, I forsee the costs part superceeding whatever has been written for expenses with the exception that the integration into .LRN still needs to be managed. This could be done e.g. by using dynamic types that extend the existing costs object and add the .LRN specific fields.

2: Re: Invoicing and Payments (response to 1)
Posted by Richard Hamilton on
Definitely need to hook up with Jim. I was talking to him on IRC the other day about an accounting package he is preparing to write. He plans to build the data model layer and it is intended that this model will wupport a proper set of ledgers. It would be great to make sure that the higher layers that you propose build on his model.

I made some suggestions to him about 4 or 5 days ago on IRC which you will find in the irc logs.


3: Re: Invoicing and Payments (response to 1)
Posted by Torben Brosten on
I'd like to work with you on this. I am working to migrate sql-ledger (SL) to OpenACS as a series of packages, which will include functionality not too different from your description. No coding has been done yet.

I am formalizing a conversion strategy and a set of additional requirements, and am gathering $900 to get the SL developer docs[1] etc. The docs will be shared with others who want to work in this project. There is a business major here, who is willing to help with the accounting aspects.



4: Re: Invoicing and Payments (response to 1)
Posted by Claudio Pasolini on
Me and my friend Luca Bellini have worked and are continuing to work on issues like invoicing and payments, considering these as parts of a complete ERP system. Our work has been driven by client requirements and I think that it will be quite difficult reuse it in other contexts, but anyway I’ll let the community know about it.


We had a couple of prospects very unhappy with their stock ERP system. They were too small to even consider a SAP like project, but too complex to fit a standard ERP system. One of them sells products which are manufactured by external contractors and he needs to track both the material flow and the work phases before the final quality control. The other prospect's business consists in repairing electrical machinery where each machine is a project with a very complex workflow: the project must be opened, assigned, configured (materials and work phases), bidded, authorized, worked, quality controlled and sent.

Other requirements not adequately covered by a stock ERP system were:
· ‘Purchase Order management’. We needed a fully integrated module capable to manage the material requisition (MR) issue, bid inquiry, PO generation and receiving.
· Inventory management. We needed to trace material movement down to the lot number.


I seriously considered Compiere and SQL-LEDGER, installing and playing with them, before deciding to build a new system from scratch. Here are some random thoughts to explain my choice:
· From a functional point of view SQL-LEDGER was really inadequate to our goals and so I didn’t have to consider very much his technical aspects (CGI & PERL) that don’t make it particularly attractive.
· I spent more time on Compiere which overall was functionally quite close to our requirements, even if lacking in the areas of project management and production.
· Compiere was completely insufficient in the accounting area, with regard to the Italian laws, even if there was an Italian company offering a localized accounting version for about 15000 EUR.
· We don’t know Java and don’t like Oracle and we should have invested heavily in Java to get started
· Compiere seemed very well engineered, but we should have invested a huge amount of time before really mastering it to be able to maintain and extend its functions
· We very much like Aolserver, PostgreSQL and particularly OpenACS
· We were quite familiar with ERP systems, particularly in the engineering, procurement, construction and project management areas
· We were persuaded that an Open Source ERP could have been interesting for the Italian market and finally decided to go for it


The following list should give an idea of the scope and functions of the new system:

· Product management
· Drawings management
· Bill Of Material (very basic right now)
· Customers, Vendors and Contractors management
· Project management
· Material requisition
· Price lists
· Purchase orders
· Receiving
· Bids
· Sales Orders
· Sales statistics
· Inventory management
· Purchase invoices
· Sales invoices
· General Accounting
· Accounts Payable
· Accounts Receivable

The system has been built with OpenACS 5.1.3 and PostgreSQL 7.4.
The main system entities (parties, products, projects, material requisitions, bids, purchase orders, sale orders and inventory) are defined as cr_items.
The standard management functions has been built using extensively the ad_form (thanks Don!) and list::create (thanks Lars!) API.


The lack of time and resources has caused a number of limitations:

· We didn’t write any documentation, apart the comments buried in the data model and the code.
· The system is not internationalized, but I decided to use the English language both for the code and for the comments, so as to ease an eventual future internationalization.
· The system is right now a unique big package and will probably be repackaged in the future.
· We wrote all the queries inline, without using the canonical xql files
· The system lacks a ‘Production Management’ module
· The system lacks an ‘Asset Management’ module


We started working in September 2004 and the first customer did go live in February 2005.
The second customer is going live right now.
We sold the system to two more customers that should go live before the year end.
One of them runs a ‘make to order’ business and so we will extend our Bill Of Material module to work as a
product configurator.


OpenACS is incredibly productive (we already knew that, but this project was really challenging, considering that we had also to recover and load our clients data from their old systems).

Perhaps the heavy use we made of the CR is overkill and the resulting performances are not spectacular, but we didn’t have time to observe and tune the system.

We are appealing to our clients because we give them a customized solution, but the complexity of managing different code bases is becoming bigger and will soon force us to define a more long term strategy.

5: Re: Invoicing and Payments (response to 1)
Posted by Richard Hamilton on

Very excited to hear about your work since this is exactly the direction that several of us in the community have been leaning towards. The fact that you have used the latest versions of the code and have exploited the cr, list builder and ad_form is even better news since less work needs to be done to integrate.

I for one would be very interested in working with you on this in the future.

In particular - referring to your stated limitations:

· We didn’t write any documentation, apart the comments buried in the data model and the code.

This is something that we can sort out as a community. We should discuss the possibility of setting up a collaborative documentation drive. For example we could set up an area on specifically for ERP package doc development. However we do it, I can certainly provide some resources for helping to document this project and I am sure others will also.

· The system is not internationalized, but I decided to use the English language both for the code and for the comments, so as to ease an eventual future internationalization.

I can provide translation resources into a couple of languages and would certainly be able to help with the I18N work (with Malte's guidance).

· The system is right now a unique big package and will probably be repackaged in the future.

Discussion and sgreement required but I am sure that we can make the necessary decisions quite quicly once the development code is familiar to us all. One thought that immediately springs to mind is the possibility of structuring some of the functionality as callback procs so that integration with other modules such as events and ecommerce will be seamless and elegant (i.e. raising invoices from other packages etc.).

· We wrote all the queries inline, without using the canonical xql files.

No problem here at all. I will happily provide resources to help xqlify the sql as I did with an earlier version of contacts!! 😊

· The system lacks a ‘Production Management’ module

We can work on a requirements spec as a group.

· The system lacks an ‘Asset Management’ module


Another area that we must consider is ensuring that the data model is flexible enough to be configured to serve different countries with different accounting standards (for example whilst we don't have fiscal poilice who are bristling with guns in the UK(!) - we do have some quite arcane accounting conventions which must be complied with by computerised accounting systems)😊

I have been putting together some info for another community member who is designing an underlying data model to support accounting ledgers. Whilst your work probably already meets the requirement, maybe a brief scan of some of the UK conventions that I have summarised would give an early indication of what kind of thing might need to be expanded (if anything).

Claudio, thank you very much for posting this. This is very exciting indeed and I for one would like very much to help to generate momentum behind an effort to integrate your work.

Kind Regards

6: Re: Invoicing and Payments (response to 1)
Posted by Claudio Pasolini on

as a first step I could load the source code into file-storage, so as to enable the people interested to have a look at it.

Then, if there is interest in the community, I could setup a demo server with some data, so as to play with it.

Finally this server could eventually become a development server for completing, internationalize and localize the package(s).

7: Re: Invoicing and Payments (response to 1)
Posted by Malte Sussdorff on
Yes, please go ahead, it will be very interesting to take a look at the code for us.
8: Re: Invoicing and Payments (response to 1)
Posted by Claudio Pasolini on
I've loaded the source code (named 'An OpenACS ERP') into the 'OpenACS packages' folder of
9: Re: Invoicing and Payments (response to 1)
Posted by Richard Hamilton on
Fantastis, thank you Claudio. We will take a look and maybe we can plan some next steps after that.


10: WyattERP, GNUe, etc. (response to 1)
Posted by Andrew Piskorski on
FYI, WyattERP was just announced on one of the PostgreSQL lists, it's some sort of Open Source ERP toolkit using PostgreSQL and Tcl/Tk.

This old thread from 2001 and 2003 also mentions a bunch of other maybe ERP-relevant projects, GNUe, GnuCash, Sql-Ledger, etc.

Posted by Ben Koot on
Wouldn't it be an idea to concentrate on what already seems to be operational, and improve if needed, instead of drifting back to days gone by. I recall Thorben is also working on many of the issues Claudio allready seems to have solved. For basic accounting functions SQL ledger doesn't seem to be required, and I guess Claudio created a good alternative.

My immediate questions would be...

1. Will Claudio's package work on OACS 5.2.

2. If not, what needs to be done to make it work.

3. Are there conflicts between Throben's approach and Claudio's solution. Looking at the description I get a feeling Thorben can save quite some time by preventing duplicate efforts, but I may oversimplifying things.

4. Can Claudio's package be made part of the default OACS mountable packages as soon as possible. It's a most valuable addition to the toolkit.

5. How far are we with a multi payment solution, so we can finaly offer a default paypal gateway as an option. Wether we like it or not, 86.6 million consumers seem to have no problems with Paypal so this seems a pretty basic requirement that will help promote OACS.

Just some enduser thoughts


Posted by Torben Brosten on
Hi Ben,

Regarding your item 3:

As I understand it, there are multiple vertical solutions available: ecommerce, Claudio's, dotlrn-ecommerce, invoices, and bill-book to mention a few.

The OpenACS port of sql-ledger is consistent with Claudio's comments (earlier in this thread) about a long term solution.

There are no conflicts, only lots of work to do! =)

The idea is to have the accounts* packages integrate with other OpenACS packages to meet the functional requirements of most businesses, and provide a useful base for vertical solutions and the rest to build upon.


Posted by Ben Koot on
Ah, that's good news. Sorry to be impatient 😉