Directive Journal

Help and reference · 2 MIN READ

Read an error and recover safely

Use the public support code and precise reason to choose the next step.

Guide reviewed 14 September 2026 · Controls depend on your app version and access.

Before you begin

Keep the screen open long enough to record the message. Do not include passwords, tokens or full customer datasets in a support request.

  1. 01Record what happened

    Note the action, app, time, company and record identifier. Capture the public code and any reason code or request/trace identifier shown in the error details.

  2. 02Read the identifiers

    The shared public code uses five digits: the first two identify a service and the last three identify the failure class. A reason code narrows the condition. For example, permission failure and service unavailability call for different responses.

  3. 03Check before retrying a write

    For a save, payment, receipt, conversion or stock movement, reopen the record and inspect its history first. The response may have failed after the server accepted the operation.

  4. 04Use the dictionary

    Search the error dictionary by code, reason or message. Follow the relevant recovery guidance; a technical retryable flag does not mean blindly repeating a business action is safe.

  5. 05Escalate with context

    Send the code, request identifier, affected record and steps that led to the problem to support. For widespread unavailability, also check Services status.

Check the result

You have either resolved the cause or supplied enough non-secret context for support to investigate.

If something does not look right

Not every client message has a shared numeric code, and deployed versions can differ from the catalogue. An unknown code should be reported exactly as displayed, not guessed from a nearby number.

Look up an error