Comments
This should be an automatic input.When entering a Sales order, the "Sales responsible" on the sales order will be the "employee responsible" on the customer account. If the employee responsible is meant for another function then there should be space to hard code the Sales Responsible against the customer master record. Otherwise the administrator has to open the customer record to find this information.
The current approach with the sales unit being price-sensitive is a good approach to persuade customers to buy full packages.Still, your idea is good to reduce the management work of trade agreements and the risk of functional inconsistencies when above scenario is not desired by a company.Therefore, I believe there should be a parameter to switch between the two logics, such as an "Allow unit conversion" checkbox in the trade agreement journal line details fast-tab, which will be considered by the "Find next" checkbox.
There is a very big need for this, dealing with a customer that has this need at the moment... (Just google and see how many discussion threads there are for this topic going back to the NAV days) Had a look and couldn't find an extension on AppSource with this feature. This is seriously something to re-consider adding to the standard app.They have a lot of orders that is invoiced upon shipment, goods take a couple of weeks to arrive... Items are serial tracked... This means that if they try to use pre-payments the workload is just way too much, and trying to keep track of the invoices is twice as difficult as now you have 2 x BC invoices per order. Creating a different warehouse, receiving into that warehouse, and doing a transfer order to the actual warehouse complicates the stock planning process way too much, and is nearly impossible with serial tracking.
To reiterate Peter Frei's comment, it's the difference between a user inadvertently writing bad data to one record and the same user inadvertently writing bad data to thousands of records. You assume all users are as careful and deliberate as programmers and developers. Experience in the real world proves otherwise.