Using Trytond 5.0 there is a transactional queue. It seems that this queue is also used if you make a shipment. After the shipment, a task is handed over to the worker to create an invoice. Between the sale and the actual shipment were several months. In that time some changes were made in the data making the creation of the invoice impossible due to a domain error. Nobody got noticed that creating the invoice didn’t happen. Fortunately in the end it got picked up by administration.
The user doesn’t get any errors or warnings because the creation of the invoice runs in a separate worker / process. So it would be nice to send the user a notification or an email when there is an error. You know the user because the record has it. You can also dig through the logfiles but sometimes it maybe too late.
the user may not have the privilege to solve the issue
the user may no more be active when the error happens
Indeed I think we must try to avoid such situation as much as possible as long as it does not increase the complexity of the code nor reduce the performance. The same way as we do on product with the check_no_move in stock module.
It was a custom module which makes it possible to add options to a product (machine) from the list of products. You have then a product with a set op options. When you add the product to a sale, you can select which options you want to add to the product. These options stays forever with the main product.
When removing the option from the list and then trying to create an invoice triggered the error. We are going to change the module, but found with this an edge case.
Also it will be good if you can configure your system to get notification for any critical or error logs from Tryton.
We may need to refine their usage because I see some are critical when they could be just error and other error when they should be critical. Because I think critical should be managed directly by admin and error can wait. (I created Issue 8452: Rationalize logging levels - Tryton issue tracker)
We can do that, but in this case we change the module so options have an end date. A product / machine can be sold with options, but in a few years it’s possible that the customer says that he want to replace the machine with another one. So then a sale is created with a price for the new machine and a price for the machine to be replaced (negative quantity). Also “old” machines (which already exists as a product with options in Tryton) can be purchased from bankruptcy and maybe there are options which are not available anymore. So it basically works throughout the whole system and it’s working well. So in this case changing the module is an enhancement.