Wednesday, May 1, 2019

I continued working on #2776 (prototype for Lino Presto).

Invoicing areas

An invoicing area is is used to classify business activities into different parts for which end users can start separate invoicing plans.

This is used in Lino Presto to differentiate between activities that are invoiced manually based on occasional work and those that are invoiced automatically based on regular work. In Lino Tera will probably be used to separate the therapy centres in different towns.

The application is responsible for selecting only invoiceables that belong to the area of the current plan. In Lino Presto we do this by defining a field Room.invoicing_area.

Changes in lino_xl.lib.invoicing:

Added a new model Area to be configured by the site admin via Configure ‣ Sales ‣ Areas.

New field Plan.area.

Plan.journal replaced by Area.journal.

Removed the StartInvoicingForJournal action which anyway wasn’t used by anybody.

Demo orders

I extended the demo fixture for lino_presto.lib.presto so that it now creates orders. This took a few hours. It’s a complex but important work. Only this step makes the demo project useful because without any orders and calendar entries the demo wasn’t obvious to understand. It is complex because you need to design how to generate fictive examples which cover more or less what they want.

Orders arrive randomly, about daily. There are days without any order and days with more than one order . Teams have their typical number of calendar entries to generate.

Two new plugin config options for lino_xl.lib.accounting: purchase_stories and sales_stories. These are set to False in Lino Presto because they plan to use Lino only for generating invoices, not for their real accounting.

Commits

The test suites are probably broken, but I committed my work because lino_presto.projects.presto1 is now getting interesting for Hamza and Tonis who are working on #2967 (for which Lino Presto will be the pilot user).