„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-ს თავის საკუთარი თანმიმდევრობებისთვის ამისთვის მონაცემთა ბაზის sequence-ები აქვს. საკუთარი აგებული ნომრისთვის ეს არ არსებობს, ხოლო შეთავაზებებისა და შესყიდვის შეკვეთებისთვის 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_yearaddons-ის გზაში. - განაახლეთ აპლიკაციების სია, დააინსტალირეთ მოდული. წინაპირობებია გაყიდვები, შესყიდვები, საწყობი და ბუღალტერია.
- პარამეტრები → დოკუმენტების ნომრავა განყოფილებაში შეიყვანეთ პრეფიქსები, წლის ფორმატი და ციფრების რაოდენობა.
- ჯერ ასლზე გამოსცადეთ. დოკუმენტის ნომერი მოგვიანებით ავტომატურად ვერ დაბრუნდება, ინვოისებზე კი ნომერს უკავშირდება შენახვისა და შემოწმების ვალდებულება.
შეზღუდვები
- შეთავაზებები იქმნებისას ინომრება. წაშლილი ან გაუქმებული შეთავაზებები ნაპრალებს ტოვებს. იგივე ეხება ყოველ კლიენტის შეკვეთას, რომელსაც სხვა მოდული ქმნის: ვებ-მაღაზიის კალათები (
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, შავი სია თავდასხმის ტრაფიკისთვის.
მდგომარეობა: 2026 წლის 3 ნოემბერი. მოდულის ვერსია 19.0.1.0.0. მაგალითებსა და ილუსტრაციებში ყველა ნომერი თავისუფლადაა შერჩეული.