New invoicing method when selling both goods and services

[nicoe (Nicolas Évrard)]

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 with a very simple model with a minimal workflow but with an optional reference field which allow it to be “plugged” to another document workflow. Also the invoice method on sale should be split between services and goods.

So if for example, we want to invoice the service once a shipment has been done, the service order is linked to the shipment and once the shipment is shipped the service order is triggered to be marked as done.

This would then be easy to customize to support plenty of different use cases.

The default could just manage the unlinked case with a simple button to mark the service order as done (and the quantity done).

Implementation

See Issue 9999: Add module to allow services to be invoiced when they are done - Tryton issue tracker

[ced (Cédric Krier)]

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

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.

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.

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.

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.

[ced (Cédric Krier)]

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.

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.

[pokoli (Sergi Almacellas Abellana)]

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).

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.

[ced (Cédric Krier)]

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.

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

Why do you think the task from the project module should not be used?

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”.

[ced (Cédric Krier)]

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.

[dave (David Harper)]

To me a “shipment for a service” sounds a lot like a Work Order, or more specifically Service Order.

I have a few questions about the design:

• So would most/all of this be part of a new module, perhaps sale_service_order?
• Should the “shipment for service” lines just have two states (draft, and done), or do you think they also need a cancelled state (which may then need “shipment for service” exceptions that need to be handled)?

[ced (Cédric Krier)]

@dave

So would most/all of this be part of a new module, perhaps sale_service_order?

I think the basis should be in such module.

@dave

Should the “shipment for service” lines just have two states (draft, and done), or do you think they also need a cancelled state (which may then need “shipment for service” exceptions that need to be handled)?

It is probably good to also manage exception like for goods shipment.

[tbruyere (Thierry Bruyere)]

We planned to use the concept of service to invoice transport costs or administrative costs during a sale…
These costs must be invoiced at the same time as the products of the shipment.

If I’ve tested it well, can’t we use this service-type product concept to put a charge on a sale?

Example of costs: for certain product we must create product test certificates, this type is indeed a service. We have to include this service on the sale because we have to give a confirmation of sale with this service included.

[ced (Cédric Krier)]

@tbruyere

These costs must be invoiced at the same time as the products of the shipment.

This is the role of the invoice method to decide when a sale line must be invoiced. It is not difficult to say that a service must be invoiced once a shipment has been done.

@tbruyere

If I’ve tested it well, can’t we use this service-type product concept to put a charge on a sale?

For shipment cost it is better to use sale_shipment_cost because the invoicing of the cost is done automatically when the shipments are done.

@tbruyere

Example of costs: for certain product we must create product test certificates, this type is indeed a service. We have to include this service on the sale because we have to give a confirmation of sale with this service included.

Indeed it is if you need to track that the service has been actually delivered.

[udono]

@tbruyere

We planned to use the concept of service to invoice transport costs or administrative costs during a sale…

Here I see two invoice methods for these costs:

1. The actual real cost based on time-sheet lines
2. A fixed cost based on a former agreement

For method 2. it would be helpful to have the possibility of time sheet entries as in method 1. for controlling reasons. Like e.g. the company agrees on a service cost of 10, but it always needs at least the time for a cost of 12. So the company should fix the agreement to 12.
IMHO the controlling is not part of the base functionality, but the base functionality should allow to collect service time independent from the invoice method.

[dave (David Harper)]

@ced

I think the basis should be in such module.

I have created Issue 9999: Add module to allow services to be invoiced when they are done - Tryton issue tracker for this.