I guess my question is, bluntly, whether or not we care. People have 
named one project or another almost anything over the years. Also, 
Minerva as forum is pretty distinguishable from Minerva as invoices - 
not like proforma where existing products do the same thing.

There is an (active) phpBB clone on SF with that name.

This is now in the incubator as Minerva. Name is completely 
negotiable; it's not blatantly taken by an active project and it's in 
the horde scheme (mythology) and commerce-related. I mainly wanted to 
get it under CVS.

- Correct reset invoice name/id in aftear creating new invoices

- Allow to overwrite variable parameters for Horde_Form_RDO

- Move Agora comment code to Proforma::postComment to add automatic 
adding comments when the program automatically does someting and for 
user  action log

- Form for sending email notification of expired invoices to clients

- Mark invoice as "Klishé" - Future invoice drafts



Inovice Klishe will be the last feature added for the first version of 
Progorma

- Email drafts

- Check if the invoce is saved before it is converted, printed or deleted.

- Clone invoices - create invoice from before created proforma/delivery note.

- SQL unique index correntions.

- Lock invoce while editing

- Posibility to reset invoice number/names every year

- Posibility to offset the initial invoice number

- Refactor invoice name generation to have incremental id/name for each type.

- Moved statuses and taxes to RDO. Filtered permission by persmission 
and cache.

- Move each draft files to its folder. You can still have genreal 
header/footer.

- Added a page to preview drafts.

- Stores file in comment when sending invoice by email

- Export only realy needed methods to ajax

- Update totals when import articles

- Stores invoice file in comment when sending invoice by email.

- Added a page to preview drafts.

- Moved statuses and types from config file to SQL using RDO.

- Move draft files in order to have a folder for each draft. You can 
still have a general header/footer.

Thanks. I will check for possible good solutions.



I started to move Currencies and Taxes to RDO. As you can see I 
extended Horde_Form and Horde Template to handle automatic form 
generation and browsing.

Something to take a look at for possible inspiration: 
http://www.blinksale.com/home

- wrapper for converting data charsets for ajax to utf8 (json)

- better error handling, now all errors are pear_error transformed to 
JS alerts when needed

- spped up with caching administrative data (like taxes, currencies, 
external api lists etc)

- compressed js

Send invoices by email as attachments in a desired format.

- Searching invoices now works for all type of invoice attribute. You 
can find invoice by date, client, article name, reseller name.... etc.

- Printer friendly using print horde theme

- Reseller revenue calculation



Now all the basic functionality are done.

We will start to use this internally to test them.

Has someone have tried it?



Duck

- Introduce Resellers. This are agents that sell your products and 
service. So you can track to who belongs the merit of one income and 
calculate his/her percentage (revenue). Resellers are link to clients 
in a may-to-many relations.

- Added config option to define possible documents export formats.

- comments on invoices using Agora for internal history  (ex. the 
costumer called  and said that will pay tomorrow, or I added a new 
article....)

- log and display when and who edited the invoice

- comments on invoices using Agora for internal history  (ex. the 
costumer called  and said that will pay tomorrow, or I added a new 
article....)

- log and display when and who edited the invoice

- uses central currencies and taxes (see bug #3731)

- basic export system using Horde_Temaple

- implemented abiword and openoffice driver to export files to desired format

- Moved database functions to Perfor ma_Driver_Sql

- Stores currencies settings.

- Stores used taxes settings.

- Stores user and timestamp for each edit (not used jet, in long 
future I wold like to see an versioning system here)

- Started with server-side data checking and recalculation (don't trust ajax)

Jan:

I didn't use code from hermes. I took a look, but I didn't understand 
the logic very much.  For the name I am not so delicate.



Thomas

- I agree about displaying only the used tax calculations.

- I still changing the SQL design. But of course it will store all the 
data not just the ids. Even for currency values and so on.

- Ajax just select the tax values and then calculates all the values 
on the client side. For now I don't perform any server-side checking 
since I would like to brig the API on a basic usable stage first.



Then move the source in the incubator (if possible) to start to work 
with other that will show interest in this module.

Added mega feature - basic save and edit support :)

Jokes apart.

- linked invoice types and statuses to permissions system

- basic dynamic save support

- to edit an invoice, ajax refills the form

- added API calls to allow external access to invoice data, so other 
APIs can use invoice for their billing processes



Next spet it would be the debug the save/edit methods (without special 
data error checking for now) and then exporting to PDF/DOC/RTF.

Great work!!!



Some comments (Please don't take them too serious if I'm totally wrong on

some points. I installed proforma yesterday evening and just played around a

little bit - but I didn't dig deep enough to be sure about what I'm writing):



- using AJAX for tax calculation while updating fields seems a useless over-

   head - it should be worth the effort to write some client-side 
JavaScript to do

   this job. While finally saving an invoice I wouldn't trust these 
values and do

   the same calculation once again on server side.



   This may be seen as a duplication of code (same thing in PHP and JS) -

   but it saves us a lot of HTTP traffic. Especially if you're going 
to use HTTPS

   this shouldn't be underestimated.



- show tax sums only for taxes used in the current invoice (there are 
countries

   with 5 and more tax variants - and only one of them is used in probably 99%

   of all invoices)



- what will the SQL layout look like? I would suggest something like:



   * invoices: containing customer details (address... - it's important to

     duplicate them and not to save just an ID), billing date, ctime, mtime,

     document type (offer, invoice, proforma invoice...), state (sent, payed)



   * invoice details: invoice id, amount, price, tax, currency



I'm in a hurry right now - but maybe this weekend I can find some time to

go on playing with "proforma" ;-)



Kind regards,

Thomas Gelf



NB: Please keep this ticket up to date!

The screenshot looks nice, I didn't have time to look at the code yet 
though. Have you been able to reuse anything from Hermes' invoice 
support?



We need to find a different name for the application btw., because 
there exist already a few software products and companies with that 
name.

Screen shot of the invoice preparation

Proforma allows to create and track invoices. The idea is to create a 
centralized billing system to an dedicated module that can be even 
used by its own.



Reads contacts from Turba. Items can be typed directly of imported 
from any module that have the listCostObjects method like Merk, Sesha, 
Hermes, Whups.



Supports taxes and currencies. Uses ajax to handle dynamic article 
insertion and prices/taxes/exchange calculations.