When a request to the AEAT SII web service fails for a network or server reason - the connection times out, AEAT returns an HTTP 5xx, or the certificate handshake breaks - the corresponding SII History record is not marked Failed immediately. Instead, the localization decreases the Retries Left counter and renews the SII Job Retry Comm. Error job to fire again on a daily schedule. The document moves to Failed only when retries reach zero.
This topic describes how to schedule the retry job and what each retry attempts.
In this article
Schedule the Communication Error Retry job
Schedule the Communication Error Retry job
The retry job runs via the standard Job Queue framework. The localization automatically renews the job entry when a comm error is logged - if the entry doesn't exist yet, create it once.
- Click the
icon, enter Job Queue Entries and select the relevant link. - Select New.
- In the General FastTab:
- Set Object Type to Run to Codeunit.
- Set Object ID to the standard SII Job Retry Comm. Error codeunit.
- Set the Earliest Start Date/Time to the next time the job should fire (typically the morning after a failure).
- Set Status to Ready.
Note: The localization renews this job with a 24-hour interval (PeriodInSeconds = 86400). Avoid setting a different recurrence on the Job Queue Entry - it will be overwritten when the next comm error fires.
Retry behavior and counter
Each SII History record carries a Retries Left counter. When a request fails with a communication error:
- The error message is stored on the SII History record.
- Retries Left is decremented by one.
- If Retries Left > 0 (or the request was issued manually), Status is set to Communication Error, and the message includes "There are %1 automatic retries left before failure."
- The Job Queue Entry for the retry job is renewed.
- If Retries Left reaches 0 and the request was not manual, Status is set to Failed.
Initial retry counts are set when the request is first created (typically 4 for automatic batch submissions, 1 for manual retries).