--- title: "What are price attributes, component codes and price structures?" canonical_url: "https://cognilium.ai/blogs/unified-pricing-management-price-attributes-components" slug: "unified-pricing-management-price-attributes-components" section: "blogs" date_published: "2026-08-05" date_modified: "2026-08-05" word_count: 1420 reading_time_minutes: 6 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: - "https://cognilium.ai/blogs/unified-pricing-management-concurrency-modes" - "https://cognilium.ai/blogs/unified-pricing-management-vs-pricing-management-module" - "https://cognilium.ai/blogs/dynamics-365-pricing-api-external-systems" --- # What are price attributes, component codes and price structures? Finance & Operations builds a selling price from four objects — price attributes, price component codes, price structures and concurrency modes — and adds base price to price adjustment to get there. Tier is Finance & Operations. Here is what each one is, in Microsoft's words, and the four you can only have one of. ## Key takeaways - Unified pricing management builds a selling price by adding a price adjustment to a base price, and the four objects exist to determine those two numbers. - Price attributes are the facts, component codes are the buckets rules are assigned to, price structures set the evaluation sequence, and concurrency modes resolve collisions inside a bucket. - You may have only one price component code for each base price type and one for sales trade agreement; every other component type is unlimited. - Maintenance mode is chosen at creation, becomes read-only on save, and decides whether the system generates attribute combinations for you or you author each one. - Combination rank breaks ties only when every competing rule in that component code uses the price attribute combination rank concurrency mode. ## What are price attributes, component codes and price structures? **Tier: Finance & Operations.** Four objects, four names that sound interchangeable and are not, and one of them silently decides who in your business can maintain pricing at all. ## Start with the arithmetic, because it is published From the [Unified pricing management module overview](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-management-overview) `[GA]` (`ms.date` **2026-04-20**, `updated_at` **2026-04-21**): > "The base price is the price before any price adjustments are made (*Base price* + *Price adjustment* = *Selling price*)." Everything below exists to determine two numbers on the left of that equation. The module is not a price list; it is a **calculation graph**, and the four objects are its parts. ## The four objects, in Microsoft's words - **Price attributes** — "Price attributes give you a flexible way to define your pricing factors. They use information about customers, products, sales order headers, and sales order lines." - **Price component codes** — "Price component codes group together price attributes. They represent the building blocks of your price structure. When you create a price and discount rule record, you also assign that record to a price component code." - **Price structures** — "Price structures help you understand the sequence of your price component codes." - **Concurrency modes** — "Concurrency modes control how the final price is calculated in situations where multiple pricing rules are associated with the same price component code." Read them as a hierarchy and the vocabulary stops being slippery. **Attributes are the facts.** Component codes are the buckets those facts sit in — and every pricing and discount rule you write is assigned to one. A price structure is the **order the buckets are evaluated in**. Concurrency modes settle fights **inside** one bucket, which is chapter 5. The [Price component codes](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-price-component-code) page (`ms.date` **2026-05-18**, `updated_at` **2026-07-01**) opens with the design intent stated more plainly than most vendor documentation manages: > "The goal of making pricing decisions is to increase profitability. Good decision making requires a thorough understanding of the different elements that determine the price." It also names what a price component code can carry: "Price component codes can define default values for posting and the discount concurrency mode." **Your default concurrency behaviour lives on the bucket**, and individual rules override it — which is why a change at code level moves prices in places nobody was looking. ## The rule most people meet the hard way There is a hard cardinality constraint, and it is a Note rather than a heading: > "You can have a maximum of one price component code record for each of the following price components: Base price - inventory price / Base price - purchase price / Base price - sales price / Sales trade agreement. You can have any number of price component code records for each of the remaining price components." **One sales base price component. One trade agreement component. Unlimited discount and margin components.** So a design that wants two parallel base-price regimes — say one per business unit inside a legal entity — cannot be expressed at that layer. The variation has to move into attributes and rules beneath the single component, or into separate price structures. Finding that out during a build is expensive; it is one Note on one page. ## Maintenance mode decides who owns pricing When you create a price component code you choose a **Maintenance mode**, and the page is explicit that this is permanent: "You can edit this field only for new records. (It becomes read-only when you save the record.)" > "*Separate* – You can assign a rank to each individual header and line attribute group. The system then automatically generates each possible combination of header and line attribute groups, and assigns a combined rank to each combination, based on your individual rankings." > "*Combined* – You can define each relevant combination of header and line attributes, and manually assign a combination rank to each of them." This is the real fork. **Separate** generates the combination matrix for you from two ranked lists — fast to set up, and it produces rows nobody explicitly asked for. **Combined** makes you write every combination and rank it by hand — slower, fully deliberate, and it scales badly. Choose Separate and pricing maintenance is a task a merchandiser can do. Choose Combined and it becomes a task somebody has to be trained for. That is an operating-model decision wearing the clothes of a configuration field, and it is read-only after save. ## How a tie between two reasonable rules is broken Microsoft states the problem honestly: > "In general, specific pricing rules (that is, rules that apply to a specific customer account and product number) take priority over more general rules … However, if two equally general rules apply (for example, a rule that targets a specific customer group and a rule that targets a specific region), it can be difficult to determine which rule should have priority." The answer is **combination rank**, and it applies only under two conditions, both quoted: > "- Multiple pricing rules in the same price component code apply to the same order line. - For all the qualifying rules, the **Concurrency mode** field is set to *Price attribute combination rank*." Then "the rule that matches the row with the highest **Combination rank** value applies." Microsoft's own worked example ranks a customer-group-and-product-group combination at 2002 and a market-segment-and-category combination at 1001, and selects the first — "Therefore, the price is $20." **Rank is not priority.** It is a number generated from two independent rankings you set, and it only decides anything when every competing rule is in that mode. ## What the structure does not contain Walk the four objects again as a list of inputs: customer facts, product facts, order header facts, order line facts, the order they are evaluated in, and the rule for resolving collisions. **Nothing in the four definitions above is an input about outcomes** — not what the customer accepted last quarter, not what the order would have converted at, not what this line costs you today. The structure is a complete and precise description of *how your rules combine*. It is silent on whether they are the right rules, and it is designed to be: Microsoft's own framing is that good decision making requires understanding the elements, and the module supplies the elements. ## How we build it: rules into the structure, never a second structure **Pricing & Discount Optimizer decides which pricing and discount rules earn the most margin across the book, re-plans them as demand and cost move, and writes them back as records against your existing price component codes — behind an approval step.** Into your structure, at your ranks, under your concurrency modes. An optimizer that needed its own price structure would be a second pricing engine, and you already have a capable one. **A working demo exists; it is not off the shelf.** We build it against your systems and your constraints on request, and we have no delivered pricing engagements — so this is a capability, not a report on somebody's business. We do not touch your ERP core, and the structure stays your implementation partner's. ## Three things to check this week 1. **Open each price component code and note its Maintenance mode.** It is read-only, it was chosen once, and it determines whether pricing maintenance is a merchandising job or an IT one. 1. **Read the default discount concurrency mode on every discount component code.** Rules inherit it unless overridden, so this is the setting with the widest blast radius in the module. 1. **Count your price structures.** If there is one per company and your commercial reality has more than one pricing regime, the single-base-price constraint above is already shaping your rules. Chapter 5 is what happens when two rules land in the same bucket. Chapter 6 is how to tell whether you are on this module at all. **About Cognilium** Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/ Runs Finance & Operations and want to know what your price structure is actually deciding? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck. ## Sources - [Unified pricing management module overview](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-management-overview) - [Price component codes](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-price-component-code) ## Sources - [learn.microsoft.com — upm pricing management overview](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-pricing-management-overview) - [learn.microsoft.com — upm price component code](https://learn.microsoft.com/en-us/dynamics365/supply-chain/unified-pricing-management/upm-price-component-code) --- Canonical HTML: https://cognilium.ai/blogs/unified-pricing-management-price-attributes-components