[Feature] pre-flight check

[blaggacao]

I personally find an API like this:

'id': {
    "@attributes": {
        "schemeAgencyID": "195",
        "schemeID": "31",
        "schemeAgencyName": "CO, DIAN (Direccion de Impuestos y Aduanas Nacionales)"
    },
    "#text": "810849728"
}

not optimal, given that this is redundant information. Same goes for

{
    "@attributes": {
        "currencyID": "COP"
    },
    "#text": "885.00"
}

Before stabilizing API would you accept to run a processor which infers those values from document_currency_code or otherwise contextual information (like legal money will always be "CO" or the Agency Scheme will always be the one of the DIAN)?

[blaggacao]

A made a quick basis for discussion here: https://github.com/nubark/facturark/pull/14

[tebanep]

Hi @blaggacao. I'd rather stay with the current API for a while (if not forever), as a modification would generate a great impact in all the composers. The current approach is based in several formats, to name a few:

• http://badgerfish.ning.com/
• https://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html
• https://docs.apigee.com/api-platform/reference/policies/xml-json-policy
• https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/rapim_ref_ootb_policyxml2json.html
• https://community.apigee.com/articles/1839/converting-between-xml-and-json-what-you-need-to-k.html

The format in use doesn't support namespaces, but that is something facturark should be providing anyway. It however provides enough clarity and ease of parsing (specially for the attributes), without becoming too verbose. I think we should concentrate in other areas right now for the foregoing reasons.

[blaggacao]

Alright, sounds like a good plan. Didn't know of those resources...