l10n_bg_stock_account: връщаме осчетоводяването на пикинга в Odoo 19

В Odoo 19 бе премахнато picking-level осчетоводяването, interim сметките и Stock Valuation Layers (SVL). Това създава сериозни проблеми за българските фирми - нарушение на НСС 2, липса на audit trail и проблеми с историческата цена. BL Consulting разработи два модула, които възстановяват правилното поведение, адаптирани към новата архитектура на Odoo 19.

Припомняне: проблемът

В предишната статия разгледах фундаменталния проблем с Odoo 19: премахването на stock.valuation.layer, interim сметките (Stock Input/Output) и прехвърлянето на цялото осчетоводяване на ниво фактура.

Накратко:

• Историческата цена се презаписва от фактурната — в нарушение на принципа на историческата цена (IAS 2 / НСС 2).
• Audit trail изчезва — вече няма документ, който да свързва физическото движение със счетоводното.
• Одиторите очакват Дт 302 / Кт 301 при приемането на стоката, а не при осчетоводяване на фактурата.

Това е блокиращо за всяка българска фирма, която подлежи на одит. Затова BL Consulting разработи два модула, които връщат правилното поведение — но адаптирано към новата архитектура на Odoo 19.

Решението: два модула

1. l10n_bg_stock_account — picking-level осчетоводяване

Repository: rosenvladimirov/l10n-bulgaria/tree/19.0/l10n_bg_stock_account
License: LGPL-3 (OCA l10n-bulgaria)
Версия: 19.0

Модулът генерира журнални записи в момента на валидиране на пикинга — както се очаква от българското счетоводно законодателство.

2. l10n_bg_stock_price_diff — MO chain price difference (Enterprise)

Repository: rosenvladimirov/l10n-bulgaria-ee/tree/19.0/l10n_bg_stock_price_diff
License: OPL-1
Версия: 19.0.1.0.1

Разширение, което решава вторичния проблем: какво се случва, когато фактурната цена се различава от PO цената, а суровината вече е консумирана в производството и готовата продукция частично продадена.

Как работи l10n_bg_stock_account

Адаптация за V19: директна работа със stock.move

Тъй като Odoo 19 премахна stock.valuation.layer, модулът е пренаписан да чете valuation полетата директно от stock.move — remaining_qty, value и новите valuation полета, които замениха SVL.

Това не е просто бекпорт на стария V18 модул. Моделът на данните е различен и логиката за създаване на journal items е пренаписана.

Пример: приемане на стока

Сценарий: Доставчик доставя 100 бр. суровина по цена 10 лв./бр. (PO стойност 1000 лв.).

Стандартно поведение на Odoo 19: няма запис до осчетоводяване на фактурата.

С l10n_bg_stock_account — при валидиране на пикинга:

Дт 302 Материали              1000.00
    Кт 301 Доставчици за доставени,
         нефактурирани стоки (GRNI)  1000.00
    

След получаване на фактурата (PO=Invoice):

Дт 301 GRNI                   1000.00
    Кт 401 Доставчици         1000.00
    

Резултатът: валутационната сметка се удря в момента на физическото приемане, както очаква одиторът. GRNI сметката служи като clearing account между получаването и фактурата.

Как работи l10n_bg_stock_price_diff

Това е отделен Enterprise модул за по-сложния сценарий: ценовите разлики при производство.

Алгоритъмът: рекурсивен MO chain обход

При _post() на vendor bill, модулът:

1. Детектира разлики между PO и Invoice за всеки ред.
2. Рекурсивно обхожда MO chain — от суровината надолу към готова продукция, с максимална дълбочина 10 нива.
3. За всяко количество проследява destiny — дали е в склада, в WIP, във FG, или в COGS.
4. Създава ЕДИН журнален запис с пропорционално разпределение.

Три нови модела

Защо това е важно за българския контекст

НСС 2 съответствие

НСС 2 (и IAS 2) изискват stock-ът да се оценява в реално време, а движенията да създават счетоводни записи в момента на физическото движение. Без l10n_bg_stock_account, Odoo 19 не отговаря на това изискване.

Одиторски очаквания

Всеки български одитор ще попита: "Покажи ми записа Дт 302 / Кт 301 от датата на приемането." Ако такъв запис няма — следват въпроси. Модулът затваря това очакване без ръчни корекции.

Производствени предприятия

За пилотните клиенти на MRP Design Matrix (консервна фабрика, торби, входни врати, щори) — всички с активно производство — l10n_bg_stock_price_diff е задължителен. Без него COGS стойностите ще се разминават систематично с реалните при всяка PO↔Invoice разлика.

Инсталация и конфигурация

Repositories

Community модул:
Repository: rosenvladimirov/l10n-bulgaria (19.0 branch)
Модул: l10n_bg_stock_account

Enterprise модул:
Repository: rosenvladimirov/l10n-bulgaria-ee (19.0 branch)
Модул: l10n_bg_stock_price_diff

Заключение

Odoo 19 направи архитектурно опростяване, което работи за прости търговски фирми, но нарушава основни изисквания за производствени фирми и всеки бизнес под одит. l10n_bg_stock_account и l10n_bg_stock_price_diff връщат коректното поведение — не като работят против новата архитектура на V19, а като се интегрират чисто с новия stock.move-базиран valuation модел.

Ако имаш производствена фирма или си под одит — тези два модула не са опционални.