Tax level code multi

[blaggacao]

This is towards fixing: #10 (I guess I need such semantics for my data layout).

[codecov]

Codecov Report

Merging #15 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #15   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          88     88           
  Lines        1934   1935    +1     
  Branches       91     92    +1     
=====================================
+ Hits         1934   1935    +1

Impacted Files	Coverage Δ
facturark/composers/party_tax_scheme_composer.py	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5105767...ce42ded. Read the comment docs.

[blaggacao]

Still have to check what to do with:

    def get_supplier_tax_scheme(self, document):
        return document.find(
            ('.//fe:AccountingSupplierParty/fe:Party/fe:PartyTaxScheme/'
             'cbc:TaxLevelCode'), vars(NS)).text

    def get_customer_tax_scheme(self, document):
        return document.find(
            ('.//fe:AccountingCustomerParty/fe:Party/fe:PartyTaxScheme/'
             'cbc:TaxLevelCode'), vars(NS)).text

and with

    def _review_customer_identification_type(self, element):
        value = self.analyzer.get_customer_identification_type(element)
        self.check(IDENTITY_DOCUMENT_TYPES, value)

    def _review_supplier_tax_scheme(self, element):
        value = self.analyzer.get_supplier_tax_scheme(element)
        self.check(TAX_LEVELS, value)

I think I'll prepare fixups if I'm clear about that...

[tebanep]

Still have to check what to do with:

    def get_supplier_tax_scheme(self, document):
        return document.find(
            ('.//fe:AccountingSupplierParty/fe:Party/fe:PartyTaxScheme/'
             'cbc:TaxLevelCode'), vars(NS)).text

    def get_customer_tax_scheme(self, document):
        return document.find(
            ('.//fe:AccountingCustomerParty/fe:Party/fe:PartyTaxScheme/'
             'cbc:TaxLevelCode'), vars(NS)).text

and with

    def _review_customer_identification_type(self, element):
        value = self.analyzer.get_customer_identification_type(element)
        self.check(IDENTITY_DOCUMENT_TYPES, value)

    def _review_supplier_tax_scheme(self, element):
        value = self.analyzer.get_supplier_tax_scheme(element)
        self.check(TAX_LEVELS, value)

I think I'll prepare fixups if I'm clear about that...

I didn't notice this in #16. I'll see what I can do. Think it's bettter to use findall.

[tebanep]

I think the change is bigger than I previously fathomed. For validation, we'll have to add the listName attribute to TaxLevelCode to know if it is "8.10 Tipos de Régimen IVA", "8.13 Tipos de Representación", "8.14 Tipos de obligaciones responsabilidades", etc. I don't know if this is something we should handle explicitly as this attribute is not mandatory and almost always the TaxLevelCode will be either 0 or 2.

For example, this XML fragment is taken directly from an electronic invoice of Certicamaras:

fe:PartyTaxSchemecbc:TaxLevelCode2</cbc:TaxLevelCode>cac:TaxScheme/

As it can be seen, they don't include the listName attribute and the assumed list is "8.10 Tipos de Régimen IVA".

The alternative is to compare each value to be inside any of the mentioned lists. The sets do have some intersections, for example, the value 2 is both in the following sets:

8.10. Tipos de Régimen IVA

TAX_LEVELS = {
    "0": u"Simplificado",
    "O-11": u"Común",
    "2": u"Común"
}

8.9. Tipos de Organización Jurídica; Tipos de Adquiriente;

PARTY_TYPES = {
    "1": u"Persona jurídica",
    "2": u"Persona natural",
    "3": u"Gran contribuyente"
}

But this possible eventual confusion is not as impactful as to demand such greater complexity in the json construction. It doesn't seem to be that important for DIAN. If it was, they would have made the attribute mandatory.

I will proceed with the any of the mentioned lists strategy and see how it goes.

[blaggacao]

I will proceed with the any of the mentioned lists strategy and see how it goes.

That seems like a good solution. I hope the specs of the DIAN are accurate to this extend (not mandatory). They maybe have a similar validation strategy internally.