Outage

This section explains how to handle service outages for the E-Receipts solution.

There are two outage scenarios:

1. The integrator cannot reach A-Cube APIs (client-side connectivity issue).
2. MF1 and MF2 cannot communicate with each other (platform-side communication outage).

Scenario 1: client-side connectivity issue

If your system cannot communicate with A-Cube APIs, follow this process:

1. Record transactions in an Emergency Report during the outage.
2. Upload the emergency report after connectivity is restored:
   • POST /mf1/pems/{serial_number}/emergency-report
3. Notify the offline period:
   • POST /mf1/pems/{serial_number}/offline-period
4. If receipts were issued via API on the same fiscal day as the outage, close the active journal.
   • If not closed manually, the journal is closed automatically 24 hours after the first commercial document of that fiscal day is issued.

Scenario 2: platform-side connectivity issue

In this scenario, the two cloud modules (MF1 and MF2) cannot communicate with each other.

The platform reports this condition through notifications. To monitor status changes, poll:

• GET /mf1/notifications

For the first hour of MF1-MF2 communication issues, the system continues to operate normally.

• At T+30 minutes from detection, MF1 generates an INTERNAL_COMMUNICATION_FAILURE notification.
• At T+60 minutes, MF1 generates a STATUS_OFFLINE notification and fiscal operations are suspended.

When the STATUS_OFFLINE notification is received, E-Receipts automatically:

• closes the active journal
• changes PEM status from online to offline
• prevents the issuance of new receipts via API

After the STATUS_OFFLINE notification is received, the Merchant must:

1. Record all new transactions in an emergency report.
2. Submit the emergency report using one of the following methods:
   • Direct submission by the Merchant: call POST /mf1/pems/{serial_number}/emergency-report.
   • Submission through a supplier: send the report to the supplier through an external channel (for example, by email), then the supplier calls POST /mf2/pems/{serial_number}/upload-emergency-report.

Normal operations resume when MF1-MF2 communication is restored and a STATUS_ONLINE notification is received. The PEM status automatically changes from offline to online.

If communication is restored within 30 minutes of the INTERNAL_COMMUNICATION_FAILURE notification, MF1 sends a INTERNAL_COMMUNICATION_RESTORED notification. In this case, The PEM status remains online, no STATUS_OFFLINE notification is generated, and you can continue issuing receipts without additional actions.