I agree that we should add this fields like we did on shipment but for each model we should use diferent kind of fields as we use diferent Workflow. So here is my proposal for every model:
Sale
I think we should add two employee fields:
One named Employee that will be set on draft state and will represent the employee responsible of the sale works
Another named Confirmed by to denote the employee responsbile of confirming the sale. The field should be set when confirming the sale if empty.
I think the employee should be set by the default with the following values:
With the current employee when the sale is manually created
With the opportunity employee when the sale is created from an opoprtunity.
Purchase
The behaviour should be very similar to sale on but the default value should be a little bit diferent:
The current employee should be used when the purchase is manually created
When creating a purchase from a purchase request the Wizard should ask for an employee to assign the newly created purchases. By default this field can be set with the current employee.
Invoice
I think only one employee field should be added to the invoices and it should be named Posted by. This field will set when posting the invoice if empty.
For me, it is not clear what means “responsible”. I think this should be thought a little bit more deeper. The design of the opportunity should not be taken as example as it was not really though at that time.
By the way, I think I would prefer to know “who did what”.
So it would be: Quoted by and Validated by. The Quoted by will be updated if the sale is reset to draft and quoted again.
I do not think it is workable. I would prefer to have no value so the purchase is free to be taken. But then we need a way to take it.
Maybe this responsible thing should not be in base module but only the unambiguous workflow fields.
I think it may be useful to also have Validated by even if it is not always filled.
We are interested in such feature.
How to keep employee who did the opportunity when the sale is created ? As i follow your suggestions Cédric, “quoted by” would be filled by the current employee quoting the sale… so you’ll loose the employee at the beginning of the sale.
To have commercial statistics we need to keep the employee linked to the opportunity at the beginning of the sale, not the employee responsible of the action on the sale (quoting, …) that could be a “backoffice” employee…
Well on the sale you will have the link to the opportunity and so the information about each step of the opportunity. I do not think it will be good to duplicate that information.
For me responsible is “who has to do the next step”.
Having the employee who did something is good for to have the full history but user should be able to know what has to do and which records are done by another employee.
Then we can have a wizard to assign task like described in:
In the case of a sale order, it is not clear for me.
At best it is only when the sale order is in draft because after that point, the management is about reacting to external even.
Also I think that in this case it is more about user than employee. Only users can make action on a document not employee.
So in such case the create_uid or write_uid for draft sale gives usually the proper information.
For me, it does not apply on sale order because it is about choosing what next to do and not about postponed action.
I find that this seems quite similar to the subscription process described in Chat functionnality on resources
I think what will be useful is to allow user to subscribe to document (and automatically subscribe them when they do changes) and unsubscribe if they want. Than we should have a menu entry or a tab or a filter which allow users to see only the document he is subscribed to.
I submitted Issue 8969: Add employee on some documents - Tryton issue tracker
I added employee for major state transition for which the employee may be accountable/responsible.
I did it only on document for which the employee may not be linked to a specific user (through external interface). So this excludes, I think, all the accounting document (for which it is more an audit feature that may be needed).
Also I did not include “cancel” state because I think it is not relevant and it may also prevent employee to acknowledge failure if they may be taken as responsible. So I think it is better to store only positive information (with the exception of the rejection of purchase request because the author may want to contact the rejecting employee).
Other points, I considered:
Adding employee on production work but I think with the timesheet the information may be stored differently
Adding invoice posting employee but indeed it is more about the user and auditing
What if the work does not have any timesheet information? This is possible when the work is mostly done by a machine so the employee only takes care of staring and ending the works. In this case it makes sense to store who started the process and who ending the process.
Not sure if we should store the employee per cycle so we have the full details in case of multiple cycles.