New invoicing method when selling both goods and services


(Nicolas Évrard) #1

Rational

There are some business (furniture business for example) that sell both services and goods to their customer. Customers are able to buy the furniture but also, if they need it, the assembly of the furniture they just bought.

It gets complicated when the company intends to use the shipment invoice method. In this case tryton will generate a first invoice with the service line and then one or more invoice when the shipments are done.

Proposal

The proposal is to add a new module defining a new invoice method that would only invoice the services when the goods are sent.

I think that Tryton should support the fact that different services are related to different goods and thus invoice only the right service when the right goods are sent. Thus I think that a way to group sale lines together should be defined, probably a new object that would be put on every lines that relate together.

Another open question is when should the service be invoiced. According to me the default behavior should be that the service is invoiced as soon as the first related good is shipped (and thus invoiced) but the design should permit to change this easily.

Implementation

The implementation will override _get_invoice_line_quantity in order to return the quantity to be invoiced.


(Cédric Krier) #2

For me, it is a too complex topic to be solved in a generic way.

I do not think it will be practicable. At best it could be a package line which is composed of a set of products. But this is another topic.

I do not think there will be a consensus about what is a good default behavior. Each company will have its own rule.

I do not think we should have any new module on this topic but we should ensure that the API of the sale methods allow to be customized easily.


(Cédric Krier) #3

Indeed I think this is a wrong analysis. The assembly service of your example is not invoiced when the goods are shipped but when the service is performed. So there is also another topic which is to have some services sold creating “Work/Task” (I do not think it should be the one from project module). And it will be the workflow of those models that will trigger the invoicing.


(Sergi Almacellas Abellana) #4

I think this is the way to go. To have some object that indicates that the service is done (and then it should be invoiced). Indeed if the task involves sending the goods to the customer, then a shipment must be created with this object indicating the goods to be sent.

Why do you think the task from the project module should not be used? For me the current task is enought to indicate that something has to be done, and it has a state to indicate that it’s still pending or it have been done.


(Cédric Krier) #5

I do not think so. A task which is “sending goods” is a shipment. So it is the standard sale workflow.

Because the project module is at the same level as the sale. It defines how selling services based on project which is a different workflow as sale.
Here we need a kind of “shipment for service”.


(Cédric Krier) #6

After more thoughts, I think this kind of “shipment for service” should have a quiet similar design as the timesheet works. It should be a very simple model with a minimal workflow but with an optional reference field which allow it to be “plugged” to another document workflow.
So if for example, we want to invoice the service once a shipment has been done, the service line is linked to the shipment and once the shipment is shipped the “shipment for service” is triggered to be marked as done.
I think this is a very generic design which allows to support plenty of different cases with simple customization.
The default could just manage unlinked case with a simple button to mark the service as done (and the quantity done). And we should split the invoice method on sale between service and goods.