Adds the price change document to the retail merchandise accounting of l10n_ro_stock_account_retail.
l10n.ro.retail.price.change is a persistent document numbered PVSP/YYYY/00000 out of a sequence of its own company. It captures the warehouse, the date, the products on hand and the old versus new shelf price (PVA, VAT included) per line, with the markup (378) and deferred VAT (4428) split.
The old side is what the stock carries — cost, markup and deferred VAT per unit, read from the markup ledger — and it is read again when the document is posted, so the delta always measures the gap that exists at the moment the entry is made. A posted document is final: it is revoked by posting another one, never reset, cancelled or deleted.
There are three flows:
Manual - create a draft, load the products on hand, edit the new prices, then post. Posting writes the new prices on the warehouse retail pricelist, books the revaluation and records it in the markup ledger, so the next sale releases the new markup and not the old one.
Automatic - a draft document is raised for each affected retail warehouse whenever a shelf price moves, and the user reviews it and posts it. What decided the price does not matter: a fixed rule, a rule over a category or the whole shop, any term of a formula, a change on another pricelist the shop derives from, or the product’s own sale price. The price before and the price after are compared per product and per shop, so a rule that names a whole range raises a document holding the labels that actually moved.
A shop has at most one open automatic document, topped up as prices keep moving, so it always quotes the price that is on the label.
Posting writes a fixed rule back on the pricelist only where the pricelist does not already answer with the price decided, which is what keeps a shop priced by formula priced by formula.
Reconciled - a daily cron, Retail: Reconcile Shelf Prices, compares what the markup ledger says each unit on the shelf carries with what the pricelist says the label reads, and raises a draft wherever the two have parted company. That catches the prices which move with nobody writing anything: the day a dated promotion opens, a shelf price computed over a cost that a reception has moved, a change of VAT rate. Stock the ledger does not yet account for is left to the opening balance wizard.
The document prints as Proces-verbal privind modificarea pretului de vanzare cu amanuntul, listing quantity, old and new price, old and new value and the difference per product, with the markup and VAT split shown separately.
Every posted document is a dated record of the shelf price of the products it covers. The Price History button on a product shows the lines that concern it, oldest first, so the sequence of shelf prices and the document that decided each of them are visible in one place.
Table of contents
Nothing to configure beyond what l10n_ro_stock_account_retail already asks for. What that module needs, this one relies on:
Two things are worth doing once, before the first price change:
The shop can start from either end.
From the document. Inventory → Retail → Price Changes, create one, pick the warehouse, Load Products. Every product on hand in the shop’s retail locations comes in with what it currently carries on the left — cost, markup and deferred VAT per unit, read from the markup ledger, not from the price list — and the current shelf price on the right. Edit the New PVA of the lines that are changing, delete the rest, then Post.
From the price list. Change the price of a product on a shop’s retail pricelist, and a draft Proces Verbal is raised for each retail warehouse that has that product on hand. It is a draft on purpose: somebody reviews it and posts it. Deleting a rule raises one too, because the label changes then as well.
Posting does four things, in one transaction: writes the new prices on the retail pricelist, posts the revaluation of 371 against 378 and 4428, records it in the markup ledger so the next sale releases the new markup, and prints as the Proces-verbal privind modificarea pretului de vanzare cu amanuntul.
The old side and the quantity are re-read at the moment of posting, not at the moment of loading. A draft raised this morning and posted this afternoon measures itself against what the shop holds this afternoon, so two documents on the same goods cannot each revalue from the same starting point.
There is no reset to draft, and a posted document cannot be cancelled or deleted. It wrote prices, posted an entry and moved what the stock carries; the paper trail is the point. A price decision that turned out wrong is revoked the way it was made — post another Proces Verbal bringing the price back. Only a document still in draft can be cancelled or deleted.
Price History on a product lists every posted line that concerns it, oldest first: the date, the shop, the old and new PVA and the document that decided each. That is the shelf price history the shop has to be able to show.
A Proces Verbal is raised for every shelf price that moves, whatever decided it. What is compared is the price before and the price after, per product and per shop, so a rule that names a whole range produces a document holding the labels that actually changed — not the range.
Caught as it happens, from a write on the price list:
Caught overnight, by Retail: Reconcile Shelf Prices:
The cron is the mechanism of record, and it is the one to trust: it checks the invariant itself — the markup ledger says what each unit on the shelf carries, the price list says what the label reads, and those two agreeing is what this family of modules exists to maintain. The write hooks only make the common cases immediate.
The cost is deliberately not watched as it is written. standard_price is rewritten by the valuation on every reception under average cost, and hanging a price check off the hot path of every goods movement would make every receipt pay for a check that almost never finds anything.
Stock the markup ledger does not yet account for is left alone by the reconciliation. That is the opening balance, it has its own wizard, and a document raised over it would refuse to post anyway.
A shop has at most one open automatic document. A second price move on the same goods brings the open draft up to date instead of raising another one, so three price moves in a morning are one document quoting the price that is actually on the label — and the nightly reconciliation does not add the same divergence again every night until somebody posts it.
Posting writes a fixed rule per variant only where the price list does not already answer with the price the document decided. A document raised by a category rule or a markup formula therefore writes nothing back: the rule that produced the price still reaches the product afterwards. A fixed rule is an override, and it is written when somebody actually overrode something — a price typed by hand on the document.
Bugs are tracked on GitHub Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us to smash it by providing a detailed and welcomed feedback.
Do not contact contributors directly about support or help with technical issues.
Do not contact contributors directly about support or help with technical issues.
This module is maintained by the OCA.
OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.
Current maintainers:
This module is part of the OCA/l10n-romania project on GitHub.
You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.