Recommendations for integrations in the face of intermittency scenarios or DIAN Timeouts

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.

1. 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.
2. 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).
3. 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. .
4. 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:

Our platform to deal with scenarios 2 and 3, leaves incomplete transactions in an "intermediate" status, carries out subsequent processes to search for definitive and conclusive status of these transactions, identifying Rejections, validations and/or non-existence. The first two update the transaction that generated the event (the ubl sent that had the timeout), here this point is very important in the case of retries and consumption of consecutive ones, because the DIAN only validates one of the transactional attempts so the one that is validated is the one that must be updated. For cases of non-existence, the first transactional attempt is inactivated and a resend is allowed to give conclusive status to it.

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:

The most appropriate thing is not to reuse consecutive fiscals and generally avoid reusing it in time periods of less than 2 hours. Given that a transactional reattempt by a consecutive prosecutor may, as explained above, try to rescue a definitive transactional status in the DIAN, which he could not obtain in previous attempts. In times of DIAN processing difficulties, they can last dozens of minutes, so a set of transactions can be generated that conclude in a timeout consecutively and that make processing clarity more complex. However, if the reshipment is the same tax content - as we suggest -. Regardless of which of all these attempts concludes satisfactorily before the DIAN from the fiscal and tax point of view, it is the same document and thus avoid inconsistency in the documents.

1) Code 102: Invalid document number:

In this case, the message is associated with a document that has not been transmitted to the platform or whose issuance resulted in a rejection. In this last scenario and in case the system stores the response of each document, the causes that generated the rejection of said document must be validated in the response of the Send method, when reading the array messajesValidacion , or validate the causes of rejection in the Rejected Documents section of the portal. In this scenario, it is recommended to resend the document.

2) Code 200 with esValidoDIAN = true:

The document has been satisfactorily processed and has the ApplicationResponse from the DIAN. In this case, they can download PDF (standard RG), XML Invoice, XML AttachedDocument, forward the notification email to the acquirer and, in the case of issues with attachments, synchronize the attached files corresponding to the document to complete the issuance cycle of the same before the platform and the notification email is delivered to the acquirer.

3) Code 200 with esValidoDIAN = false:

The document is satisfactorily processed by the platform, however, it is waiting for the ApplicationResponse from the DIAN (intermittency scenario during its issuance). In this scenario, it is recommended to check the status again after 1 hour. If this scenario persists after a third attempt, we recommend notifying us via email indicating the NIT and the consecutive number, in order to carry out the corresponding validations and if found in the DIAN platform registry, the respective update is carried out before the TFHKA platform so that it can be consulted from the system.

Workflow with suggestions on how to handle different scenarios of the Electronic Invoicing operation

WorkFlow

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:

Response Time

Generally if a time Out occurs on link 1 (ERP-TFHKA), this may be the client's internet or our platform is experiencing latency, in this scenario it is not possible to reach the DIAN , the codes that the platform generally returns are 100, 103 or an exception is generated due to time out or due to link time configured in the ERP. In these scenarios, if the latency persists, it is important to always keep in mind to issue due to 'contingency '.

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:

1. 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.
2. 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'.

Once the above has been indicated, in all the previous TFHKA scenarios, that is, in the presence of codes 100, 103, 200, etc., it is always important to validate the state of the esValidoDIAN = 'True' property since if This property is 'false', it is an indication that the document cannot be validated before the DIAN in the synchronous connection. Some integrations do not validate this property and it is very important to control the validation status.

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.

Workflow, with tips on how to handle different billing scenarios

Workflow

THE FACTORY HKA COLOMBIA
Copyright © 2016 The Factory HKA. All rights reserved.