1.TimeOut Problem AEAT
Depending on the traffic that occurs on the Tax Agency's servers, when the traffic is high, when waiting for a response, it returns a TimeOut, and in the case of a synchronous service, it is not possible to make a new request to retrieve the response. However, they process the Invoice as a server, but as long as it takes to process it, the connection cannot be kept open and ends up being closed, leaving the response incomplete.
This creates an inconsistency in the statements of the invoices between AEAT and SAP, since in AEAT these invoices have been processed, and since they are not able to return the response to the middleware, the statements of these invoices in SAP are not updated and remain in "Included in Batch" status.
We have been informed that the AEAT cannot do anything to improve the situation, so it is possible that this problem will be repeated on more than one occasion.
2. How to solve the problem of Time Out.
A process has been developed from the product to help customers deal with this problem. A new state has been created for the batches, "Time Out", so that when a response TimeOut occurs between the middleware and the AEAT, this error is picked up by FUSE or PI which sends a specific error code to SAP to mark the batch with this new state:
This change of status only affects batches, not intermediates.
If this happens, the invoices in SAP are in an "Included in Batch" status, as you can see in the image above, while in AEAT these invoices will have been processed and will have a status, either Accepted or Accepted with Errors, or without registering if any invoice has been rejected.
To resolve these state inconsistencies you have to do certain manual actions:
2.1.Previous Customizing
In order for the batches to be able to take the TimeOut state previously, it is necessary to parameterize the table /EDGE/SII_MP_013 - Equivalence between Middleware and eDocuments states:
| Status | Process Step |
|---|---|
| 504 | TIME_OUT |
2.2. Manual actions to be performed
To understand this problem, the first thing to do is to check the status of the invoices in the AEAT to see if they have been accepted or rejected.
Once we know the status of the invoices, through exceptional processing:
We change the intermediate states to the states indicated by the AEAT. That is, if the records are accepted, we mark them as accepted, if the records are rejected we mark them as rejected or if they have been accepted with errors we mark them as accepted with errors. Finally we change the status of the batch to a final state so that no live batch error (that an intermediate is in two batches at once in a state that is not accepted, partially accepted, rejected or discarded), either accepted, if all records are accepted, partially accepted if there is any rejection or rejected if all records are rejected.
Records that have been rejected should be corrected and resubmitted to the AEAT.
Important: You can choose to resend the records of a batch with a TimeOut error by putting the records of this batch back into a modification batch to get the AEAT to return the correct states to us without having to consult their status one by one. This way, with a modification batch, if the invoices were accepted in the first shipment with a TimeOut error, we will not get the "Duplicate invoice" error that would occur if the invoices were sent again in a registration batch.
Please note that this is possible for all types of invoices except Outgoing Invoice Payments and Incoming Invoice Payments. These two books are cumulative and if they are sent more than once to the AEAT, incorrect amounts will be added. It is therefore necessary to check the status of these invoices in the AEAT and, if they are accepted, not to send them again and to put them in the Cockpit with "Accepted" status so that the statuses (SAP and AEAT) are aligned.
The product cannot develop an automatic functionality for the Time Out problem, as there are invoices that cannot be automatically sent back to the AEAT without having checked their status, as is the case of FE collections and FR payments.
3. Recommendations
We recommend that the Batches contain no more than 1000 invoices, including a maximum of 750 invoices, as the larger the batch, the greater the risk of error in TimeOut. To do this, you can set the table "Conditions for batches SII":
