Stephen Swanson BDO Digital Managing Director - Microsoft Business Applications Enablement

In the Tech Talk it seemed everything in the demo had to do with the Order to Cash/Sales side of trade to supply pricing, discounts, rebates, etc. to customers on sales transactions. 80%+ of the functionality demonstrated is needed on the Source to Pay/Procurement side in managing pricing and rebates with Vendors. It is great to see the progress on the sales side but without nearly the identical functionality on the Vendor side this does not meet the needs of most Distributors and many Retailers.

This also includes providing the various Pricing Attributes functionality on both the Customer and Vendor side as well. Here is an example that shows the extent of the capabilities leveraging both the Customer and Vendor side together for what is referred to as a "pass through rebate".

• In this example the organization using D365 is the Distributor. A computer manufacturer sells their computers normally to the Distributor at $1,000 a piece. Rebates are not determined during the procurement transaction. When the Distributor sells these laptops to their Retailers the Manufacturer has made an agreement with the Retailer and Distributor that for Retailer A they will provide a $50 rebate per laptop but for Retailer B they have approved a $100 rebate. Upon the Sales Invoice being posted a Customer Discount (included in price) or Rebate (accrued for later consumption) will be generated for the $50 or $100 according to the Retailer. At the same time a Vendor Rebate will be generated to accrue the receivable from the Vendor for each of the laptops sold for $50 or $100 according to which Retailer purchased the goods. The Customer Discount/Rebate is funded by the Pass Through Rebate with the Vendor. This would need to be supported for both inventory that has been received by the Distributor as well as inventory that is on Vendor Consignment that is still on the Vendor's balance sheet until sold.

A very common requirement that comes up on many projects and especially wholesale distributors is the need to store and see sub-totals along the various levels within the Pricing Tree. I view the Pricing Tree as essentially the Costing Sheet for Standard Cost but the Pricing Tree is for how the Selling Price has been calculated.

Here is an example:

Let's say we buy something for $1,000 from the Vendor. The company decides they want to utilize two Margin Components to Mark Up the Cost along the way to the final selling Price. They determine they want one for 10% to cover corporate Procurement and Marketing expenses and another 2% for inbound Freight. They would like to see this $1,120 as a sub-total in the Pricing Tree labelled as "Sales Cost". This Sales Cost is what the salespeople are allowed to see and all commissions and store level profitability is calculated from Sales Cost to Selling Price instead of all the way back to the actual Financial Cost. Some organizations require to display some of these sub-totaled layers in the Pricing Tree on reports and invoices so it would need to be a stored value to utilize in reporting. Additionally, they often want to allow further Discounts, Rebates, etc. pointing at one of these named/stored Sub-Totals. For example, the customer might get 24% markup from Sales Cost but then 2% off Selling Price for using the private label credit card and a 5% Vendor Rebate leverage another layer in the Pricing Tree.

• Allow for the insertion of named Sub-Totals in the Pricing Tree
• Store these Sub-Totals to leverage on reports and other processes
• Allow these various Sub-Totals to be pointed at throughout other Pricing Elements so the Margin Components, Discounts, Rebates, etc. can access different layers of the Pricing Tree.