Aydınlatma metni yükleniyor…
Managing dealer-specific prices and discounts in a B2B portal involves more than showing a different number to each company. At order time, the system may need to evaluate the company and location, product eligibility, active contract, quantity tier, campaign, currency, effective time and manual authority. The essential output is not only the net amount. It is an explainable result that can be reproduced from the same inputs.
This guide helps B2B sales and ecommerce teams define pricing-rule scope. The “Kumsal pricing decision stack” and acceptance-test matrix are original planning tools created for this article. They do not recommend a particular product, report a Kumsal Agency client result or guarantee commercial performance.
Separate a price from a discount
A price is the starting or contracted unit amount in a given context. A discount is a commercial adjustment applied to an eligible amount. “Twenty per cent off list” and “contracted net price of 800” are not equivalent rules. The former changes when the source price changes; the latter may remain fixed for its effective period.
A campaign, quantity break, payment-method adjustment, coupon, sales-representative concession and contracted price may all appear in one basket, yet require different ownership and conflict behaviour. Compressing every decision into one discount-percentage field makes it difficult to explain the outcome or identify who changed it.
Define the pricing context before calculating
The correct price cannot be derived from the product code alone. Establish the calculation context first:
- Dealer company, company location, purchasing account and user role
- Sales channel, country or region, currency and tax-display preference
- Product, variant, pack or unit and sales eligibility
- Order quantity, basket conditions and requested fulfilment date
- Contract, price list, segment and campaign membership
- Calculation time, effective period and source-data revision
A dealer company and its purchasing location are not always the same pricing object. A master agreement may cover every location, or one delivery account may have a distinct price. Attach pricing context to the commercial account and location rather than merely the login name.
The Kumsal pricing decision stack
Describing the engine as consecutive decision layers rather than one long formula helps business, ERP and development teams discuss the same result. The sequence below is not a universal standard. It is a scoping framework to adapt to the commercial model.
| Layer | Decision | Evidence to retain | Behaviour when unresolved |
|---|---|---|---|
| 1. Identity and context | Which company, location, channel and currency? | Account/location ID and calculation time | Complete context before exposing a price |
| 2. Product eligibility | Can this dealer buy the product, variant and pack? | Catalogue and restriction revision | Hide or block with a reason |
| 3. Source price | Does contract, location, segment or general list win? | Winning record and priority | Defined fallback; never silently estimate |
| 4. Quantity rule | Are minimum, increment and volume tier satisfied? | Applied tier and unit of measure | Explain the valid quantity |
| 5. Discount conflict | Is the rule best-price, compound or exclusive? | Winning and rejected rule IDs | Do not apply undefined combinations |
| 6. Authority and floor | Does a manual change exceed authority or a boundary? | User, reason and approval status | Route for approval without changing price |
| 7. Final calculation | What are the precision, currency and line/basket allocation? | Intermediate values and rounding policy | Reject rather than display an approximation |
| 8. Order snapshot | How is this result preserved in the order? | Pricing revision, rule summary and net amount | Reprice and request confirmation after change |
With this stack, a “wrong dealer price” report is not investigated from the displayed number alone. Teams can see the received context, eligible records, winning priority and any rejected discount.
How should special-price precedence work?
A product may have a contracted net price, company catalogue, location list, dealer-segment price and general list at the same time. Decide whether “lowest price wins”, “most specific record wins” or another explicit policy applies. A contract can be exclusive for one range while a quantity adjustment remains valid on contracted prices elsewhere.
Microsoft Dynamics 365 Commerce price-management documentation describes price groups that associate prices with entities such as channels, catalogues and customers. It also documents pricing priority as a way to evaluate higher-priority records before lower-priority candidates. This is an implementation example rather than a product recommendation. It demonstrates why multiple eligible records need a deliberate selection rule.
Priority should be accompanied by scope, effective period, product level, customer level, currency, system of record and fallback behaviour. If two records collide at the same priority and effective period, rejecting the release for correction is safer than selecting a hidden winner by creation order.
Classify discounts as best-price, compound or exclusive
Two eligible percentage discounts do not automatically add together. Give each rule one of three explicit behaviours:
- Best-price: only the winner under the defined comparison is applied.
- Compound: multiple adjustments apply in a specified order and against a specified base.
- Exclusive: once the rule applies, no other rule in the defined scope may join it.
For compounded percentages, order and calculation base affect the result. Ten and twenty per cent deducted independently from the original amount do not produce the same net price as applying the second adjustment to the remaining amount. Microsoft's Commerce pricing-settings documentation likewise separates best-price and compound competition within or across priorities, and distinguishes compounding on the remaining amount from calculating adjustments against the original price.
A campaign record should therefore contain more than a percentage: behaviour type, priority, compatible rule families, calculation base, maximum effect and effective period. A new promotion should not unexpectedly combine with every existing dealer concession.
Do not confuse quantity rules with volume pricing
Minimum order quantity, purchase increment and maximum quantity are eligibility rules. Volume pricing is a new unit amount or adjustment reached at a defined quantity. An item may be sold only in packs of 12 and receive an additional price break at 60 units. When selling and inventory units differ, record the unit used to evaluate each threshold.
Shopify's B2B quantity-rule and volume-pricing documentation configures minimum, maximum and increment values separately from volume price breaks, and evaluates volume pricing against variant quantities. Its B2B catalogue documentation also illustrates how multiple catalogues can be assigned to a company or location and why overlapping product prices require defined selection behaviour. These are platform-specific examples; the project policy must reflect the organisation's contracts and sales model.
Use the same inputs across product page, basket and ERP
If the product page produces one price, the basket another and ERP a third, the buyer cannot know which commitment is valid. A project may use one central pricing service or separate systems implementing the same rule package. In either case, inputs and revisions need a shared contract.
Product listings may show a precomputed value for performance. The basket should re-evaluate quantity, account location, campaign and contract currency. During ERP transfer, compare the portal explanation with the ERP result. When they differ, apply a defined tolerance, repricing and user or approval flow instead of silently saving a different amount. Use our ecommerce–ERP integration guide to assign ownership for product, inventory, price, order and error data.
Define price locks and repricing triggers
How long a basket price remains valid depends on the commercial model. A contracted net price might remain effective through the day, a currency-linked record may have a shorter window, and a draft order might require recalculation before approval. Neither “a basket price never changes” nor “recalculate on every page view” is universally correct.
When a price changes, expose the earlier amount, new amount, changed rule and required buyer action. Store the price and discount record identities and revisions with the order—not merely the final net amount—so returns, disputes and reconciliation can reconstruct the decision made at purchase time.
Keep credit limits separate from price calculation
Calculating the correct dealer price and allowing a purchase on account are separate decisions. Credit limit, overdue balance, payment method and risk hold belong to payment or order acceptance. If credit is unavailable, the system can disable account terms, request partial payment or route for authorised review without changing the product price.
This separation lets teams answer “why did the price change?” and “why was the order rejected?” with different evidence. Authorised business owners must approve financial-limit and risk policies; this guide is not accounting, credit or legal advice.
Version every pricing-rule change
Keeping only the current rule is insufficient. Retain start and end time, draft–approved–active–expired states, change reason, maker and approver, and affected product/dealer scope. A historical order can calculate differently under today's rules; review depends on the revision that was active for the transaction.
Bulk price imports should produce a validation report. Separate unknown products, duplicate records, overlapping dates, invalid currencies, blank or negative values, floor breaches and unexpectedly large changes. Test a sample of dealer and basket combinations before activation rather than discovering a wide error after release.
Write acceptance tests around real rule conflicts
The following scenarios test an illustrative policy; they are not real commercial rates or priorities. Keep test data, expected result and explanation together.
| Scenario | Expected behaviour | Evidence checked |
|---|---|---|
| Product-specific contracted net price exists | Segment list is rejected; contract exclusivity policy applies | Winner, priority and effective period |
| Two catalogues are assigned to one company location | Defined specificity or priority rule selects a deterministic winner | Candidate catalogues and rejection reason |
| Quantity break and campaign are both eligible | One explainable result follows best-price, compound or exclusive policy | Calculation sequence and intermediate values |
| Order quantity violates the pack increment | Engine explains valid increment and minimum rather than pricing invalid quantity | Unit conversion and quantity rule |
| Manual discount exceeds user authority | Unauthorised price is not applied; request goes to approval with a reason | User limit and approval state |
| Calculation occurs exactly at a rule boundary | Time zone and inclusive/exclusive decision apply consistently | Timestamp and rule revision |
| Price changes between basket and order | Difference is visible; repricing and confirmation policy runs | Old/new revision and buyer decision |
| ERP returns a different net amount | Order is not silently changed; tolerance or exception queue runs | Portal result, ERP result and disposition |
What should a dealer-pricing proposal include?
- Pricing context, company/location model and catalogue scope
- Price types, precedence matrix and effective-period rules
- Quantity, pack, volume and minimum-order behaviour
- Discount conflict, compounding, exclusivity and authority policies
- Currency, precision, rounding and price-lock approach
- ERP ownership, recalculation, tolerance and exception queue
- Rule revisions, bulk imports, approvals and audit trail
- Acceptance tests, pilot scope, monitoring and operating owners
A proposal that only promises “dealer-specific pricing” cannot be tested. Require at least a precedence matrix, conflict policy, example calculation explanation and end-to-end acceptance scenarios.
Conclusion: the explanation is part of the price
Dependable dealer pricing does not invisibly pile contract, catalogue, quantity, campaign and manual concessions together. Define the scope, priority, compatibility, effective period and owner of each rule. Given the same inputs, the order should produce the same explainable decision.
Start with the pricing decision stack and conflict table, then test real basket combinations. To scope dealer-portal pricing, ERP connectivity and management workflows together, explore Kumsal Agency ecommerce services.
Managing dealer-specific prices and discounts in a B2B portal involves more than showing a different number to each company. At order time, the system may need to evaluate the company and location, product eligibility, active contract, quantity tier, campaign, currency, effective time and manual authority. The essential output is not only the net amount. It is an explainable result that can be reproduced from the same inputs.
This guide helps B2B sales and ecommerce teams define pricing-rule scope. The “Kumsal pricing decision stack” and acceptance-test matrix are original planning tools created for this article. They do not recommend a particular product, report a Kumsal Agency client result or guarantee commercial performance.
Separate a price from a discount
A price is the starting or contracted unit amount in a given context. A discount is a commercial adjustment applied to an eligible amount. “Twenty per cent off list” and “contracted net price of 800” are not equivalent rules. The former changes when the source price changes; the latter may remain fixed for its effective period.
A campaign, quantity break, payment-method adjustment, coupon, sales-representative concession and contracted price may all appear in one basket, yet require different ownership and conflict behaviour. Compressing every decision into one discount-percentage field makes it difficult to explain the outcome or identify who changed it.
Define the pricing context before calculating
The correct price cannot be derived from the product code alone. Establish the calculation context first:
- Dealer company, company location, purchasing account and user role
- Sales channel, country or region, currency and tax-display preference
- Product, variant, pack or unit and sales eligibility
- Order quantity, basket conditions and requested fulfilment date
- Contract, price list, segment and campaign membership
- Calculation time, effective period and source-data revision
A dealer company and its purchasing location are not always the same pricing object. A master agreement may cover every location, or one delivery account may have a distinct price. Attach pricing context to the commercial account and location rather than merely the login name.
The Kumsal pricing decision stack
Describing the engine as consecutive decision layers rather than one long formula helps business, ERP and development teams discuss the same result. The sequence below is not a universal standard. It is a scoping framework to adapt to the commercial model.
| Layer | Decision | Evidence to retain | Behaviour when unresolved |
|---|---|---|---|
| 1. Identity and context | Which company, location, channel and currency? | Account/location ID and calculation time | Complete context before exposing a price |
| 2. Product eligibility | Can this dealer buy the product, variant and pack? | Catalogue and restriction revision | Hide or block with a reason |
| 3. Source price | Does contract, location, segment or general list win? | Winning record and priority | Defined fallback; never silently estimate |
| 4. Quantity rule | Are minimum, increment and volume tier satisfied? | Applied tier and unit of measure | Explain the valid quantity |
| 5. Discount conflict | Is the rule best-price, compound or exclusive? | Winning and rejected rule IDs | Do not apply undefined combinations |
| 6. Authority and floor | Does a manual change exceed authority or a boundary? | User, reason and approval status | Route for approval without changing price |
| 7. Final calculation | What are the precision, currency and line/basket allocation? | Intermediate values and rounding policy | Reject rather than display an approximation |
| 8. Order snapshot | How is this result preserved in the order? | Pricing revision, rule summary and net amount | Reprice and request confirmation after change |
With this stack, a “wrong dealer price” report is not investigated from the displayed number alone. Teams can see the received context, eligible records, winning priority and any rejected discount.
How should special-price precedence work?
A product may have a contracted net price, company catalogue, location list, dealer-segment price and general list at the same time. Decide whether “lowest price wins”, “most specific record wins” or another explicit policy applies. A contract can be exclusive for one range while a quantity adjustment remains valid on contracted prices elsewhere.
Microsoft Dynamics 365 Commerce price-management documentation describes price groups that associate prices with entities such as channels, catalogues and customers. It also documents pricing priority as a way to evaluate higher-priority records before lower-priority candidates. This is an implementation example rather than a product recommendation. It demonstrates why multiple eligible records need a deliberate selection rule.
Priority should be accompanied by scope, effective period, product level, customer level, currency, system of record and fallback behaviour. If two records collide at the same priority and effective period, rejecting the release for correction is safer than selecting a hidden winner by creation order.
Classify discounts as best-price, compound or exclusive
Two eligible percentage discounts do not automatically add together. Give each rule one of three explicit behaviours:
- Best-price: only the winner under the defined comparison is applied.
- Compound: multiple adjustments apply in a specified order and against a specified base.
- Exclusive: once the rule applies, no other rule in the defined scope may join it.
For compounded percentages, order and calculation base affect the result. Ten and twenty per cent deducted independently from the original amount do not produce the same net price as applying the second adjustment to the remaining amount. Microsoft's Commerce pricing-settings documentation likewise separates best-price and compound competition within or across priorities, and distinguishes compounding on the remaining amount from calculating adjustments against the original price.
A campaign record should therefore contain more than a percentage: behaviour type, priority, compatible rule families, calculation base, maximum effect and effective period. A new promotion should not unexpectedly combine with every existing dealer concession.
Do not confuse quantity rules with volume pricing
Minimum order quantity, purchase increment and maximum quantity are eligibility rules. Volume pricing is a new unit amount or adjustment reached at a defined quantity. An item may be sold only in packs of 12 and receive an additional price break at 60 units. When selling and inventory units differ, record the unit used to evaluate each threshold.
Shopify's B2B quantity-rule and volume-pricing documentation configures minimum, maximum and increment values separately from volume price breaks, and evaluates volume pricing against variant quantities. Its B2B catalogue documentation also illustrates how multiple catalogues can be assigned to a company or location and why overlapping product prices require defined selection behaviour. These are platform-specific examples; the project policy must reflect the organisation's contracts and sales model.
Use the same inputs across product page, basket and ERP
If the product page produces one price, the basket another and ERP a third, the buyer cannot know which commitment is valid. A project may use one central pricing service or separate systems implementing the same rule package. In either case, inputs and revisions need a shared contract.
Product listings may show a precomputed value for performance. The basket should re-evaluate quantity, account location, campaign and contract currency. During ERP transfer, compare the portal explanation with the ERP result. When they differ, apply a defined tolerance, repricing and user or approval flow instead of silently saving a different amount. Use our ecommerce–ERP integration guide to assign ownership for product, inventory, price, order and error data.
Define price locks and repricing triggers
How long a basket price remains valid depends on the commercial model. A contracted net price might remain effective through the day, a currency-linked record may have a shorter window, and a draft order might require recalculation before approval. Neither “a basket price never changes” nor “recalculate on every page view” is universally correct.
When a price changes, expose the earlier amount, new amount, changed rule and required buyer action. Store the price and discount record identities and revisions with the order—not merely the final net amount—so returns, disputes and reconciliation can reconstruct the decision made at purchase time.
Keep credit limits separate from price calculation
Calculating the correct dealer price and allowing a purchase on account are separate decisions. Credit limit, overdue balance, payment method and risk hold belong to payment or order acceptance. If credit is unavailable, the system can disable account terms, request partial payment or route for authorised review without changing the product price.
This separation lets teams answer “why did the price change?” and “why was the order rejected?” with different evidence. Authorised business owners must approve financial-limit and risk policies; this guide is not accounting, credit or legal advice.
Version every pricing-rule change
Keeping only the current rule is insufficient. Retain start and end time, draft–approved–active–expired states, change reason, maker and approver, and affected product/dealer scope. A historical order can calculate differently under today's rules; review depends on the revision that was active for the transaction.
Bulk price imports should produce a validation report. Separate unknown products, duplicate records, overlapping dates, invalid currencies, blank or negative values, floor breaches and unexpectedly large changes. Test a sample of dealer and basket combinations before activation rather than discovering a wide error after release.
Write acceptance tests around real rule conflicts
The following scenarios test an illustrative policy; they are not real commercial rates or priorities. Keep test data, expected result and explanation together.
| Scenario | Expected behaviour | Evidence checked |
|---|---|---|
| Product-specific contracted net price exists | Segment list is rejected; contract exclusivity policy applies | Winner, priority and effective period |
| Two catalogues are assigned to one company location | Defined specificity or priority rule selects a deterministic winner | Candidate catalogues and rejection reason |
| Quantity break and campaign are both eligible | One explainable result follows best-price, compound or exclusive policy | Calculation sequence and intermediate values |
| Order quantity violates the pack increment | Engine explains valid increment and minimum rather than pricing invalid quantity | Unit conversion and quantity rule |
| Manual discount exceeds user authority | Unauthorised price is not applied; request goes to approval with a reason | User limit and approval state |
| Calculation occurs exactly at a rule boundary | Time zone and inclusive/exclusive decision apply consistently | Timestamp and rule revision |
| Price changes between basket and order | Difference is visible; repricing and confirmation policy runs | Old/new revision and buyer decision |
| ERP returns a different net amount | Order is not silently changed; tolerance or exception queue runs | Portal result, ERP result and disposition |
What should a dealer-pricing proposal include?
- Pricing context, company/location model and catalogue scope
- Price types, precedence matrix and effective-period rules
- Quantity, pack, volume and minimum-order behaviour
- Discount conflict, compounding, exclusivity and authority policies
- Currency, precision, rounding and price-lock approach
- ERP ownership, recalculation, tolerance and exception queue
- Rule revisions, bulk imports, approvals and audit trail
- Acceptance tests, pilot scope, monitoring and operating owners
A proposal that only promises “dealer-specific pricing” cannot be tested. Require at least a precedence matrix, conflict policy, example calculation explanation and end-to-end acceptance scenarios.
Conclusion: the explanation is part of the price
Dependable dealer pricing does not invisibly pile contract, catalogue, quantity, campaign and manual concessions together. Define the scope, priority, compatibility, effective period and owner of each rule. Given the same inputs, the order should produce the same explainable decision.
Start with the pricing decision stack and conflict table, then test real basket combinations. To scope dealer-portal pricing, ERP connectivity and management workflows together, explore Kumsal Agency ecommerce services.