Understand the NRUA/XBRL generation boundary

Holidario no longer shows the Generate NRUA XBRL batch action, queue, or operation panel. Generation, invalidation, submission, retry, reset, deletion, and background processing are hardcoded off as legacy functionality.

The remaining implementation and this boundary are retained for historical accountability. They are not an approved self-service journey and must not be re-enabled without a reviewed code change, a fresh privacy/compliance assessment, and a separately approved release.

Holidario also does not prepare these filings as an assisted service in place of the retired action. If your organization must file an NRUA deposit or report, do so through its current external procedure. This article explains what each state of the retired flow meant so that earlier evidence is not misread.

What the organization must decide#

The filing obligation and its scope are decided outside Holidario. For the external procedure, the responsible person must confirm with their professional or administrative source:

• which operations must be included;
• which period applies;
• which activity and reservations belong in the report;
• who is authorized to present it;
• what evidence the organization will retain.

Holidario does not determine a filing obligation or replace professional or legal advice.

Data and states that determine the result#

This section documents only the retired code's behaviour; Holidario no longer runs these checks or shows the action, widget, or NRA/CRU fields.

Batch generation and later submission processing did not perform the same checks. The complete journey depended on:

1. an active short-term rental operation that belongs to the team and is authorized for the person;
2. a stored NRA and the correct CRU/IDUFIR: a disabled, non-STR, or incomplete operation could be skipped by the batch;
3. a completed report year; the retired action defaulted to the previous year;
4. sufficiently complete relationships and activity data to build the report;
5. an NRA with Valid validation status before processing toward Sede Registradores could continue;
6. prepared credentials for the later filing stages;
7. a period compatible with the configured processing rule.

That action's queued notice proved only that a batch was created. It did not confirm that every operation contributed data or that a file was generated. Some queued views of the retired widget also grouped Provisional NRAs with valid ones. Appearing there did not prove the processor could advance: the submission step required Valid status.

Timing rule of the retired flow#

Automatic annual-deposit processing was limited to February for the previous report year. It was a Holidario operating rule, not a statement of regulation.

Outside that window, a report could exist without appearing under Queued or progressing. The absence of a record from a screenshot or note of the queue therefore does not prove that the report did not exist.

Information worth keeping#

If you need to support or reconstruct an earlier filing in the external procedure, gather the following without attaching credentials:

• team;
• operation and property;
• report year;
• the NRA, state, and validation date on record;
• confirmed CRU/IDUFIR;
• person who approved the scope;
• record or presentation identifier, if any;
• proof or status obtained directly from Sede Registradores.

Do not include passwords, keys, certificate copies, full traveller details, or downloaded notification files in a normal ticket.

Distinct evidence that must not be confused#

In records created before the retirement:

• XBRL available: the file was generated.
• Generated: a prepared record existed, but no confirmed presentation.
• Presentation created: an intermediate stage completed.
• Files signed: another intermediate stage completed.
• Submitted: the system recorded sending.
• Accepted: a later result was marked accepted.

Downloading the XBRL is not proof of filing. A presentation identifier also does not replace the registry's own documents and status.

If a filing already exists#

Holidario no longer lets you regenerate, retry, reset, or delete filings. Before filing again through the external procedure, compare the operation, CRU, year, and state of the existing record and keep its identifier.

The retired Regenerate NRUA XBRL (Subsanar) action could remove the existing file and return the record to draft before creating another batch. A draft state after that action does not prove that a new filing was made.

To interpret the state of an earlier record, see Interpret historical NRUA/XBRL status.

Current boundary#

NRUA/XBRL generation and filing are not part of the product. Offering them again would require a reviewed code change, a fresh privacy/compliance assessment, and a separately approved release; to become self-service they would also need specific authority, scope and period preview, confirmation, per-operation results, understandable reuse or duplicate detection, and verifiable recovery. Documentation does not turn a read permission or a historical record into authorization or success.