Unified Pricing Management in D365 FO: From Trade Agreements to Margin Adjustments

Pricing in Dynamics 365 Finance and Operations becomes more powerful when you understand how the pricing engine evaluates attributes, trade agreements, base prices,

and margin adjustments together. In this part of the series, we move from core concepts to practical pricing scenarios using Unified Pricing Management.

Who should read this? D365 Finance Functional Consultants, Solution Architects, Pricing Consultants, Business Analysts, and learners exploring Unified Pricing Management in D365 FO.

Creative UPM Pricing Flow

Think of Unified Pricing Management as a pricing engine journey: first it understands the order context, then it finds the right pricing rules, applies the pricing tree, resolves the base or trade agreement price, adjusts the margin, and finally calculates the sales price.

Contents

1. Recap from Part 1
2. What we cover in Part 2
3. Defining Trade Agreement Journals with Pricing Attributes
4. Creating a Journal Trade Agreement
5. Price Breakdown
6. Base Price and Trade Agreement Priority
7. Creating a Calculated Base Price in D365 FO
8. Margin Component Price Adjustments (MCPA)
9. Scenario: Simple MCPA
10. MCPA with Tiered Quantity
11. Multiple MCPA and Negative MCPA

Recap from Part 1

This Part 1 document introduces Unified Pricing Management in Dynamics 365 Finance and Operations as a centralized pricing framework across products, customers, channels, and order scenarios. It explains key concepts such as pricing attributes, attribute groups, price groups, and price component codes, and shows how they help the pricing engine find the most relevant rule. Later parts will cover base prices, trade agreements, margin adjustments, discounts, charges, and rebates in more detail.

It also summarizes how UPM calculates the final sales price by applying the base price, margin adjustments, discounts, charges, and rebates in sequence. The setup flow covers enabling Pricing Management, creating attributes and attribute groups, defining

price component codes, and building pricing trees. Overall, Part 1 establishes the core concepts and setup logic needed before moving into practical scenarios and deeper configuration.

What we cover in Part 2

In Part 2, we will focus on the following areas:

• Trade agreements with pricing attributes — how header and line attributes help determine the applicable trade agreement price.
• Base price setup — how purchase, sales, and inventory-related pricing inputs contribute to the base price.
• Calculated base price — how the system derives base price using vendor list price and vendor price term adjustments.
• Base price trade agreement priority — when trade agreements override base price and how the pricing tree controls evaluation.
• Margin Component Price Adjustments — how MCPA increases or decreases sales price without changing the base price.

Defining Trade Agreement Journals with Pricing Attributes

Navigation: Pricing Management > Setup > Trade Agreement Prices > Trade Agreement Journal Names

Creating a Journal Trade Agreement

Select the relevant journal and open Trade agreement journals to create a new journal

line. Unlike standard sales price trade agreement journals, this setup can evaluate pricing attributes at both the header level, such as customer and sales order attributes, and the

line level, such as product and sales order line attributes. In this example, the trade

agreement defines two price outcomes: $GGG per piece for UK/India when the color is Lime Green or Rose Pink, up to 10 pieces; and $G00 per piece for the US when the color is Rose Pink, up to 10 pieces.

 

Region	Color	Quantity	Price per piece
UK / India	Lime green / Rose Pink	Up to 10 pcs	$999
US	Rose Pink	Up to 10 pcs	$900

The Preview Customers and Products option show the possible customer and item combinations where the trade agreement can apply. From this list, you can exclude specific customers or products where the agreement should not be valid.

Once the trade agreement lines are posted, they can also be viewed under All Price Groups for the relevant header attribute, provided the price group is selected

With this setup complete, let’s create a sales order and review the Price Breakdown to

confirm which pricing component is applied.

Price Breakdown

Navigation: Sales Order > Line Level > Sales Order Line > View > Price

The first component in the pricing structure, Base Price, is derived from the trade

agreement. Price Breakdown helps confirm which pricing component was applied and why.

Next, we will remove the trade agreement from the pricing tree, prioritize the base price purchase component, and review how the calculated price changes on the sales order.

Changing the pricing tree

Disable the pricing tree and change the pricing component codes on the pricing tree.

Setting Up Base Price – Purchase

Navigation: Pricing Management > pre-sales pricing > Base Price versions

Click on the Base price and select active price tab to view the Base Price

Note: This Base price can also be calculated. This has been explained below.

Navigate back to the same sales order and check if the price is updated

Conclusion: In legacy, the system would always hunt for a trade agreement and fall back to base price automatically. In UPM, nothing is automatic — if it is not in the tree, it does not exist for pricing purposes.

For base price and trade agreement specifically (if both are available on the pricing tree

and trade agreement has a lower sequence), the sequence tells the engine the evaluation order — but the trade agreement always supersedes the base price when found. Think of base price as the fallback and trade agreement as the override.

Where sequence number really matters is when you have multiple components of the same type (e.g., two discount component codes), or when combining discounts, margin adjustments, and charges — that’s where sequence drives the compounding/calculation order.

Creating a Calculated Base Price in D365 FO

1.      Define vendor price term codes

Navigation: Pricing management > pre-sales pricing > Vendor price term codes

Vendor price term codes define reusable price adjustment rules that are applied on top of a vendor’s list price to help calculate the item base price.

Each code defines the calculation type, such as amount or percentage, the calculation

basis, such as vendor list price, and the pricing sequence that controls the order in which multiple terms are applied when compounded.

A code has been created for Base Price – Purchase.

Next, let’s apply this code through vendor price term agreements.

1.      Vendor price term agreements

Navigation: Pricing management > pre-sales pricing > Vendor price term agreements

Vendor price term agreements record the actual contractual price adjustments you’ve negotiated with a vendor, applied per site and validity period. They keep track of the

contracts you have with vendors for price adjustments for each site — valid periods, vendors, calculation methods, and values are all recorded. Each agreement header specifies the vendor, site, and date range, while the lines refer to a vendor price term code and set its actual percentage or amount value.

The Code created and the percentage for adjustments is defined.

Vendor list price

The vendor list price lets you record the general vendor price catalog and specify a valid date period, kept at the item and inventory dimensions level. It stands for the raw,

unadjusted price a vendor quotes for an item — the starting point before any term-code adjustments (freight, early-payment markups, etc.) are layered on.

For this example, the calculated Base Price – Purchase is derived as: List Price + Adjustment. For item iPhone 16, the calculation is $550 + 10% of $550 = $605.

Navigation: Pricing management > pre-sales pricing > Vendor list price

To generate the calculated sales price based on base price, navigate to Base Price Versions form

The Calculated Base Price can be generated

Note: Manufactured items would instead pull from an active standard cost version

Margin Component Price Adjustments (MCPA)

Margin price adjustments let you move item prices up or down from the base price. They can be associated with various agreements, promotions, and events, letting you adjust prices without touching the base price itself.

A key difference from quantity discounts is that MCPA quantity tiers are evaluated based on item quantity per sales order line, while quantity discount tiers are typically evaluated

based on item quantity per order. We will look at four practical cases:

1. Simple MCPA
2. MCPA with tiered Quantity
3. Multiple MCPA tied to an order
4. Negative MCPA

Setting up Pricing component code for MCPA

Navigation: Pricing Management > Setup > Price component codes

Create a new code for MCPA and define the Header and Line price attributes to create a price attribute combination.

If Multiple MCPA needs to be a part of Pricing tree, multiple codes for the Price component Margin Adjustment needs to be created

These codes then need to be a part of pricing tree.

Once these pricing component codes are set, the pricing rules for the same can be created.

 

Setting up Pricing rules for MCPA

Navigation: Navigate to Pricing management > During-sales pricing > Price adjustments > Margin component price adjustments and create a record

Here’s a rundown of the fields shown on this Margin component price adjustments

record (USMF-000001, “Seasonal Adjustment”):

Header fields

• Margin component adjustment – Unique ID for this rule (USMF-000001)
• Name – Descriptive name (“Seasonal Adjustment”)
• Publish status – Lifecycle state of the rule (Published = active/usable, Draft)
• Validation status – Whether the rule’s setup has passed validation checks (Validated)

General section

• Status – Enabled/Disabled toggle; only Enabled rules are used in price calculations, and a rule must be Disabled before it can be edited

 

• Currency – The currency this adjustment applies to (USD)
• Concurrency model – How the system handles multiple price adjustments hitting the same price component code (here: “Price attribute combination rank” is used to arrive at the best possible lower value). Other concurrency models available are Exclusive, Best Price and Compounded for Discounts but the model for MCPA is Primarily Price attribute rank combination.
• Quantity tiers – Whether the adjustment varies by quantity breaks (No = flat adjustment regardless of quantity)
• Pricing priority / Override priority – Lets this specific rule override the default priority order for resolving conflicts; toggle is off here so default priority is used
• Price component – The category type of this rule (Margin component — as opposed to Discount)
• Price component code – The specific code this rule feeds into, used to slot it into the price tree/sequence (“Margin Component Code”)
• Price attribute group – The group of customer/product attributes used to filter who this applies to (blank here since Header price attribute group type = All)
• Header price attribute group type – Whether this applies to All customers/Sales order just a defined Group (set to All, hence the note “Include all Header Attributes”)

Details section

• Description – Free text explaining the rule’s purpose
• Disclaimer – Text that can appear as a disclaimer, g., on quotes/invoices
• Text for fiscal receipt – Text printed on fiscal receipts (relevant for retail/POS scenarios)
• Header price attribute detail – Read-only summary of which header attribute values/filters are applied

Calculation section

• Pricing sequence – The rule’s position/order within the price tree (3) — determines when this adjustment is applied relative to base price, other adjustments, and

discounts

• Compound – Whether this adjustment compounds with other margin adjustments (multiplicatively) or applies independently/additively (No = not compounded)

 

What you can control per line is the Compound checkbox

• Compound = Yes → this adjustment calculates against the running total (base price

+ adjustments already applied)

• Compound = No → this adjustment calculates against the original base price, ignoring any prior adjustment

Validation period section– Would contain the effective from/To dates defining when this pricing rule is valid

Lines grid

• Line group type – Whether this line applies to a specific Group of products (via attributes) or to All products
• Line price attribute group – The attribute group used to filter matching items (here: “Product”)
• Price attribute detail – Read-only summary of the actual attribute filter/values applied (here: Color = Rose Pink)
• Combination rank – The rank assigned to this specific line’s attribute combination, used to resolve concurrency when multiple lines/rules could match the same order line
• Site – Restricts the adjustment to a specific inventory site (blank = all sites)
• Unit – The unit of measure this line’s adjustment applies to (ea. = each)
• Allow unit conversion – Whether the adjustment still applies if the order line uses a different, convertible unit of measure
• Calculation type – Whether the adjustment is a Percentage or a flat Amount
• Percentage – The adjustment value when Calculation type = Percentage (20.00%)
• Amount – The adjustment value when Calculation type = Amount (grayed out here since Percentage is used instead)

Scenario: Simple MCPA

 

Scenario	Code	Basis	Calculation	Expected Value
Base Price	1	Base Price explained above	Fixed Value	$605
Margin component price adjustment	2		Base price =603 + 20% of 605	$726

MCPA with Tiered Quantity: MCPA can also adjust sales price based on the quantity entered on each sales order line. This is important because the tier is evaluated at the line level, not at the total order level. Quantity tiers are enabled, and adjustments are defined using minimum quantity and percentage values.

 

Let’s create a sales order and review the price breakdown for each line.

Line 1

 

Scenario	Code	Basis	Calculation	Expected Value
Base Price	1	Base Price explained above	$605*2	$1210
Margin component price adjustment	2		10% of Base= $121	$1331

 

Line 2

Scenario	Code	Basis	Calculation	Expected Value
Base Price	1	Base Price explained above	$605*3	$1815
Margin component price adjustment	2		5% of $1815	$1905.75

 

Multiple MCPA

Multiple MCPAs are useful when different margin adjustments must apply together for a specific business scenario or limited period. The setup is like the previous MCPA example, but each margin component price adjustment should have its own component code and corresponding line in the pricing tree.

Note: The customer/product/both attributes should be valid in the MCPA to trigger on the order.

The Pricing Tree

The pricing tree includes two different margin component codes with compounding

enabled. The adjustment calculated from the first code becomes the basis for calculating the second adjustment.

In the sales order, multiple MCPAs are applied based on the pricing rules and margin component codes configured in the pricing tree.

Note: Negative MCPA is also possible when the pricing adjustment rule is configured with a negative amount or percentage.

Note: The unit price cannot be negative.