Regenerate Brazil NF-e PDF When NetSuite Deletes It but Won't Rebuild

An NF-e shows status Sent with the SEFAZ authorization intact, the signed XML is on file, but the DANFE PDF is gone. The "Generate PDF" button has disappeared from the E-Document record because NetSuite considers the process complete, yet the File Cabinet never received a replacement file. This is the exact failure mode a manual regeneration creates: the prior PDF gets deleted, the new file save fails mid-process, and the record is left without a printable copy.

What Actually Happens During the Failed Regeneration

The Brazil Localization SuiteApp handles the DANFE as a generated artifact, not as a static attachment. When a user clicks the regenerate action, the SuiteApp calls the E-Document process, which deletes the old PDF in the File Cabinet, then attempts to write a new one to the folder configured for the E-Document subsidiary.

The Internal ID gap in the File Cabinet sequence is the most reliable signal that the write attempt hit an exception after the delete succeeded.

The two pieces of evidence confirm the failure path:

• The Audit Trail on the E-Document record shows a file delete with no corresponding file create.
• The File Cabinet shows a skipped Internal ID, indicating NetSuite reserved a record number for the new PDF before the save rolled back.

Once the SuiteApp sees status Sent (the E-Document Status field driven by SEFAZ authorization), the regenerate controls are removed from the UI. The XML is the legally authoritative document in Brazil; the PDF is a rendering for transport, customs, and receiving. The control here is the signed XML, not the file in the cabinet. For general orientation on how E-Document records surface in the standard NetSuite interface, the NetSuite Basics Guide covers the underlying record layout.

First Check: Confirm the XML Is Still Authoritative

Before chasing the PDF, verify the source of truth is intact.

1. Open the E-Document record for the NF-e.
2. Confirm E-Document Status is Sent and the Authorization Protocol and Authorization Date fields are populated.
3. Open the related XML file from the File Cabinet and check that the Protocol of Authorization (nfeProc/protNFe/infProt) matches SEFAZ.
4. Note the Document Number, Series, and Access Key (the 44-digit chave de acesso) for cross-reference.

If these fields are correct, the invoice is legally valid for the recipient. The PDF is a convenience artifact and can be regenerated without re-issuing the NF-e or touching SEFAZ.

Recreating the DANFE Without Re-Issuing the NF-e

The practical path is to generate the PDF from the already-signed XML outside of the SuiteApp's broken flow, then attach it back to the record.

Option 1: Re-render the DANFE from the stored XML

1. Download the signed XML from the E-Document record (the file in the File Cabinet linked under the Documents subtab).
2. Open the XML in a SEFAZ-compliant viewer such as the free SEFAZ Virtual Viewing tool, or any local DANFE renderer that accepts the nfeProc envelope.
3. Generate a fresh PDF.
4. Upload the PDF to the File Cabinet in the same E-Document subsidiary folder where the original lived, and link it to the transaction (Invoice) record under the Documents subtab.

This keeps the XML untouched, preserves the audit trail, and gives the receiving team the printable copy they need for goods receipt.

Option 2: Ask the Localization Partner to Reissue the PDF Record Only

For the LatamReady Brazil Localization SuiteApp, open a support case with the SuiteApp provider (LatamReady) and request a re-render of the DANFE PDF. The provider has access to the E-Document record internals and can regenerate the PDF record against the existing authorized XML without triggering a new SEFAZ submission.

Provide the following so the case moves quickly:

• The E-Document Internal ID
• The Transaction Internal ID of the Invoice
• The Access Key (chave de acesso)
• The Internal ID gap observed in the File Cabinet

The gap number itself narrows the failure for their team. From an audit perspective, this is a clean fix because the underlying XML retains the SEFAZ signature and timestamp.

What Not to Do

Do not try to reset the E-Document Status to draft to unlock the regenerate button. The status is driven by the SEFAZ return; resetting it severs the link to the authorization and forces a brand-new submission with a new access key, which is an actual re-issuance under Brazilian law, not a fix.

Preventing the Recurrence

The regeneration that triggered the delete is the surface symptom. The deeper cause is usually a File Cabinet permission issue on the E-Document subsidiary folder or a custom role missing the E-Document permission. Audit both before the next batch.

Menu paths to verify

• Setup > Users / Roles > Manage Roles, confirm the role has E-Document permission enabled and Full level on the subsidiary.
• Documents > Files > File Cabinet, confirm the E-Document target folder allows the user's role to create files. A folder restricted to a specific role silently fails the write and produces exactly the Internal ID gap you saw.
• Setup > Company > Enable Features, confirm the localization features required by the Brazil SuiteApp are still enabled for the subsidiary.

A role that can view E-Documents but cannot write to the configured File Cabinet folder will produce a clean delete and a silent failed create every time.

Validate the Fix End to End

After the replacement PDF is in place, run a small saved search to confirm no other authorized NF-e is sitting without a linked PDF. The criteria: E-Document Status = Sent, Record Type = Invoice, and File Cabinet attachment count = 0. Export the result and work through any additional orphans the same way: render from XML, attach, and document.

This is one of those failures where the legal document is fine but the operational artifact is missing, so the work is on the file, not the fiscal record. Clean, reconciled, and audit-ready means the XML stays the source of truth, the PDF is rebuilt from it, and the File Cabinet count matches the E-Document status on the saved search. If the next regeneration hits the same Internal ID gap, the answer is in role permissions on the File Cabinet folder, not in the XML or the SEFAZ flow.