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