Once you’ve honestly calculated your cost of goods — with delivery, duties, and everything the product picked up on its way to the warehouse — the next question comes up: what price should you actually set? And here most entrepreneurs do the same thing: they take the purchase price, add the usual “plus 30%”, and off they go. Or they look at what the shop next door charges and match it.

The problem is that a price set by eye, or as “purchase plus a standard markup”, almost always loses somewhere. On some products you underearn, on others you become uncompetitive. And when you have hundreds of products, keeping all this in your head is no longer possible.

Why a single markup on everything is a trap

Imagine you put +30% on the entire range. Sounds simple and fair. But products differ:

• one turns over fast and sells itself — you can earn less per unit but make it up on volume;
• another sits for months taking up space — it needs to bring more from each sale;
• on a third you face strong competition, and +30% makes you the most expensive of all;
• and on an imported product, delivery and duties have already eaten part of the margin — so +30% on the purchase price actually means far less real profit.

A single markup doesn’t see these differences. It errs equally in both directions: somewhere you lose profit, somewhere you lose customers.

A price calculated from cost

It makes more sense to set the price not out of thin air but from cost — by a clear rule. In ERPJS, the price in a price list is calculated by a formula: it takes a base (most often the cost), applies your markup as a percentage, adds a fixed amount if needed — and rounds the result.

The base doesn’t have to be cost. You can calculate the price from the last purchase price, or build off another price list (for example, the retail price is the wholesale price plus a certain percentage). You set the rule once, and the system calculates prices by it for the whole list of products.

The key point: different products can be calculated differently. That’s what price groups are for — you combine products into categories and set a markup for each. Electronics one, accessories another, consumables a third. Each group lives by its own formula, but all of it sits in one transparent mechanism.

A price list for each customer

The same product often sells at different prices depending on the customer: one for wholesale, another for retail. In ERPJS, a price list is tied to the customer’s record. When you issue an invoice to that customer, the prices are pulled from their price list automatically — nothing to pick by hand. A wholesaler gets wholesale prices, a retail buyer gets retail ones, because it’s determined by who the customer is.

And you can keep as many price lists as you need — a separate wholesale one, retail one, one for the marketplace (where you also need to factor in the commission). Each has its own set of prices, validity period, and currency.

A price list in currency: the rate changes, and you do nothing

This matters especially for those who buy in foreign currency. If a price list is kept in a currency — say, euros — the local price doesn’t freeze. When you issue a document in the local currency, the system takes the euro price and converts it at the rate on that document’s date.

The rate jumped — you don’t rewrite price tags or run any recalculations. The euro price stays the same, and the local equivalent is always current as of the day of sale. For an importer, this removes a whole layer of manual work: the price is tied to the currency you actually incur your costs in.

When the cost changes — recalculation under control

A different situation is when the base itself changes. You bought a new batch at a higher price, the cost went up, and you want the prices in the list to reflect it. Then you run a recalculation: the system goes through the price lists and recalculates prices by your formulas.

This is a separate, deliberate action, not something that happens on its own. And that’s right: prices are too sensitive a thing to change behind your back. You decide when to update the price list, and you do it in one operation across the whole list.

Tidy price tags and discounts

A small thing that affects perception: after calculation, a price rarely comes out even. So there’s rounding — to any convenient step: to 99, to 50 cents, to the nearest ten.

Discounts work the same way — and they too are tied to the customer. Their record holds a discount table, and when you issue an invoice the discounts are applied automatically, with no manual intervention. The discount itself can be set on a specific product, product group, or brand and limited to a period. This is handy for promotions: the discount applies on the right dates and to the right list, rather than being edited by hand across the whole catalog.

The bottom line

A price is a decision, not a guess. Cost gives you the floor below which there’s no sense in selling. The formula in the price list gives the mechanics. A currency price list removes the exchange-rate question, and recalculation stays where it belongs — in your hands.

Instead of “plus thirty percent and whatever happens”, you get prices that rest on real numbers and update when you want them to.

How does ERPJS calculate the sales price?

The price in a price list is calculated by a formula: it takes a base (most often the cost, but it can also be the last purchase price or another price list), applies your markup as a percentage, adds a fixed amount if needed, and rounds the result. For different product categories you can set different formulas through price groups.

Can I have different prices for wholesale and retail?

Yes. You keep several price lists — for example, wholesale, retail, and one for the marketplace. A price list is tied to the customer’s record: when you issue an invoice to them, the prices are pulled from their list automatically. A wholesaler gets wholesale prices, a retail buyer gets retail ones, with nothing to select by hand.

What about prices if the list is in currency and the rate changes?

If the price list is kept in a currency (for example, euros), then when you issue a document in the local currency the price is converted at the rate on the document’s date. The rate changed — nothing to rewrite: the currency price is the same, and the local equivalent is always current as of the day of sale.

Are prices recalculated automatically when the cost changes?

No, and that’s by design. When the cost has changed and you want to update prices, you run a recalculation in one operation across the whole price list. Prices don’t change behind your back — you decide when to update the list.

Can prices be rounded to tidy figures?

Yes. There’s rounding to any step — to 99, to 50 cents, to the nearest ten. The price calculated by the formula is automatically brought to a convenient form.

Are discounts and promotions supported?

Yes. Discounts are tied to the customer’s record and applied automatically when you issue an invoice. The discount itself can be set on a specific product, product group, or brand and limited to a period — handy for promotions, when a discount should apply on the right dates and to the right list of products.