«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Թեստերը աշխատում են սովորական գործարքներով։ Երկու օգտատերերի կողմից միաժամանակյա ստեղծման ժամանակ վարքագիծը դրանց մեջ չի մտնում, այն ստուգվել է ձեռքով՝ տվյալների բազայի պատճենի վրա, ինչպես նկարագրված է վերևում։ Ով մոդուլը կիրառում է բազմաթիվ միաժամանակյա օգտատերերով համակարգում, պետք է այդ փորձը կրկնի իր սեփական տվյալների բազայում։
Իրավական նշում հաշիվ-ապրանքագրի համարի վերաբերյալ
UStG-ի § 11-ի համաձայն հաշիվ-ապրանքագրերը պետք է ունենան հաջորդական համար, որը տրվում է հաշիվ-ապրանքագրի նույնականացման համար միանգամայն եզակի։ Մոդուլը հաշիվ-ապրանքագրերը համարակալում է գրանցման ժամանակ և յուրաքանչյուր նախածանցի և տարվա համար սեփական հաշվիչով, ինչը համապատասխանում է դրան։ Արդյո՞ք ձեր կոնկրետ կարգավորումը (մի քանի ամսագիր, սեփական նախածանցով կրեդիտ-նոտաներ, տարվա փոփոխություն) բավարարում է ձեր հարկային խորհրդատուի պահանջները, դուք պետք է պարզեք նրա հետ։ Այս հոդվածը իրավական խորհրդատվություն չէ։
Հաճախ տրվող հարցեր
Ինչո՞ւ պարզապես չհարմարեցնել Odoo-ի հաջորդականությունները։
Հաշիվ-ապրանքագրերի համար դա հնարավոր է ամսագրի նախածանցի միջոցով։ Բայց առաջարկների, պատվերների, առաքման թղթերի և գնումների համար չկա նախածանցից, տարուց և հաշվիչից բաղկացած ընդհանուր սխեմա՝ տարվա փոփոխությամբ, և հաշվիչը չի ճանաչում ներմուծված հին համարները։ Մոդուլը հենց այստեղ է միջամտում։
Առկա համարակալումը վերագրվու՞մ է։
Ոչ։ Մոդուլը տալիս է միայն նոր համարներ։ Արդեն պահպանված անունները մնում են անփոփոխ, նույնիսկ անջատելիս։
Ինչպե՞ս այն նորից անջատել։
Դատարկեք փաստաթղթի տեսակի նախածանցը։ Այդ դեպքում Odoo-ն նորից ինքն է համարակալում այն։ Նույնիսկ ապատեղադրումը չի փոխում արդեն տրված համարները։
Դուք ինքներդ օգտագործու՞մ եք այն։
Ոչ։ Մեզ մոտ աշխատում են Odoo-ի ստանդարտ համարները։ Մոդուլը մենք ստուգել ենք ավտոմատ թեստերով և նկարագրված ձեռքով փորձով, բայց ոչ բազմաթիվ օգտատերերով աշխատող գործող համակարգում։
Աշխատու՞մ է Odoo 17-ի կամ 18-ի հետ։
Մենք այն փորձարկել ենք միայն Odoo 19.0 Community-ի հետ։ Այլ տարբերակների համար այն կարող է համապատասխանել կամ ոչ, մենք չենք ստուգել։
Ի՞նչ լիցենզիայով է այն։
LGPL-3 լիցենզիայով։ Սխալները և բարելավումները ողջունվում են որպես issue՝ GitHub պահոցում ։
Biricon IT Services-ի աջակցությունը
Մենք սպասարկում ենք Odoo տեղադրումները փոքր և միջին ձեռնարկությունների համար՝ ներդրումից և հարմարեցումներից մինչև միգրացիաներ և ընթացիկ շահագործում։ Եթե ցանկանում եք անցման ժամանակ պահպանել ձեր փաստաթղթերի համարները, ստուգել համարների տրամադրումը բեռնվածության տակ կամ այսպիսի մոդուլ անվտանգ կերպով ներդնել ձեր արտադրական օրինակում, ուրախությամբ կօգնենք։ Այլ սեփական մշակումներ՝ Firmenbuch և հասցեների ստուգում ավստրիացի հաճախորդների համար, Ապրանքակոմպլեկտները առաջարկում որպես բաժին և Web RBL՝ հարձակման տրաֆիկի արգելափակման ցանկը.
Վիճակը՝ 2026 թվականի նոյեմբերի 3։ Մոդուլի տարբերակը՝ 19.0.1.0.0։ Օրինակներում և պատկերներում բոլոր համարներն ազատ ընտրված են։