«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. Ён даступны на GitHub як свабоднае праграмнае забеспячэнне пад ліцэнзіяй LGPL-3:
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» і прысвойвае той жа нумар паўторна. Блакіроўка ўпарадкавала дзеянні, але не абнавіла даныя, даступныя транзакцыі.
Рашэнне — паўторнае чытанне праз асобнае кароткачасовае злучэнне з базай даных, якое бачыць усе ўжо зафіксаваныя радкі. Выкарыстоўваецца большае з двух значэнняў. Першае чытанне застаецца патрэбным, бо толькі яно бачыць нумары, якія тая самая транзакцыя ўжо прысвоіла, але яшчэ не зафіксавала, напрыклад пры імпарце некалькіх дакументаў адразу.
Мы праверылі гэта на дзвюх транзакцыях, прычым дакладна пацвердзілі, што другая атрымала свой здымак даных да фіксацыі першай, а потым чакала блакіроўкі. Без паўторнага чытання абодва заказы атрымалі аднолькавы нумар, а з ім — нумары 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у каталог, пазначаны ў шляху да дадаткаў. - Абнавіце спіс праграм і ўсталюйце модуль. Для яго працы патрэбныя Продажы, Закупкі, Склад і Бухгалтэрыя.
- У раздзеле Налады → Нумарацыя дакументаў задайце прэфіксы, фармат года і колькасць разрадаў.
- Спачатку праверце на копіі. Пазней аўтаматычна вярнуць ранейшы нумар дакумента не атрымаецца, а для рахункаў з нумарам звязаныя абавязкі захоўвання і праверкі.
абмежаванні
- Прапановы нумаруюцца пры стварэнні. Выдаленыя або скасаваныя прапановы пакідаюць пропускі. Тое самае датычыцца кожнага заказу кліента, створанага іншым модулем: кошыкі інтэрнэт-крамы (
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 для малога і сярэдняга бізнесу: ад укаранення, дапрацовак і міграцый да паўсядзённай эксплуатацыі. Калі вы хочаце захаваць нумары дакументаў пры пераходзе, праверыць нумарацыю пад нагрузкай або бяспечна ўкараніць такі модуль у працоўную сістэму, мы ахвотна дапаможам. Іншыя нашы распрацоўкі: Рэестр кампаній і праверка адрасоў аўстрыйскіх кліентаў, Наборы тавараў як раздзел камерцыйнай прапановы і Web RBL — спіс блакіроўкі трафіку атак.
Станам на 3 лістапада 2026 г. Версія модуля 19.0.1.0.0. Усе нумары ў прыкладах і на ілюстрацыях выбраны адвольна.