Skip to main content

Auto-Retry

The Auto-Retry screen schedules a recurring sweep that replays every invoice in a chosen technical-error status back to the Plateforme Agréée (PA). The default row sweeps status 9904 (Send failed) every night at 3 a.m. — the overnight batch's safety net so that anything stuck on the PA side at the close of business is picked up before operations resume in the morning.

Multiple rows can coexist: one per (hour, status list) combination. The same code path drives the manual Resend all N button on the Tech Dashboard's Send Failed card, so the manual replay and the scheduled replay produce identical results — one is fired by hand, the other by cron.

The page applies regardless of source system — JD Edwards, SAP, NetSuite or a custom ERP. The replay reads F564231 to pick invoices in scope and calls the configured PA api-connector for each one; the source format is transparent.

Added in 2026.06.03

The page is brand new. It pairs with the new Send Failed card on the Tech Dashboard — the dashboard does the immediate one-click replay, Auto-Retry does the unattended overnight pickup. The two use the same replay engine and respect the same per-call throttle (default 100 ms).

Opening the editor​

  • Sidebar → Configuration → System → Auto-Retry.
  • Or from the Tech Dashboard → Send Failed card → Schedule recurring… link (shortcut from the manual button to the catalogue).

At a glance​

Auto-Retry＋ AddStatus (multi) ▾☑ Enabled only↻ RefreshOvernight send-failed sweepReplays every invoice in technical-error status to the PAEvery day · 03:00 Europe/Paris · throttle = 100 msStatuses: 9904 (Send failed) · Lookback: 7 daysENABLEDlast run 06/03 · 12 retriedEditMid-day tech-error catch-upHourly retry on every technical-error bucketEvery hour · 50-minute offset · throttle = 250 msStatuses: 9904, 9905, 9907 · Lookback: 24 hoursENABLEDPA-outage drain (manual trigger)Throttled drain — re-enable after a PA incidentDisabled by default · throttle = 50 msStatuses: 9904, 9905, 9907, 213 · Lookback: 0 (no filter)DISABLEDAdd sweepOne row per scheduleCron-style scheduleHour + minute + timezoneMulti-status pickerTagged Error – tech onlyEnable / disablePause without deleting

Sweep fields​

Each row is one entry in the catalogue. The edit pane has four sections.

1. Identification​

FieldRequiredWhat
NameyesFree text. Shown in the catalogue list and on the Tech Dashboard's Scheduler card. Example: Overnight send-failed sweep.
DescriptionnoOne-line caption to help colleagues understand what the sweep is for.
Enabledyes (default: on)When off, the row stays in the catalogue but the scheduler skips it. Useful for pausing during a maintenance window or a deliberate PA outage.

2. Schedule​

FieldRequiredWhat
Houryes (default: 03)Hour of day in 24-h format. The sweep fires at that hour exactly.
Minuteno (default: 00)Minute of the hour. Use this to spread several sweeps across an hour so they don't all start at the same second.
Timezoneyes (default: server timezone)IANA timezone (e.g. Europe/Paris). Each sweep runs in its own timezone so a multi-region install can stagger sweeps per region.
Cadenceyes (default: daily)daily, hourly, or every N hours. Hourly + a 50-minute offset gives a sweep at 00:50, 01:50, … — a busy install benefits from the higher cadence; the default daily 03:00 is enough for most.

3. Status filter​

The multi-select picker lists only statuses tagged Error – tech in the Status catalogue:

CodeLabelWhen it applies
9904Send failedPA submission rejected at HTTP level (timeout, 4xx, 5xx). The default sweep target.
9905Mock send failedSame as 9904 but in mock mode. Typically only seen during testing.
9907Status retrieval failedPA submission landed but the lifecycle poll keeps erroring.
213PA technical rejectionThe PA side reported a technical reject after acceptance.

Pick one or several. A single row can sweep every tech-error bucket at once — useful in a single nightly catch-up that covers everything.

Business-error statuses (206, 207, 208, …) are deliberately not selectable here — they need operator action upstream, not a blind replay. The picker enforces that constraint.

4. Replay options​

FieldDefaultWhat
Lookback window0 (no time filter)When set, restricts the sweep to invoices whose status was last updated within the window (in hours or days). 7 days is the typical catch up on the last week setting; 0 means every invoice in the matching status, regardless of age.
Throttle100 msDelay between two PA calls. Matches the manual Resend all button on the dashboard. Raise it (250 ms, 500 ms) for installs where the PA rate-limits aggressively; lower it (50 ms) for a one-off drain after a PA outage.
Max invoices per rununlimitedCap the sweep at N invoices to bound the run time on big batches. The sweep picks the oldest matching invoices first and stops at N; the rest are picked up on the next scheduled run.

What happens at the scheduled hour​

The scheduler is a daemon inside NomaUBL that wakes up every minute and checks every enabled row for next-fire time. The query is cheap; the catalogue is small.

StepWhat
1. Select invoicesSELECT * FROM F564231 WHERE current_status IN (<status_list>), with optional last_update >= NOW() - <lookback> and LIMIT <max> when set. Oldest first.
2. Replay each oneFor every invoice, call the PA api-connector's submit task — same code path as the original Send action. The lifecycle row is updated with the new status.
3. ThrottleWait <throttle> ms between two calls.
4. Honour CancelThe sweep checks for a cancel signal between two invoices — operators can cancel from the dashboard's Scheduler card without waiting for the run to finish.
5. Log the runWrite a row to F564237 with the sweep name, the start / end timestamp, the count processed / succeeded / failed. Visible on the Tech Dashboard's Live process events widget.

The run progress is also visible in the shared progress window — same component as the manual Resend all button. Click any active sweep on the Scheduler card to open it.

If the scheduler is offline (server stopped, JVM crash) when a row was due to fire, the run is skipped silently — there is no missed-run replay. The next scheduled hour fires normally. To pick up missed work, run the manual Resend all on the dashboard or trigger the row from the catalogue with Run now.

Run-now button​

Each row in the catalogue has a Run now button that fires the sweep immediately, using the row's current configuration. Useful for:

  • Verifying a new sweep before letting it run on its schedule.
  • Recovering a missed run after a server restart.
  • One-off catch-up after a PA outage — flip a disabled PA-outage drain row on, Run now, flip it off when done.

The Run now run honours the same throttle, same lookback, same status list as a scheduled run. It does not advance the scheduled-run cadence — the next scheduled time still fires.

Tips & best practices​

  • Keep the default 03:00 sweep alone. It covers the most common case (overnight batches stuck on the PA). Adding a row only makes sense when you need a different cadence or a different status set.
  • Spread sweeps with a minute offset. Two sweeps both firing at :00 compete for connection pool slots. Stagger them at :00, :15, :30 to flatten the load.
  • Raise the throttle when the PA rate-limits. A 429 Too Many Requests after a few minutes of sweeping is a hint to bump the throttle to 250 ms or 500 ms. Match the throttle to the PA's documented per-second budget.
  • Disable rather than delete during a known outage. A row marked DISABLED is intentional and visible; a deleted row is invisible and easy to forget when the outage ends.
  • Don't replay business errors. The picker blocks it. If an invoice is in 207 (Disputed by recipient), no amount of replay fixes it — only operator action upstream does.
  • Use the dashboard for one-shots, Auto-Retry for habits. The two paths share code; what differs is who fires them. A one-off drain after an incident is a click; the daily safety net is a row.

Troubleshooting​

SymptomLikely causeFix
Scheduled row doesn't fire.Row is DISABLED.Open the row, toggle Enabled on, save.
Row fires but processes zero invoices.The status list and the lookback window combine to zero matches.Inspect the E-Invoicing page with the same status filter; either widen the lookback or relax the status list.
Sweep finishes but the count is far below the Send Failed card's number.The dashboard counts every 9904 regardless of age; a row with a 7-day lookback ignores anything older.Either drop the lookback (0 = no filter) or schedule a second row with a wider lookback for old back-stock.
429 Too Many Requests errors in the run log.PA rate-limit hit.Raise the throttle (e.g. 100 ms → 250 ms) on the row and re-run.
Two rows both fired at 03:00 and one stalled the other.No minute offset — they hit the connection pool simultaneously.Stagger the rows (:00, :15, :30).
Run now button is greyed out.The sweep is already running (a scheduled or earlier Run now).Open the dashboard's Scheduler card → click the active row → use the modal's Cancel if needed, or wait.
Last-run badge stays never on a new row.The row's hour is in the future — it hasn't fired yet — and no Run now has been clicked.Click Run now to verify the configuration; the next scheduled run lands as expected.

What's next​

  • Tech Dashboard → Send Failed — the one-click manual replay; same code path, fired by hand.
  • Shared progress window — the modal every long-running operation opens.
  • E-Invoicing → the PA api-connector that the replay calls; tune timeouts and retry counts there.
  • Statuses — the catalogue of status codes, including the Error – tech tag that filters the multi-status picker on this page.
  • Daily Digest — schedule a daily email summarising the integration errors; useful pairing with Auto-Retry so the on-call team sees what the sweep couldn't fix.