Repository navigation
Company created with its DIČ stays on 9950 + IČ DPH (no endpoint at all without a VAT number) #5
Description
A res.company created with vat and l10n_sk_dic in one save (the company form) leaves its partner on 9950 + IČ DPH, and a company with only a DIČ gets no endpoint, while a res.partner created with the same values goes to 0245 + DIČ; the export constraint passes because a DIČ is recorded, so the DIČ-only company exports invoices that fail PEPPOL-EN16931-R020, BR-06 and BR-CO-26, and action_l10n_sk_adopt_dic_participant fixes both but is not reachable from the UI. Tested on 1dd85c2 with Odoo 19.0 Community; drop-in test below (the contact control passes, the two company cases fail).
from odoo.tests import TransactionCase, tagged
@tagged('post_install', '-at_install')
class TestCompanyDicParticipant(TransactionCase):
@classmethod
def setUpClass(cls):
super().setUpClass()
cls.sk = cls.env.ref('base.sk')
def test_control_contact_with_vat_and_dic(self):
partner = self.env['res.partner'].create({
'name': "SK Kontakt s.r.o.", 'country_id': self.sk.id,
'vat': "SK2020317068", 'l10n_sk_dic': "2020317068"})
self.assertEqual((partner.peppol_eas, partner.peppol_endpoint), ('0245', "2020317068"))
def test_company_created_with_vat_and_dic(self):
company = self.env['res.company'].create({
'name': "SK Firma s.r.o.", 'country_id': self.sk.id,
'vat': "SK2020317068", 'l10n_sk_dic': "2020317068"})
partner = company.partner_id
self.assertEqual((partner.peppol_eas, partner.peppol_endpoint), ('0245', "2020317068"))
def test_company_without_vat_gets_an_endpoint(self):
company = self.env['res.company'].create({
'name': "SK Neplatitel s.r.o.", 'country_id': self.sk.id, 'l10n_sk_dic': "2120000016"})
partner = company.partner_id
self.assertEqual((partner.peppol_eas, partner.peppol_endpoint), ('0245', "2120000016"))
Activity
sync: l10n_cssk@6082d044
Rad0van commentedon Oct 24, 2026
Thanks for the precise report and the drop-in test — confirmed and fixed in 208b7f6 (
l10n_sk_ubl_bis319.0.3.2.0).Cause.
res.company.createbuilds the company's partner from a fixed set of values (name,vat,country_id, …) that never includes the DIČ, and flushes it, sopeppol_easis computed before the relatedl10n_sk_dicis written through. With an IČ DPH that gives9950:<IČ DPH>; without one, core falls back to the first SK code — also9950— with no endpoint. When the DIČ arrives a moment later,9950is a valid SK code, and our compute deliberately keeps a valid scheme as chosen. A contact gets every value in one write, which is why your control case passed.Fix.
res.company.createnow runsaction_l10n_sk_adopt_dic_participanton the partners core created for the new companies (using core's own condition for creating one). Apartner_idpassed in is left alone, since its scheme may be a deliberate choice.Your three tests are in
tests/test_peppol_eas_sk.py, along with company creation throughincome_tax_id, an existingpartner_idkeeping its scheme, and the server action. Without the fix, exactly the three company cases fail.Companies created before this fix are not moved by the upgrade. Open the company's contact and run Peppol: use 0245 + DIČ from the Action menu.
A DIČ entered later on an existing company or contact still doesn't change a
9950scheme by itself. That is the module's general rule (an existing valid scheme may have been chosen), and the same action is the remedy.4ktLuffy commentedon Oct 24, 2026
Thanks for the quick fix and the clear explanation. I re-ran my three tests on 208b7f6 and they pass, along with the rest of the module's tests. I'll open the next findings as separate issues, one at a time.
sync: l10n_cssk@6082d044