New invoicing method when selling both goods and services

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

1 Like

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.

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.

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.

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

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.

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

I think the basis should be in such module.

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

1 Like

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.

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.

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.

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

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.

I have created Add module to allow services to be invoiced when they are done (#9999) · Issues · Tryton / Tryton · GitLab for this.