Home / Questions / 242958
Accepted
moneyBox
Asked: 2020-03-05 19:37:37 +0800 CST 2020-03-05 19:37:37 +0800 CST

DIAN NIT Error when consuming Electronic Invoice service

  • 772

I am uploading an invoice to the DIAN tax entity in Colombia and at first I had details about missing elements in the XML, after polishing this part now the DIAN Soap webservice returns the following error message:

Parameters [ NIT=ERROR DOCNUMBER=OK ISSUEDATE=OK ]

The Request I generate is...

For obvious reasons I have filled the real NIT with "x", as well as other security elements of the Soap-Header.

I have already verified in detail:

  1. That the Issuer NIT is well written and correct.
  2. That the NIT of the Issuer exists in the DIAN (use that of Legal Entity).
  3. That the Receiver NIT is different from the issuer.
  4. That the Receiver NIT Exists in the DIAN (use the Natural Person).
  5. I am making the requests to the Test WebService (enablement) of the DIAN.
<soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rep="http://www.dian.gov.co/servicios/facturaelectronica/ReportarFactura">
    <soapenv:header>
        <wsse:security soapenv:mustunderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:usernametoken wsu:id="UsernameToken-2">
                <wsse:username>3bxxxxxx-7xxx-4xxx-bxxx-39xxxxxxxxxx</wsse:username>
                <wsse:password type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile1.0#PasswordText">1d97....ae</wsse:password>
                <wsse:nonce encodingtype="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary">bW...MQ==</wsse:nonce>
                <wsu:created>2019-03-04T22:19:11.000Z</wsu:created>
            </wsse:usernametoken>
        </wsse:security>
    </soapenv:header>
    <soapenv:body>
        <rep:enviofacturaelectronicapeticion>
            <rep:nit>901xxxxxx</rep:nit>
            <rep:invoicenumber>PRUE980000000</rep:invoicenumber>
            <rep:issuedate>2019-03-04T22:19:11</rep:issuedate>
            <rep:document>UEsD....FbXBhcw==</rep:document>
        </rep:enviofacturaelectronicapeticion>
    </soapenv:body>
</soapenv:envelope>
php

1 Answers

  1. Best Answer

    After 3 days (which seemed like weeks hehehehe), it has been resolved!

    Same story "the DIAN never answered my emails or calls", I ended up solving it at the point of breaking stones and dealing with things that even had nothing to do with the error message.

    This resolution is undoubtedly one of the most "stupid" and interesting because it makes it clear that the DIAN Tax Entity in Colombia has a long way to go in terms of Electronic Invoicing, specifically in the "Debugging" part of the information it receives your webservice, without a doubt this is a huge challenge for any developer who wants to integrate their software to Electronic Invoice.

    The resolution was: Do not use accented words in the contents of the arguments in any tag

    An example:

    Mistake:

    <fe:AccountingSupplierParty>
    <cbc:AdditionalAccountID>1</cbc:AdditionalAccountID>
    <fe:Party>
    <cac:PartyIdentification>
        <cbc:ID schemeAgencyID="195" schemeAgencyName="CO, DIAN (Dirección de Impuestos y Aduanas Nacionales)" schemeID="31">900123123</cbc:ID>
    </cac:PartyIdentification>

    Success:

    <fe:AccountingSupplierParty>
    <cbc:AdditionalAccountID>1</cbc:AdditionalAccountID>
    <fe:Party>
    <cac:PartyIdentification>
        <cbc:ID schemeAgencyID="195" schemeAgencyName="CO, DIAN (Direccion de Impuestos y Aduanas Nacionales)" schemeID="31">900123123</cbc:ID>
    </cac:PartyIdentification>

    This is so stupid, but it will save you days dealing with messages that have absolutely nothing to do with the error messages thrown by the DIAN tax entity in Colombia.

    The saddest, funny or clumsy thing, I don't know how to mention it anymore, is that the DIAN tax entity in Colombia has already released a development kit with a "modified" version 2.0 of the UBL standard, which is why I think it's too immature to want to think about migrating . to another standard when the current one cannot be well polished. Luck!

    • 3