Metadata-Version: 2.1
Name: odoo-addon-l10n_ro_stock_account_retail_price_change
Version: 19.0.1.1.0
Requires-Dist: odoo-addon-l10n_ro_stock_account_retail==19.0.*
Requires-Dist: odoo==19.0.*
Summary: Romania - Retail price change document, report and history
Home-page: https://github.com/OCA/l10n-romania
License: AGPL-3
Author: NextERP Romania,Dakai Soft SRL,Odoo Community Association (OCA)
Author-email: support@odoo-community.org
Classifier: Programming Language :: Python
Classifier: Framework :: Odoo
Classifier: Framework :: Odoo :: 19.0
Classifier: License :: OSI Approved :: GNU Affero General Public License v3
Classifier: Development Status :: 6 - Mature
Description-Content-Type: text/x-rst

.. image:: https://odoo-community.org/readme-banner-image
   :target: https://odoo-community.org/get-involved?utm_source=readme
   :alt: Odoo Community Association

============================================================
Romania - Retail Price Change (Proces Verbal Schimbare Pret)
============================================================

.. 
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !! This file is generated by oca-gen-addon-readme !!
   !! changes will be overwritten.                   !!
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !! source digest: sha256:ddf030e57cc589bfca557de269339343651a0b4ccee01f144647ced6158f7e0d
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

.. |badge1| image:: https://img.shields.io/badge/maturity-Mature-brightgreen.png
    :target: https://odoo-community.org/page/development-status
    :alt: Mature
.. |badge2| image:: https://img.shields.io/badge/license-AGPL--3-blue.png
    :target: http://www.gnu.org/licenses/agpl-3.0-standalone.html
    :alt: License: AGPL-3
.. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fl10n--romania-lightgray.png?logo=github
    :target: https://github.com/OCA/l10n-romania/tree/19.0/l10n_ro_stock_account_retail_price_change
    :alt: OCA/l10n-romania
.. |badge4| image:: https://img.shields.io/badge/weblate-Translate%20me-F47D42.png
    :target: https://translation.odoo-community.org/projects/l10n-romania-19-0/l10n-romania-19-0-l10n_ro_stock_account_retail_price_change
    :alt: Translate me on Weblate
.. |badge5| image:: https://img.shields.io/badge/runboat-Try%20me-875A7B.png
    :target: https://runboat.odoo-community.org/builds?repo=OCA/l10n-romania&target_branch=19.0
    :alt: Try me on Runboat

|badge1| |badge2| |badge3| |badge4| |badge5|

Romania - Retail Price Change (Proces Verbal de Schimbare Pret)
===============================================================

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:

1. **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.

2. **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.

3. **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.

Report
------

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.

Price history
-------------

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**

.. contents::
   :local:

Configuration
=============

Nothing to configure beyond what ``l10n_ro_stock_account_retail``
already asks for. What that module needs, this one relies on:

1. **Retail warehouse.** Tick *Retail Warehouse* on the shop and give it
   its *Retail Pricelist*. That pricelist holds the shelf price (PVA),
   VAT included, and is the one this document writes back to.
2. **Accounts.** 371, 378 and 4428 must resolve for every product the
   shop holds — on the location, the product, its category or the
   company, mapped through the warehouse fiscal position if it has one.
   Posting refuses rather than guessing.
3. **Stock journal.** The entry is posted in the company's stock
   journal; the document also lets you pick another one per document.

Two things are worth doing once, before the first price change:

- **Settle the opening balance.** Stock that was on the shelf before
  ``l10n_ro_stock_account_retail`` was installed is in the quants and
  not in the markup ledger. Run *Retail Opening Balance* until it finds
  nothing. A price change document refuses to post while the ledger does
  not account for the same quantity it revalues, because the rate it
  applies is derived from the ledger.

- **Numbering.** Each company gets its own ``PVSP/YYYY/00000`` sequence,
  created on install and whenever a company is added. Change the prefix
  or padding per company under *Settings → Technical → Sequences* if the
  shop's own numbering differs.

- **The nightly reconciliation.** *Retail: Reconcile Shelf Prices* is
  scheduled daily under *Settings → Technical → Scheduled Actions*. It
  raises drafts, never posts anything, and is what catches a price that
  moved without anyone writing a rule - a dated promotion opening, a
  shelf price computed over a cost the last reception moved, a change of
  VAT rate. Leave it on: the write hooks on the price list only make the
  common cases immediate, they cannot see those.

Usage
=====

Changing a shelf price
----------------------

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.

Correcting a document
---------------------

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
-------------

*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.

What raises a document
----------------------

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:

- a fixed price on a product or a template;
- a rule on a **category**, or a **global** rule;
- any term of a **formula** — the base it starts from, the discount or
  markup, the rounding, the extra fee, the margins;
- a change on **another price list the shop derives from**, however long
  the chain: the buyer moves a price on the buying list and the shop's
  labels move with it;
- deleting a rule, because the label changes then as well;
- a change to the product's **sale price**, for the shops that price
  their shelves off it — which is the default setup.

Caught overnight, by *Retail: Reconcile Shelf Prices*:

- the day a **dated promotion** opens or closes on its own;
- a shelf price computed over the **cost**, which moves on the next
  reception at a different cost;
- a change of **VAT rate**, which re-splits every price in the shop;
- anything else that moved the label without anyone writing a rule.

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.

One open draft per shop
-----------------------

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 does not replace your price rules
-----------------------------------------

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.

Bug Tracker
===========

Bugs are tracked on `GitHub Issues <https://github.com/OCA/l10n-romania/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 <https://github.com/OCA/l10n-romania/issues/new?body=module:%20l10n_ro_stock_account_retail_price_change%0Aversion:%2019.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

Do not contact contributors directly about support or help with technical issues.

Credits
=======

Authors
-------

* NextERP Romania
* Dakai Soft SRL

Contributors
------------

- `NextERP Romania <https://www.nexterp.ro>`__:

  - Fekete Mihai <contact@nexterp.ro>

- `Dakai Soft SRL <https://www.dakai.ro>`__:

  - Adrian Vacaru <adrian.vacaru@dakai.ro>

Do not contact contributors directly about support or help with
technical issues.

Maintainers
-----------

This module is maintained by the OCA.

.. image:: https://odoo-community.org/logo.png
   :alt: Odoo Community Association
   :target: https://odoo-community.org

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.

.. |maintainer-feketemihai| image:: https://github.com/feketemihai.png?size=40px
    :target: https://github.com/feketemihai
    :alt: feketemihai
.. |maintainer-adrian-dks| image:: https://github.com/adrian-dks.png?size=40px
    :target: https://github.com/adrian-dks
    :alt: adrian-dks

Current `maintainers <https://odoo-community.org/page/maintainer-role>`__:

|maintainer-feketemihai| |maintainer-adrian-dks| 

This module is part of the `OCA/l10n-romania <https://github.com/OCA/l10n-romania/tree/19.0/l10n_ro_stock_account_retail_price_change>`_ project on GitHub.

You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.
