Skip to Content

Odoo 19 ელექტრონული ინვოისები: ebInterface, ZUGFeRD და e-Rechnung.gv.at უფასოდ საზოგადოებისთვის

5 სექტემბერი, 2026 by
Odoo 19 ელექტრონული ინვოისები: ebInterface, ZUGFeRD და e-Rechnung.gv.at უფასოდ საზოგადოებისთვის
Alexander Biringer | Biricon IT Services GmbH

ელექტრონული ინვოისები თანამედროვე ბუღალტერიის ნაწილია

ბუღალტერიის ციფრულიზაცია წინ მიიწევს. ელექტრონული ინვოისის ფორმატები დიდი ხანია უფრო მეტია, ვიდრე ელფოსტით გაგზავნილი PDF ფაილი.

ნამდვილი ელექტრონული ინვოისი შეიცავს სტრუქტურირებულ მონაცემებს, რომლებსაც ბუღალტრული და ERP სისტემები ავტომატურად ამუშავებენ.

ჩვენი ახალი ღია წყაროს პროექტით Odoo 19 Community-ისთვის სწორედ აქედან ვაპირებთ დაწყებას.

ჩვენ შევქმენით რამდენიმე გაფართოება, რომლებსაც Odoo Community-ს უფასოდ ვთავაზობთ.

პროექტი საჯაროდ ხელმისაწვდომია GitHub-ზე:

Odoo 19 Invoice E-Files GitHub-ზე

ჩვენი ყურადღება განსაკუთრებით ავსტრიაზეა მიმართული, მაგრამ გადაწყვეტის ერთი ნაწილი ავსტრიის ფარგლებს გარეთ მოქმედი კომპანიებისთვისაც საინტერესოა.

სამი მოდული ელექტრონული ინვოისებისთვის

პროექტი ამჟამად სამი ძირითადი კომპონენტისგან შედგება:

  • ebInterface 6.1 ავსტრიისთვის
  • ZUGFeRD ელექტრონული ინვოისებისთვის
  • ავტომატური გადაცემა e-Rechnung.gv.at-ზე

ამგვარად, ელექტრონულ ინვოისებთან დაკავშირებულ სხვადასხვა მოთხოვნას ერთ ღია წყაროს პროექტში ვაერთიანებთ Odoo 19 Community-ისთვის.

ebInterface 6.1 – ავსტრიული ინვოისის ფორმატი

ჩვენი დამუშავების ერთ-ერთი ძირითადი მიმართულებაა ebInterface 6.1.

ebInterface არის ავსტრიის სტანდარტული ფორმატი სტრუქტურირებული ელექტრონული ინვოისებისთვის.

ჩვენი მოდული

l10n_at_ebinterface

Odoo-ში მომხმარებლის ინვოისიდან ან კრედიტ-ნოტიდან ქმნის შესაბამის ebInterface-6.1-XML-ს.

ამ დროს Odoo-ს ინვოისიდან XML სტრუქტურაში, სხვა მონაცემებთან ერთად, გადადის შემდეგი ინფორმაცია:

  • ინვოისის გამცემი
  • ინვოისის მიმღები
  • ინვოისის პოზიციები
  • გადასახადები
  • გადახდის ინფორმაცია
  • საბანკო რეკვიზიტები
  • ინვოისის მონაცემები

შექმნილი XML ფაილი პირდაპირ უკავშირდება ინვოისს.

რატომ შევქმენით ამისთვის საკუთარი მოდული?

დამუშავებისას აღმოვაჩინეთ, რომ Odoo 19 Community-ისთვის ამჟამად არ არსებობს ავსტრიული ნატიური ebInterface სტანდარტის შესაბამისი Odoo-ს ბირთვის ან OCA მოდული.

სწორედ აქედან გვინდოდა დაწყება.

იმის ნაცვლად, რომ ავსტრიული გადაწყვეტა მხოლოდ ჩვენი ინსტალაციისთვის შეგვექმნა, იგი დამოუკიდებელ ღია წყაროს მოდულად განვახორციელეთ.

ამგვარად, დანარჩენ Odoo-ს საზოგადოებასაც შეუძლია ამით ისარგებლოს.

ZUGFeRD ავტომატურად ყოველ ინვოისთან ერთად

ჩვენი პროექტის მეორე ძირითადი მიმართულებაა ZUGFeRD.

ZUGFeRD აერთიანებს PDF ინვოისს სტრუქტურირებულ XML ინვოისთან.

შედეგი არის ე.წ. ჰიბრიდული ინვოისი: ადამიანისთვის ინვოისი PDF-ის სახით იკითხება, ხოლო პროგრამულ უზრუნველყოფას შეუძლია მასში ჩართული სტრუქტურირებული მონაცემების ავტომატურად დამუშავება.

Odoo 19-ს პრინციპში უკვე აქვს ZUGFeRD-ისა და CII-ის მხარდაჭერა.

პრაქტიკაში, თუმცა, არსებობს გარკვეული შეზღუდვები.

ჩვენი მოდული

account_invoice_zugferd_ebinterface_auto

ამიტომ სწორედ ამ საკითხიდან იწყებს.

ZUGFeRD აღარ არის მხოლოდ არჩევითი ვარიანტი

გვინდოდა მაქსიმალურად ავტომატიზებული პროცესი.

გაგზავნილი მომხმარებლის ინვოისის შემთხვევაში ამიტომ ჯერ არ მოწმდება, არის თუ არა შესაბამისი მომხმარებელი ინდივიდუალურად კონფიგურირებული ZUGFeRD-ისთვის.

ამის ნაცვლად, ZUGFeRD ავტომატურად გამოიყენება მომხმარებლის ინვოისებისა და კრედიტ-ნოტებისთვის.

გარდა ამისა, შექმნილი ebInterface-XML ინვოისის შემადგენელ ნაწილად თან ერთვის.

ასე იქმნება უწყვეტი პროცესი:

Odoo-ს ინვოისი → PDF → სტრუქტურირებული ელექტრონული ინვოისი → გაგზავნა

იმის გარეშე, რომ მომხმარებელმა ყოველი ინვოისისთვის დამატებითი ნაბიჯები შეასრულოს.

ჩვენ ვავსებთ Odoo 19 Community-ის ხარვეზებსაც

განხორციელებისას Odoo 19-ის იმპლემენტაციის რამდენიმე თავისებურებას გადავაწყდით.

სხვა საკითხებთან ერთად, CII-ექსპორტერში არსებობს დამოკიდებულებები, რომლებმაც გარკვეული ქვეყნების ინსტალაციების გარეთ პრობლემები შეიძლება გამოიწვიოს.

ჩვენი მოდული ამ პრაქტიკული შეზღუდვებიდან რამდენიმეს აღმოფხვრის.

მათ შორისაა, სხვა საკითხებთან ერთად:

  • დროებით გადავადებული შემოსავლის (Deferred Revenue) პერიოდების ველების არარსებობა
  • PDF/A-3 კონვერტაციის ქვეყნის მიხედვით შეზღუდვა
  • არსებულ ინვოისებში საბანკო რეკვიზიტების არარსებობა ან დაუყენებლობა

ამგვარად, ZUGFeRD საიმედოდ უნდა იყოს გამოყენებადი იმ კომპანიებისთვისაც, რომლებიც თავდაპირველად გათვალისწინებული ქვეყნების კონსტელაციების გარეთ არიან.

e-Rechnung.gv.at – პირდაპირი გადაცემა ავსტრიის სახელმწიფოსთვის

მესამე კომპონენტი განსაკუთრებით საინტერესოა იმ კომპანიებისთვის, რომლებიც ინვოისებს საჯარო დამკვეთებს უგზავნიან.

მოდულით

l10n_at_erechnung_gv_at

შესაძლებელია ebInterface ინვოისის პირდაპირ გადაცემა ავსტრიის e-Rechnung.gv.at-ვებსერვისზე.

ამგვარად, ინვოისის უბრალო შექმნა ავტომატიზებულ ელექტრონული ინვოისირების პროცესად იქცევა.

პროცესი, მაგალითად, ასე შეიძლება გამოიყურებოდეს:

ინვოისის შექმნა Odoo-ში

↓

ebInterface XML-ის გენერირება

↓

ინვოისის გაგზავნა

↓

ebInterface-ის ავტომატური გადაცემა e-Rechnung.gv.at-ზე

ამგვარად, სხვაგვარად ხელით შესასრულებელი პროცესი პირდაპირ Odoo-ში ინტეგრირდება.

ავტომატური გადაცემა მხოლოდ საჭირო მომხმარებლებისთვის

e-Rechnung.gv.at-ზე გადაცემა ყველა მომხმარებლისთვის ზოგადად არ აქტიურდება.

ამის ნაცვლად, ის შესაბამისი ავსტრიელი მომხმარებლის შემთხვევაში შეიძლება გააქტიურდეს.

ამისთვის საჭირო მონაცემები, როგორიცაა, მაგალითად,

  • მომწოდებლის ნომერი
  • მყიდველთა ჯგუფი / ფილიალის ნომერი
  • შეკვეთის მითითება

მომხმარებელთან ინახება.

მოდული ამასთან ამოწმებს, დაკმაყოფილებულია თუ არა გააქტიურების წინაპირობები.

სატესტო და სამუშაო რეჟიმი

e-Rechnung.gv.at-ისთვის შეიძლება არჩეულ იქნეს სატესტო და სამუშაო გარემო.

USP-ვებსერვისის წვდომის მონაცემები Odoo-ს პარამეტრებში ინახება.

ამგვარად, ინტეგრაცია ჯერ სატესტო გარემოში შეიძლება მომზადდეს, სანამ ინვოისების რეალური გაგზავნისთვის გამოიყენება.

ავტომატიზაცია დამატებითი სამუშაოს ნაცვლად

დამუშავებისას ჩვენი მიზანი არ იყო ბუღალტრისთვის კიდევ უფრო მეტი ღილაკის მიცემა.

პირიქით.

იდეა ასეთია:

რაც შეიძლება ნაკლები ხელით შესასრულებელი სამუშაო.

ინვოისი იქმნება Odoo-ში.

საჭირო სტრუქტურირებული ფორმატები ავტომატურად გენერირდება.

გაგზავნისას შესაბამისი ფაილები ავტომატურად მიემატება.

ხოლო შესაბამისად კონფიგურირებული ავსტრიელი მომხმარებლების შემთხვევაში ინვოისი დამატებით ავტომატურად შეიძლება გადაიცეს e-Rechnung.gv.at-ზე.

სწორედ ეს ავტომატიზაცია ქმნის განსხვავებას მარტივ ფაილის ექსპორტსა და ნამდვილად ინტეგრირებულ ელექტრონული ინვოისების გადაწყვეტას შორის.

მონაცემთა ხარისხი უბრალოდ არ იმალება

ჩვენი იმპლემენტაციის ერთი მნიშვნელოვანი საკითხი ასევეა:

ელექტრონული ინვოისი მხოლოდ იმდენად კარგი შეიძლება იყოს, რამდენადაც კარგია მონაცემები, რომლებისგანაც ის შექმნილია.

ამიტომ არ ვცდილობთ, არასრული სავალდებულო მონაცემები უხმოდ რაიმე მნიშვნელობებით ჩავანაცვლოთ.

თუ, მაგალითად, ZUGFeRD-ისთვის ან ebInterface-ისთვის სავალდებულო ინფორმაცია აკლია, Odoo-მ მომხმარებელს ამაზე ყურადღება უნდა მიაქციებინოს.

ამ შემთხვევებს მიეკუთვნება, მაგალითად:

  • მომხმარებლის ქვეყნის არარსებობა
  • ინვოისის პოზიციებზე საგადასახადო ინფორმაციის არარსებობა
  • საბანკო რეკვიზიტების არარსებობა

ჩვენი აზრით, ეს უკეთესია, ვიდრე ფორმალურად შექმნილი, მაგრამ შინაარსობრივად მცდარი ელექტრონული ინვოისის გაგზავნა.

ღია წყარო Odoo Community-ისთვის

ამ პროექტსაც უფასოდ, ღია წყაროს სახით ვაქვეყნებთ.

რატომ?

იმიტომ, რომ ჩვენც ვსარგებლობთ ღია წყაროს პროგრამული უზრუნველყოფით.

Odoo Community შესანიშნავ საფუძველს გვთავაზობს ERP-ისთვის, ბუღალტერიისა და ბიზნეს-პროცესებისთვის. თუ ყოველდღიურ მუშაობაში რაიმე ფუნქცია გვაკლია, ჩვენ თვითონ ვქმნით მას.

ხოლო თუ გადაწყვეტა სხვა კომპანიებისთვისაც შეიძლება საინტერესო იყოს, მას საზოგადოებას ვუზიარებთ.

ჩვენთვის ეს ცოცხალი ღია წყაროა.

ავსტრიაზე ორიენტირებული – მაგრამ არა მხოლოდ ავსტრიისთვის

პროექტს მკაფიო ავსტრიული აქცენტი აქვს.

ebInterface და e-Rechnung.gv.at განსაკუთრებით ავსტრიული კომპანიებისთვის არის საინტერესო.

ZUGFeRD-ის მხარდაჭერა კი ავსტრიის გარეთ მყოფი კომპანიებისთვისაც აქტუალურია.

ამრიგად, პროექტი მხოლოდ ავსტრიული გადაწყვეტა არ არის.

სწორედ სტრუქტურირებული ინვოისის მონაცემებისა და ავტომატურად გენერირებული PDF/A-3 დოკუმენტის კომბინაცია შეიძლება სხვა Odoo ინსტალაციებისთვისაც საინტერესო იყოს.

Odoo 19 Community-ისთვის

მოდულები შეიქმნა Odoo 19 Community-ისთვის.

რეპოზიტორი ამჟამად შეიცავს:

  • l10n_at_ebinterface
  • account_invoice_zugferd_ebinterface_auto
  • l10n_at_erechnung_gv_at

მოდულები ერთმანეთზეა დამოკიდებული, ამიტომ გამოყენების შემთხვევის მიხედვით მხოლოდ საჭირო კომპონენტების ინსტალაციაა საკმარისი.

ჩვენი წვლილი საზოგადოებაში

ამ პროექტს არ განვიხილავთ როგორც დასრულებულ კომერციულ პროგრამულ უზრუნველყოფას, არამედ როგორც წვლილს Odoo-ს საზოგადოების განვითარებაში.

შესაძლოა, ვინმეს მხოლოდ ebInterface სჭირდება.

შესაძლოა, სხვა კომპანიას ZUGFeRD სჭირდება.

შესაძლოა, კომპანიამ რეგულარულად უნდა გაუგზავნოს ინვოისები საჯარო დამკვეთებს e-Rechnung.gv.at-ის მეშვეობით.

სამივე შემთხვევაში ჩვენს პროექტს საფუძვლის შექმნა შეუძლია.

ხოლო რადგან წყაროს კოდი ღიად არის ხელმისაწვდომი, ყველა მომხმარებელს შეუძლია გადაწყვეტის შემოწმება, მოდიფიცირება და შემდგომი განვითარება.

ღია წყარო ნიშნავს: ერთად უკეთესობას

დარწმუნებული ვართ, რომ ღია წყარო განსაკუთრებით ERP სისტემებში დიდ უპირატესობას იძლევა.

კომპანიებს განსხვავებული მოთხოვნები აქვთ.

გადაწყვეტა, რომელიც ერთი კომპანიისთვის იდეალურად მუშაობს, სხვისთვის შესაძლოა ადაპტირება დასჭირდეს.

ღია წყაროს კოდით ეს შესაძლებელია.

ამიტომ გვიხარია:

  • უკუკავშირი
  • Bug Reports
  • გაუმჯობესების წინადადებები
  • Pull Requests
  • მხარდაჭერილი დამატებითი გამოყენების შემთხვევები

კარგი საზოგადოებრივი გადაწყვეტა სულაც არ იბადება პირველივე Commit-ით.

ის იქმნება მრავალი მომხმარებლისა და დეველოპერის მიერ შემდგომი განვითარების შედეგად.

პროექტის უფასოდ გამოყენება

სრული წყაროს კოდი საჯაროდ ხელმისაწვდომია GitHub-ზე:

GitHub – Odoo 19 Invoice E-Files

იქვე არის ინსტალაციის ინფორმაცია და ცალკეული მოდულების დოკუმენტაცია.

ავსტრიის e-Rechnung.gv.at-ვებსერვისის ინტეგრაციისთვის დამატებით საჭიროა Python-ის ბიბლიოთეკა Zeep.

ჩვენი წვლილი ღია Odoo-ს სამყაროში

ამ პროექტით გვინდა ვაჩვენოთ, რომ მცირე საკუთარმა დამუშავებებმაც კი შეიძლება მთელ საზოგადოებას დამატებული ღირებულება შესძინოს.

მოდულები თავდაპირველად კონკრეტული მოთხოვნების გადასაჭრელად შევქმენით.

ახლა ამ გადაწყვეტებს Odoo 19 Community-ის ყველა მომხმარებელს უფასოდ ვთავაზობთ.

ამგვარად, ინდივიდუალური დამუშავებიდან საზოგადოებრივი გადაწყვეტა შეიძლება გახდეს.

Odoo 19. ღია წყარო. ელექტრონული ინვოისები. ავსტრია. და უფასოდ საზოგადოებისთვის.

სწორედ ამისთვის გამოვაქვეყნეთ ეს პროექტი.

ერთად, და არა მრავალჯერ ცალ-ცალკე დამუშავება.

პროექტზე GitHub-ზე გადასვლა