«AN26000001» кажа больш, чым «S00001»: гэта прапанова, яна з 2026 года, і яна першая. Многія прадпрыемствы, асабліва тыя, што пераходзяць са старэйшай сістэмы на Odoo, хочуць захаваць свае нумары дакументаў менавіта такімі. Сам Odoo нумарацыю прапаноў, заказаў і накладных вядзе ўласнымі паслядоўнасцямі (S00001, WH/OUT/00001, P00001), а рахункаў — з прэфіксам журнала і годам (INV/2026/00001).
Для гэтага мы напісалі модуль Document Numbering by Prefix and Year (document_number_prefix_year) для Odoo 19. Ён даступны як свабоднае праграмнае забеспячэнне пад ліцэнзіяй LGPL-3 на GitHub:
github.com/Alex0176/odoo-document-number-prefix-year
Спачатку шчырая ацэнка: мы не выкарыстоўваем гэты модуль у Biricon IT Services. Мы публікуем яго, бо ён гатовы, задакументаваны і забяспечаны тэстамі і можа зэканоміць працу іншым. Хто яго выкарыстоўвае, павінен прачытаць раздзелы пра Абмежаванні і Тэсты .
Схема нумарацыі
Кожны нумар складаецца з трох частак: прэфікса для кожнага віду дакумента, года і лічыльніка з фіксаванай колькасцю знакаў. Прэфікс, фармат года (26 або 2026) і колькасць знакаў вы задаяце для кожнай фірмы ў Налады → Нумарацыя дакументаў.
Апрацоўваюцца прапановы, заказы кліентаў, рахункі кліентаў і крэдыт-ноты, накладныя, паступленні тавараў і заказы на закупку. Прэфіксы на малюнку — толькі прыклады: AN, AU, RE, GU, LI, WE, BE. Калі пакінуць прэфікс пустым, для гэтага віду дакумента захоўваецца стандартная нумарацыя Odoo. Таму модуль нічога не робіць, пакуль вы яго не наладзіце.
Як паводзяць сябе нумары
- Кожны год нанова. Лічыльнік пачынаецца з 1 пры змене года.
- Працяг пасля імпартаваных нумароў. Модуль шукае найвышэйшы наяўны нумар таго ж прэфікса і года, незалежна ад яго даўжыні. Калі са старой сістэмы ў базе даных ёсць
AN26119, наступная прапанова будзеAN26000120. Таму модуль падыходзіць для пераходаў: старыя дакументы імпартуюцца з арыгінальнымі нумарамі, а новыя дакументы працягваюць без разрываў. - Новы нумар заказу пры пацверджанні. Пацверджаная прапанова пры жаданні атрымлівае нумар з паслядоўнасці заказаў. Нумар прапановы захоўваецца ў полі Нумар прапановы у заказе і бачны ў форме, спісе і пошуку.
- Рахункі пры праводцы. Рахункі кліентаў і крэдыт-ноты атрымліваюць свой нумар толькі пры праводцы, а не пры стварэнні. Выдаленыя чарнавікі таму не пакідаюць прабелаў. Год бярэцца з даты рахунку: рахунак ад 30.12.2025, які праводзіцца 2.1.2026, называецца
RE25…. - Усё астатняе застаецца. Рахункі пастаўшчыкоў, плацяжы, бухгалтарскія праводкі і заказы на вытворчасць захоўваюць стандартныя паслядоўнасці Odoo. Існуючыя назвы ніколі не перазапісваюцца, нават калі вы зноў адключыце модуль.
Далікатная частка: два карыстальнікі адначасова
Уласная раздача нумароў выглядае проста: знайсці найвышэйшы нумар, дадаць адзінку. Але гэта не так, як толькі два карыстальнікі ў той самы момант ствараюць прапанову. Абодва чытаюць «найвышэйшы нумар = 0», абодва прысвойваюць AN26000001. Для ўласных паслядоўнасцяў у Odoo для гэтага ёсць паслядоўнасці базы даных. У самаробнага нумара іх няма, а для прапаноў і заказаў на закупку ў Odoo да таго ж няма праверкі ўнікальнасці па назве: два дакументы з аднолькавым нумарам проста захоўваюцца.
Відавочная абарона — блакіроўка. Модуль бярэ для кожнай фірмы, прэфікса і года блакіроўку базы даных (PostgreSQL Advisory Lock), якая трымаецца да канца транзакцыі. Другі карыстальнік чакае, пакуль першы не скончыць. Але гэтага недастаткова, і мы выявілі гэта эксперыментам на копіі прадукцыйнай базы даных:
Odoo працуе з узроўнем ізаляцыі REPEATABLE READ. Стан базы даных, які бачыць транзакцыя, замарожваецца пры яе першым запыце. У карыстальніка B гэты стан ужо ёсць да таго, як A скончыць. Калі B пасля гэтага чакае блакіроўку і атрымлівае яе, ён чытае са сваім старым станам «найвышэйшы нумар = 0» і прысвойвае нумар другі раз. Блакіроўка ўпарадкавала чаргу, але не абнавіла веды.
Рашэнне — другое чытанне праз асобнае кароткачасовае злучэнне з базай даных, якое бачыць усе ўжо пацверджаныя радкі. Перамагае большае са знойдзеных значэнняў. Першае чытанне застаецца неабходным, бо толькі яно ведае нумары, якія тая ж транзакцыя ўжо прысвоіла, але яшчэ не пацвердзіла, напрыклад пры імпарце некалькіх дакументаў за адзін раз.
Мы праверылі гэта двума транзакцыямі, у якіх другая даказана ўзяла свой стан да commit першай, а потым чакала блакіроўку. Без другога чытання абодва заказы атрымалі той самы нумар, з ім — нумары 1 і 2.
Важна для ацэнкі: гэты эксперымент — ручная праверка. Ён не ўваходзіць у аўтаматычныя тэсты, бо для яго патрэбныя два рэальныя злучэнні з базай даных, якіх тэставае асяроддзе Odoo (адна транзакцыя на тэст) не дае.
Тэхнічная рэалізацыя
| Дакумент | Пункт падключэння |
|---|---|
| Прапанова | sale.order.create, калі назва пустая, / або New |
| Заказ кліента | sale.order.action_confirm, перад стандартным пацверджаннем |
| Рахунак, крэдыт-нота | account.move._set_next_sequence, выклікаецца пры праводцы |
| Накладная, паступленне тавараў | stock.picking.create па тыпе аперацыі |
| Заказ на закупку | purchase.order.create |
- Лічыльнік. Найвышэйшы нумар знаходзіць рэгулярны выраз (
^<Stamm>([0-9]{1,15})$, аснова экранаваная) для кожнай фірмы, уключаючы назвы без фірмы. - Рахункі.
_set_next_sequenceзапісвае назву і выклікае_compute_split_sequence, каб лагіка паслядоўнасцяў Odoo (прэфікс, нумар, распазнаванне года для наступнага рахунку журнала) заставалася ўзгодненай. - Налады. Палі фірмы
document_number_*адлюстроўваюцца ўres.config.settings. Налады адхіляюць прэфіксы з прабелам або лічбай у канцы. - Пераклад. Нямецкі пераклад уключаны.
Устаноўка і налада
- Пакласці тэчку
document_number_prefix_yearу шлях addons. - Абнавіць спіс прыкладанняў, усталяваць модуль. Патрабуюцца Продажы, Закупкі, Склад і Бухгалтарыя.
- У Налады → Нумарацыя дакументаў увесці прэфіксы, фармат года і колькасць знакаў.
- Спачатку выпрабаваць на копіі. Нумар дакумента пазней нельга аўтаматычна вярнуць назад, а ў рахунках за нумарам стаяць абавязкі захоўвання і праверкі.
Абмежаванні
- Прапановы нумарыруюцца пры стварэнні. Выдаленыя або скасаваныя прапановы пакідаюць прабелы. Тое ж тычыцца кожнага заказу кліента, які стварае іншы модуль: кошыкі вэб-крамы (
website_sale) — гэта заказы ў статусе Прапанова, і яны расходуюць па нумары. Без прабелаў толькі рахункі і крэдыт-ноты, бо яны нумаруюцца пры праводцы. - Не змяняйце фармат года ў працоўным рэжыме. З асновай
AN26модуль чытае наяўныAN2026000001як лічыльнік26000001. Вызначце фармат да першага дакумента. - Лічыльнік не больш за 15 знакаў. Даўжэйшыя паслядоўнасці лічбаў пасля асновы ігнаруюцца пры пошуку найвышэйшага нумара.
- Няма асобных серый для журнала або склада. Лічыльнік дзейнічае для фірмы, прэфікса і года. Некалькі журналаў продажаў дзеляць лічыльнік рахункаў.
- Прэфіксы не павінны ўтрымліваць прабел і не павінны заканчвацца лічбай, інакш прэфікс, год і лічыльнік ужо нельга падзяліць.
- Апрацоўваюцца толькі названыя віды дакументаў.
Тэсты
Модуль пастаўляецца з дзесяццю аўтаматычнымі тэстамі. Яны правяраюць:
- Прапанову і пацверджанне: нумар прапановы і заказу, захаванне нумара прапановы
- Працяг ліку пасля імпартаванага нумара (
AN26119→AN26000120) - адсутнасць пазнейшай перанумарацыі наяўных дакументаў
- Рахунак, крэдыт-нота і змена года па даце рахунку
- Заказ на закупку і накладныя
- пусты прэфікс: стандартны нумар Odoo захоўваецца
- чатырохзначны год
- прэфікс са спецыяльнымі знакамі
- некалькі нумароў у адной транзакцыі
- вельмі доўгія паслядоўнасці лічбаў ігнаруюцца
Выклік:
odoo-bin -d <Testdatenbank> -i document_number_prefix_year --test-enable --test-tags=/document_number_prefix_year --stop-after-initТэсты выконваюцца са звычайнымі транзакцыямі. Паводзіны пры адначасовым стварэнні двума карыстальнікамі да іх не адносяцца, іх, як апісана вышэй, праверылі ўручную на копіі базы даных. Хто выкарыстоўвае модуль у сістэме з вялікай колькасцю адначасовых карыстальнікаў, павінен паўтарыць гэты эксперымент на ўласнай базе даных.
Юрыдычная заўвага пра нумар рахунку
Рахункі паводле § 11 UStG павінны мець паслядоўны нумар, які прысвойваецца аднойчы для ідэнтыфікацыі рахунку. Модуль нумаруе рахункі пры праводцы і з уласным лічыльнікам для кожнага прэфікса і года, што з гэтым сумяшчальна. Ці адказвае ваша канкрэтная налада (некалькі журналаў, крэдыт-ноты з уласным прэфіксам, змена года) патрабаванням вашага падатковага кансультанта, вы павінны высветліць з ім. Гэты артыкул не з'яўляецца юрыдычнай кансультацыяй.
Частыя пытанні
Чаму б проста не наладзіць паслядоўнасці Odoo?
Для рахункаў гэта магчыма праз прэфікс журнала. Але для прапаноў, заказаў, накладных і заказаў на закупку няма агульнай схемы з прэфікса, года і лічыльніка са зменай года, і лічыльнік не ведае імпартаваных старых нумароў. Менавіта тут модуль і ўключаецца.
Ці перазапісваецца наяўная нумарацыя?
Не. Модуль прысвойвае толькі новыя нумары. Ужо захаваныя назвы застаюцца без змен, таксама пры адключэнні.
Як мне яго зноў адключыць?
Ачысціце прэфікс віду дакумента. Тады Odoo зноў нумарыруе яго сам. Нават выдаленне модуля не змяняе ўжо прысвоеныя нумары.
Вы самі яго выкарыстоўваеце?
Не. У нас працуюць стандартныя нумары Odoo. Мы праверылі модуль аўтаматычнымі тэстамі і апісаным ручным эксперыментам, але не ў працоўным асяроддзі з вялікай колькасцю карыстальнікаў.
Ці працуе ён з Odoo 17 або 18?
Мы тэставалі яго толькі з Odoo 19.0 Community. Для іншых версій ён можа падыходзіць або не, мы гэтага не правяралі.
Пад якой ліцэнзіяй ён распаўсюджваецца?
Пад LGPL-3. Паведамленні пра памылкі і паляпшэнні вітаюцца як issue ў рэпазіторыі GitHub .
Падтрымка ад Biricon IT Services
Мы суправаджаем устаноўкі Odoo для малых і сярэдніх прадпрыемстваў: ад укаранення праз адаптацыі і міграцыі да штодзённай эксплуатацыі. Калі вы хочаце пры пераходзе захаваць свае нумары дакументаў, праверыць раздачу нумароў пад нагрузкай або бяспечна ўвесці падобны модуль у прадукцыйнае асяроддзе, мы з ахвотай дапаможам. Іншыя ўласныя распрацоўкі: Firmenbuch і праверка адрасоў для аўстрыйскіх кліентаў, Наборы прадуктаў у прапанове як раздзел і Web RBL, спіс блакіроўкі для шкоднаснага трафіку.
Стан на 3 лістапада 2026 г. Версія модуля 19.0.1.0.0. Усе нумары ў прыкладах і на малюнках выбраны адвольна.