Pricing

Miridia keeps two pricing concepts apart. The price history records what a product costs and is worth over time. A price list holds a different price for a specific context. With this separation, one product can have one price on the web store, a different price for a trade customer, and a third price at one branch. You do not copy the catalogue.

The price history

The price history is the default price of a product. Each change adds a new entry. Miridia never changes or deletes an entry. Read Products for the fields of an entry.

If no price list applies to an order line, Miridia uses the most recent selling price in the price history.

Price lists

A price list is a named set of price overrides. It has:

• a title and a description
• a currency
• a status: Active or Inactive
• an effective window, with a start date and an optional end date
• a pricing mode: Fixed or Relative

A price list holds only the products whose price is different from the default. If you have 500 products and 30 have a regional price, the list has 30 items, not 500.

Pricing modes

• Fixed: each item gives its own price.
• Relative: the list applies an adjustment to the default price. The adjustment type is Percentage or Amount. You can also set a rounding step, for example 0.50.

Each item has a basis. A Fixed item has its own price. A Pegged item follows the default price with its own adjustment.

To stop a list for a period, set its status to Inactive. You do not have to delete it.

Scopes and assignments

You assign a price list to one or more scopes. An assignment is separate from the list. Thus one list can serve many scopes.

Which price wins

More than one list can apply to an order line. Each assignment has a priority number. The lowest number wins.

The merchant sets the number. Miridia does not score the lists by how specific they are. A number that a person sets gives a result that the person can predict.

Miridia follows these rules to resolve a price:

1. Find the active price lists that are assigned to the context of the order line, inside their effective window.
2. Select the assignment with the lowest priority number.
3. In that list, a price for a product group member wins over a price for the parent product.
4. If no list has a price, use the most recent entry in the price history.
5. If no source has a price, the resolve endpoint returns 404.

A worked example

A business sells a notebook with a default selling price of R89.00. It has two price lists.

• A retail customer in Cape Town pays R89.00. No list applies, thus the price history gives the price.
• A retail customer in Gauteng pays R95.00. Only the Gauteng list applies.
• A trade customer in Gauteng pays R80.00. Both lists apply, and the Trade list has the lower priority number.

To test a result, call the resolve endpoint with the product and the context. The endpoint also accepts salesChannelId, locationId, customerId, priceType, and asOf for a price on a past date.

GET /api/v1/pricelists/resolve?productId={productId}&deliveryZoneId={zoneId}&customerGroupId={groupId}

Prices from a sales channel

A connected sales channel can report its own price. Miridia records the observed price. It never writes the observed price into your price history.

If you enable price sync on that connection, an observed change updates the price list that is assigned to that channel. Your own record of the product price stays under your control.

Tax and discounts

Each price history entry and each price list item has tax data: a tax type (for example Vat or Sales), a tax rate, and a flag that tells if the price includes tax. Each can also have a discount of type Percentage or FixedValue.

API reference

• Price lists
• Products
• Customer groups
• Sales channels
• Delivery zones