SII Communication Error Retry

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

Retry behavior and counter

Manual retry actions on the SII History page

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.

  1. Click the icon, enter Job Queue Entries and select the relevant link.
  2. Select New.
  3. In the General FastTab:
    • Set Object Type to Run to Codeunit.
    • Set Object ID to the standard SII Job Retry Comm. Error codeunit.
  4. Set the Earliest Start Date/Time to the next time the job should fire (typically the morning after a failure).
  5. 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:

  1. The error message is stored on the SII History record.
  2. Retries Left is decremented by one.
  3. 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."
  4. The Job Queue Entry for the retry job is renewed.
  5. 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).

Manual retry actions on the SII History page

In addition to the automatic retry job described above, the SII History page has three manual actions that let you resubmit or inspect a document on demand. These actions replace or supplement the standard actions of the same name and handle both back-office and POS (retail) SII History records.

Action What it does
Retry Resubmits the selected record(s) with a status other than Accepted - for example Pending, Communication Error, Rejected, Failed, or Accepted With Errors. Use this to manually push through documents that have not yet been accepted, without waiting for the automatic retry job.
Retry Accepted Resubmits the selected record(s) that already have status Accepted, explicitly flagging the new request as a correction/error-retry of an accepted document. Use this only when a document that AEAT already accepted needs to be resent (for example, to correct it).
Download XML Doc. Generates the SII XML request for the selected record's underlying POS transaction and offers it as a downloadable .xml file, named after the transaction's Receipt No. Available only for records that originate from a retail (POS) transaction linked to the current user's store and POS terminal; for other records the action has no effect.

Note: Whether Retry and Retry Accepted act on just the selected line or on every matching pending record depends on the Enable Batch Submissions setting on the SII Setup page. See Batch submission threshold (optional).

Note: The standard Microsoft Retry All action is still present on the page and is not changed by the localization.