Setting Different Prices for Dealers and Retailers with Price Lists

Every distributor sells the same product at different prices. The dealer buys a carton cheaper than the retailer, the retailer buys cheaper than a walk-in customer, and your biggest dealer has a special rate on two products that nobody wrote down. When those prices live in people's heads, you get three problems: officers quoting different rates, invoices that do not match the quote, and margin leaking because nobody knows who is on which rate. Price lists in gamitrack fix this by deciding the price at the moment the order is created. This guide explains the logic and how to set it up.

How price resolution works

When an order line is created for a party and a product, gamitrack looks for a price in three layers, in this order:

1. Override. A price set for this specific party and product.
2. Party type. The price on the price list for the party's type, for example dealer or retailer.
3. Default. The company's default price list.

The first match wins. That means you can keep one default price for everyone, add a cheaper type-level list for dealers, and add a few overrides for the handful of accounts that have negotiated terms.

This layering is the secret to staying sane. You maintain the default list thoroughly, and everything else is an exception. If you ever wonder why a price came out the way it did, the answer is always one of those three layers.

Step 1: Decide your price structure

Before touching the screen, write down your price ladder on paper. A hypothetical example for one product, a 500 g pack:

Customer	Price per pack
Default (walk-in, unclassified)	Rs 120
Retailer	Rs 112
Dealer	Rs 104
Special dealer override	Rs 101

These are invented numbers for illustration. The structure is what matters: each step down needs a business reason, such as volume, payment terms or territory exclusivity.

Step 2: Set up the default price list

Open Products, and under each SKU set the default price. Complete this for every active product before anything else. If the default is missing, an order for a party without a specific price has nothing to fall back on.

Step 3: Create party-type lists

Next, define prices for the party types you use, usually dealer and retailer. You do not need to repeat every product. Enter prices only where the type price differs from the default; the rest falls through to the default.

Keep the ladder logical. If your dealer price is higher than your retailer price on any SKU, you have either a typo or an arbitrage opportunity for a clever customer.

Step 4: Add overrides sparingly

For a dealer who has a negotiated rate, open that party and add an override for the product. Write down why in the party's internal notes. Internal notes are visible to staff and never visible to dealers, so you can record the reason, such as "agreed for Q2 volume".

A good test: if you have more than a handful of overrides per dealer, your type lists are wrong. Consider creating a new party type instead.

Step 5: Check an order end to end

Create a test order for a retailer and for a dealer, each with the same products. Confirm that:

• the retailer's lines show the retailer price,
• the dealer's lines show the dealer price,
• the override customer shows the override on that product only,
• VAT is added only to taxable lines.

Then dispatch a test order to see the invoice line match the order line. Prices are fixed on the order, so a later change in the price list does not rewrite orders already taken. That is important for trust with dealers.

Step 6: Communicate the change

Tell officers they no longer quote prices from memory: the app shows the right price at the point of order. Tell dealers the same, with the effective date. When a dealer orders in the app and the rate matches what was agreed, the old argument disappears. The dealer app is described in how dealers order and track.

When to change prices

Prices need a calendar. Review quarterly, or when input costs change. For a change:

1. Prepare the new list and effective date.
2. Announce to dealers and officers a week ahead.
3. Update the price list on the effective date.
4. Check the first day's orders for anything unexpected.

Avoid changing prices mid-week; it confuses orders already promised.

Pricing versus schemes

A price list is the base price. A scheme is a reward for behaviour, such as buying a target volume. Do not mix them. If you want to give a dealer a better deal for hitting a monthly volume, use a tiered scheme whose rewards are credited to the dealer's ledger, rather than cutting the list price for everyone. See designing dealer schemes that pay for themselves.

Common mistakes

• Too many lists. Each additional list is a new thing to maintain. Start with default, dealer, retailer.
• Missing default. Always price everything at default first.
• Overrides without a reason. Six months later nobody remembers why.
• Discounting in the field. If officers can discount at will, the price list is decorative.

Quick audit checklist

Check	Frequency
Every active SKU has a default price	Monthly
Dealer price below retailer price on all SKUs	Quarterly
Overrides each have a note and a reason	Quarterly
A test order for each party type prices as expected	When rates change

A worked scenario (hypothetical)

Imagine a company with three dealers and two hundred retailers. One dealer, who covers a large district and pays within the due days, has an agreed lower rate on two fast-moving SKUs. You create one override for each of those two products on that dealer's party record, and a note explaining the agreement and its review date. The other two dealers stay on the dealer list. A retailer who graduates to dealer status is simply changed to the dealer party type, and the dealer list takes over. No order form, no spreadsheet and no rate card has to be re-issued.

Next steps

Price lists work from the first order and need no extra setup beyond the catalogue. Compare plans on the pricing page, and see the product and price-list articles in the Help centre.