Recommendations for integrations in the face of intermittency scenarios or DIAN Timeouts
Sumario
Recommendations for integrations in intermittency scenarios or DIAN Timeouts
In scenarios of intermittency or slowness in the DIAN response, the following are described:
Timeout failure points:
In a failure risk analysis we say that we must consider 4 points mainly from the source of timeouts.
- In the request sent to TFHKA by the system: This case is identified because when resending a document to our platform or when checking the status of the document, it will not be reported that one exists previously. There is a low probability of a transaction that has been received, but due to an internal transactional error, it is rolled back and although there is evidence of its receipt, the platform will act as if it had no prior record. However, this scenario is less than 0.01% of our transactions.
- In the request from TFHKA to the DIAN: This case is identified in a similar way to the one indicated previously. However, we have seen that in times of instability of the DIAN platform, which can occur in the face of greater exchange controls. This scenario not only corresponds to network issues (non-reach of network packets), but is sometimes due to inconclusive processes within the DIAN system itself (similar to what was previously indicated for TFHKA, we do not know a probability rate of this scenario).
- In the DIAN's response to TFHKA: We have recorded long validation times by the DIAN platform, sometimes (very very rarely) exceeding 10 min. These cases are known because the TFHKA platform, although it is unaware of the conclusive status of the transaction in the DIAN, when it is consulted for it (once it has been validated, which may require several attempts), a definitive validation response is obtained from the DIAN. .
- In the TFHKA response to the system user: It is detected because there is a completed transaction (except when we are talking about scenarios 2 or 3) on our platform obtainable by status queries and document download.
When the DIAN has delays in processing:
Error codes 100/500 respond to difficulty communicating with the DIAN platform or to an unexpected response from the DIAN validation process. In any next transactional attempt of the same fiscal consecutive, the following occurs:
a) The DIAN tells us that the document has already been previously processed.
b) The TFHKA platform, identifying that it is a scenario 3, seeks to execute the transactional reconstruction of that fiscal consecutive, indicating as valid the record that originated the transaction and returning the UBL that corresponds to that transaction.
c) Given that the transactional attempt that triggered the reconstruction process is different at the content level from the document that had been previously validated in the DIAN, but that had not been able to obtain conclusive status, a disparity or inconsistency of information in the document.
d) The Factory HKA Colombia has in its logs multiple transactional attempts in its entries, but only one of them is the one correctly validated by the DIAN (The first one actually delivered to the DIAN that meets the validation conditions, It is important to highlight that previously there may have been other cases that were rejected by DIAN validation or that remained in scenario 2). Given that this validation process concluded in a timeout or in an unexpected connection error, it could be in scenarios 2 and 3.
e) The next transactional attempt is the one that "reveals" that scenario really was 3 and the transactional reconstruction with the previously validated document is required. (This occurs because the transaction retry is generated before our automatic reconstruction processes can find the final status of the DIAN.) If the latter occurs then the response from our platform is "previously generated document" preventing the scenario from being even more complex.
Recommendations:
1) Code 102: Invalid document number:
2) Code 200 with esValidoDIAN = true:
3) Code 200 with esValidoDIAN = false:
Generally, when the DIAN is intermittent, its response times increase considerably, which can cause time Outs at points 2, 3 and 4 as shown in the following image:
When time Out occurs on links 2, 3 and 4 (communication with the TFHKA-DIAN), this is where it becomes more complex due to the following scenarios:
- Expiration of the connection waiting time between TFHKA-DIAN (link 2), which causes the document to remain on hold or in process and the ERP could have received code 100, 103 or a time out exception, in these scenarios In most cases the ERP can do the forwarding and The document will be processed since our WS, upon detecting whether the document already exists in the DIAN, carries out a reconstruction process to close the transaction correctly.
- A response is received from the DIAN but with an unexpected structure (link 3), for example the Response app (DIAN validation) arrives empty or the DIAN returns an unexpected code as a result of the intermittency. This scenario is the most complex and is in which sometimes many invoices have to be regenerated manually, many times in this situation our platform even returns a 200 and a CUFE but this does not mean that the document was authorized by the DIAN since in the property esValidoDIAN is returned 'false'.
Additionally, it is important to always keep in mind the scenario or contingency billing since in the event of technological intermittency or latency this billing scheme is defined in the regulations.
Copyright © 2016 The Factory HKA. All rights reserved.