-
-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track Sales Person that Raised a Sale vs the one that created the invoice #4318
Comments
I don't understand this point. The fact that this user gets recorded isn't hard-coded: the person entering the invoice can select another sales person. |
Ok, to clarify, the point is that we should be recording the "entering user" as well as the "Sales User" for all invoices. In many cases this will be the same person, but in some cases this will be two different people. MANUAL selection of the sales user should be a last resort to be used only when the order user etc isn't available |
What do we need the entering user for? Is it that the invoice is a financial transaction and that those need to be auditable? |
That's part of it yes. If the entering person is not the sales person then it's going to matter that you are coaching the correct person |
@sbts You are aware that all INSERT/UPDATE/DELETE/etc actions on the AR/AP/GL tables are logged in the In that sense, I think this enhancement has been realized already. |
Ok. That works as far as tracking it goes. I'll have a play when back at home next week to offer a more coherent comment |
There's no presentation at this time of the various modifications of an invoice (including creation), but if that is the actual request, that totally changes the nature of the feature request at hand. |
I would like to propose a different approach to handling this issue -- having a "default" sales person for a credit account. In our scenario, we are obligated to pay a sales commission on all actual receipts for a particular set of customers for 2 years. I would like to be able to set a "Salesperson" on the ECA for these customers -- this should be entirely optional. When a sales order is created, it should set the salesperson to the default for the ECA if it exists, or the current user if it does not. When an invoice is created, it should set the salesperson to the value in the sales order first, and if that's not set/doesn't exist, the default sales person for the ECA, and only if that's not set, the current user. (Might be nice to even have a permission on this, for who is allowed to override the salesperson on an order). I see that you can filter on invoices by sales person. So one more step is needed to fully set this up for what I need: enhance the Cash -> Reports -> Receipts screen to report on actual receipts for a time period per sales person. (Or create a new report for this somewhere...) @sbts would that design meet your needs? |
Closing: more than 90 days without user response. Feel free to reopen with your comments. |
Currently the only user that created an invoice is recorded against the invoice.
In reality we probably should also directly record the person that raised the sale.
ie: The sales person that raised the sale may not be the person entering the invoice and tracking who generated the sale is required to properly handle calculation of bonus payments etc.
I propose we add a field to the invoice screen showing the initiating sales person.
This field should default to
This field should them be stored against the invoice
For example, Sales Team member Jack raises a sales order but Admin staff member Jill receives the PO, and converts the Sales order to an invoice.
Currently this is "sort of" possible as long as there was a sales order generated and the invoice is directly created from the order.
If the above is true, the order number can be used to look up the sales person.
However, the above doesn't work if the sales person provides the goods, or list of goods, and prices to the person entering the invoice via some other means.
The text was updated successfully, but these errors were encountered: