How-to guide
Understand REGES Online reporting results
Distinguish delivery receipts from processing results, understand warnings and check an unconfirmed submission before sending it again.
Management AZ provides connection setup and delivery history. Reviewed basic employee reporting and correlated results have passed a real development trial. These controls remain separately enabled for each deployment; contract reporting and production rollout still require further acceptance.
For the current manual route, use the illustrated export and import guide. The API route is a separate integration; a file import does not submit a declaration to REGES.
Activate your personal account and obtain employer API access
1. Check the connection
In Management AZ, open Settings, then Data sources. Open the source labelled REGES Online reporting and API reporting.
Expand Connection settings and select Test connection. This checks access to the employer profile; it does not send employee or contract changes.
If the check fails, follow the credential and connection guide. Check the employer and environment before replacing credentials.
2. Read the delivery history
On the source page, look for REGES delivery history. A run records an attempt to exchange messages. Run completed describes delivery work; it does not mean that REGES accepted the employees or contracts.
Receipt counts are counts of receipt records, not accepted employees. No delivery runs yet means that this source has no recorded delivery attempts.
First, REGES receives a message and returns a receipt. Later, REGES processes the message and returns its result. A receipt alone is never final acceptance.
3. Understand the processing result
The meanings below apply to REGES API result messages. When saved-employee result checking is enabled, use the employee review page to see its matched final result. General delivery-run history is a separate view.
| Result stage | Meaning | Next action |
|---|---|---|
| Queued receipt | REGES received the message and placed it in its processing queue. | Wait for the processing result. Keep the receipt so the result can be matched to this message. |
| Processing continues | This result is successful, but REGES says that more related results are expected. It may also carry a warning. | Wait for the remaining results. Do not treat this event as the final result for the whole submission. |
| Accepted result | This message has a successful result and no further related results are expected. | Check that the result belongs to the intended message and record. One result does not confirm every item in a batch. |
| Accepted with a warning | This message succeeded and has an informational warning; no more related results are expected. | Read the warning in REGES. A warning alone is not a reason to send a successful message again. |
| Rejected result | REGES returned a failed result with an error. | Review the explanation and correct the data before preparing a new reviewed submission. |
| Unconfirmed result | A required result field is missing, invalid or contradictory, or delivery could not be confirmed. | Check the submission in REGES before sending it again. Ask your integration administrator to investigate. |
4. Handle an unconfirmed delivery
Do not repeatedly submit the same change after a timeout or an unconfirmed response. REGES may already have received it.
Select the correct employer in REGES and check the submission or ask the authorised employer administrator to check it.
For support, share the time of the attempt and available message, receipt and result identifiers. Keep passwords, tokens and employee identity data out of support screenshots.
For integration administrators
When result checking is enabled, the collector saves and checks the message, session, employer and result references before acknowledging one result. An interrupted acknowledgement pauses collection for investigation; it does not trigger another acknowledgement or resubmit the employee.
Detailed result descriptions can contain employee information. The saved reporting status keeps identifiers and result codes; check REGES for the full explanation of a rejection or warning.
Saved employee drafts and the local queue
The next rollout stage records a delivery attempt before contacting REGES. An interrupted or uncertain attempt must be checked before any resend; reopening the page must not submit it again. Credentials remain in managed secret storage.
A real development test needs an activated REGES account and authorised access to a test employer. Creating an account alone does not provide employer API access. Use fictional employee data only in the development environment.
Saved-record reporting is introduced in stages: prepare a draft, approve it locally, confirm delivery separately, then check the matched result. Your deployment must enable each required control. Saving an employee alone never sends data to REGES.
A draft keeps a fixed copy of the saved employee data and its message identifier. Preparing the same version again reuses the draft. If the employee changes before approval, prepare and review a new draft.
Incomplete or unsupported data blocks approval. The first mapping covers basic Romanian employee registrations and modifications; foreign identity details, disability data, corrections and contract reporting still need separate mappings.
Queued locally means that a manager approved a draft. Local approval alone never sends the message. Where sending is enabled, a separate confirmed action starts delivery. Saving an employee never submits a declaration automatically.
Review a saved employee draft in Management AZ
These controls appear only when saved-record reporting is enabled for your deployment. An organisation administrator must perform the review.
Open Settings, Data sources, then your REGES Online reporting source. Select Review saved employee reporting.
Find the employee by name and choose the saved employee. Select Register a new employee only for a person who is not already registered; choose Modify an existing REGES employee for a saved record linked to its REGES reference.
Select Prepare draft for review. Check the employee identity, address, operation and message identifier on the review page.
If approval is blocked, review the named fields in the employee record. Do not delete unsupported details just to pass the check. Cancel the draft if it is not the change you intend.
For a complete draft, tick the review confirmation and select Approve into local queue. The status becomes Queued locally. Nothing has been sent to REGES in this stage.
If the employee changed after preparation, return to the queue and prepare a new draft. If a request times out, reload the queue to check its saved outcome before trying again.
Send a reviewed employee when delivery is enabled
The sender is being prepared for release and stays disabled until the deployment and employer checks pass. When your administrator enables it, the approved employee review page offers a separate send confirmation.
Check the environment and REGES employer reference shown under Send the approved employee. For a trial, it must say REGES test environment and use an authorised test employer.
Tick the employer and environment confirmation, then select Send to REGES test environment. This sends the fixed approved employee data; it does not send other employees or contracts.
After a successful delivery, the page shows Receipt received — processing pending, the receipt identifier and who started the attempt. A receipt is still not final acceptance.
If the outcome needs investigation or the page times out, reload the saved review. An existing attempt removes the send control. Do not create duplicate declarations to work around an uncertain delivery.
If sending is unavailable, ask your integration administrator to check the employer reference, environment and connection. Keep passwords and tokens out of support messages. Manual file export and import remain available separately.
Check the result of a saved employee declaration
When result checking is enabled for your connection, open the saved employee review and look below Delivery to REGES. Checking results does not send the employee again.
Select Check REGES result. Each check reads one result from this connection history and saves it before confirming that it has been read. An older result may belong to another employee; only a matching result changes this employee status.
If the status says Waiting for a REGES result or REGES is still processing this message, check again later. No new result does not mean acceptance.
Accepted by REGES means a matching final successful result was saved. Accepted with a warning also needs you to read the warning in REGES. The message, receipt, result and entity references remain separate.
For Rejected by REGES, read the full rejection in REGES and correct the employee record before preparing a new declaration. For Result needs investigation or an unfinished check, contact your integration administrator; do not resend the employee to clear the status.
Read Code, CodeType and RelatedResultsExpected together. Missing or contradictory fields must stay unconfirmed. The table describes one result event; it is not a batch-level decision or a retry policy.
A valid final result can remain accepted even when confirming its queue read is interrupted. The saved result and the unfinished collection warning describe separate facts. Do not resend the employee to fix that warning.
Code | CodeType | RelatedResultsExpected | Result interpretation |
|---|---|---|---|
SUCCES | SUCCES | false | Accepted result |
SUCCES | WARNING | false | Accepted with a warning |
SUCCES | SUCCES / WARNING | true | Processing continues |
FAIL | ERROR | true | Processing continues |
FAIL | ERROR | false | Rejected result |
For example, SUCCES combined with ERROR is contradictory and stays unconfirmed. An absent CodeType must not be treated as successful processing.
Keep the original message, receipt and result identifiers distinct. When result checking is enabled, a dedicated consumer acknowledges one result only after durable recording and correlation. Interrupted acknowledgement is never automatically retried, and checking never resubmits an employee.
Official REGES API protocol and schema
A real development test from start to finish
On 18 October 2026 we activated a dedicated fictional test register, stored its API credentials in Google Cloud Secret Manager, and sent one reviewed employee from a local Management AZ deployment to the actual REGES development API. REGES returned a receipt and a matched final successful result; the employee then appeared in the REGES employer portal after refresh.
The screenshot below shows the real receipt and accepted result. The local sign-in and connection lookup were test fixtures; REGES responses and secret storage were real. This verifies one basic employee creation in development, not production deployment or contract reporting.
