Forum OpenACS Development: Invoicing and Payments

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.

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.

cheers,

1. http://sql-ledger.org/cgi-bin/nav.pl?page=misc/support.html&title=Support

Claudio,

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

Ditto.

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
Richard

Yes, please go ahead, it will be very interesting to take a look at the code for us.

Fantastis, thank you Claudio. We will take a look and maybe we can plan some next steps after that.

Regards
Richard

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

cheers
Ben

Ah, that's good news. Sorry to be impatient 😉

Cheers
Ben