SPED-NFE

The sped-nfe library covers a wide range of fiscal document operations, including:

• XML Generation: Via Convert::class (from TXT) or Make::class (direct assembly).
• Contingency: Managing SVC, EPEC, FS-DA, and OFF-LINE modes via Contingency::class.
• Webservice Interaction: Communicating with SEFAZ servers.
• Data Handling: Reading and converting XML data into other formats.
• Document Management: Storage and sending of fiscal documents.
• DANFE Printing: Supported via external libraries sped-da and posprint.
• Emailing: Sending documents to recipients via sped-mail.
• Tax Data: Obtaining tax information via sped-ibpt.
• GNRE Generation: Generating tax collection guides via sped-gnre.

The SEBRAE NFe v4.00 layout is a TXT-based structure used by the SEBRAE issuer. This layout is based on Technical Notes 2016.002 (versions v1.10 through v1.60).

Important Constraints:

• Erratic Fields: Some fields do not follow a consistent pattern and may not be covered by the API parser in all conditions.
• Parser Requirement: While the SEBRAE issuer may omit the pipe separator (|) at the end of some fields, the sped-nfe parser requires ALL fields to end with a pipe (|).
• Reverse Engineering: This structure was partially obtained via reverse engineering and is subject to errors as there is no official TXT formation manual.
• Incomplete Conversion: The converter does not yet perform a complete conversion to the SEBRAE standard due to complexity and lack of information.

When performing an EPEC operation, follow this logical flow to ensure compliance and data integrity:

1. Activate Contingency: Use Contingency::activate() to set the state, motive, and type.
2. Configure Tools: Pass the contingency object to $tools->contingency.
3. Transmit: Call $tools->sefazEPEC($xml).
4. Validate Response:
   • The service response cStat must be 128.
   • The event response cStat must be 136.
5. Persist Data:
   • Use Complements::toAuthorize() to create the protocol XML.
   • Crucial: Save the XML returned/modified by the process, as the chNFe (access key) may have changed.
6. Finalize: Once SEFAZ is back to normal, transmit the document using the standard (non-contingency) method.

At the federal level, it is mandatory for the recipient to register one of the following events: Confirmação da Operação (Confirmation of Operation), Operação não Realizada (Operation Not Performed), or Desconhecimento da Operação (Unknown Operation) for NF-e transactions that meet these criteria:

1. Fuel Transactions: Circulation of goods destined for fuel distributors (since 2013) or fuel stations/retailers (since 2013).
2. Bulk Alcohol: Operations involving alcohol for non-fuel purposes transported in bulk (since 2014).
3. Wholesale/Distribution of Specific Goods: If the recipient is a distributor or wholesaler, transactions involving cigarettes, alcoholic beverages (including beer/draft beer), soft drinks, and mineral water (since 2015).

The CFOP (Código Fiscal de Operações e de Prestações) is a mandatory code required for every item in electronic invoices (NFe/NFCe), declarations, guides, and book-keeping.

It serves three primary purposes:

1. Taxation: Defines whether the invoice incurs taxes.
2. Inventory: Dictates how the movement affects stock.
3. Financial: Influences financial movements.

When selecting a CFOP, you must consider two main criteria:

• Type of Operation: Whether it is an entry (entrada) or an exit (saída).
• Region: The geographic location of the transaction (e.g., within the same state or from another state).

CFOP is closely related to the product classification and its type within the SPED system.

For legacy systems that struggle with XML, you can generate an intermediate TXT file where fields are separated by pipes (|). The library provides the Convert::class to transform these pipe-delimited TXT files into valid NFe XML files. This approach uses a structure derived from reverse-engineering the SEFAZ free issuer to ensure compatibility despite omissions in official manuals.

For detailed structure information, refer to EstruturaTxt.md. For implementation details, refer to Convert.md.

The ProcEventoNFe functionality handles the return of protocolled events provided by the DFe (Documentos Fiscais Eletrônicos) distribution system. These XML responses represent events manifested by parties involved in a fiscal operation, such as Customers, Suppliers, Carriers, or Tax Authorities (State or Federal).

Common event types handled in this context include:

• Cancellation Events (Evento de Cancelamento)
• Correction Letter Events (Evento de Carta de Correção)
• Recipient Manifestation Events (Eventos de Manifestação do Destinatário)
• Suframa Events (Vistoria/Internalização)
• Deadline Extension Request Events (Eventos de Pedido de Prorrogação de Prazo)
• Tax Authority Responses to Extension Requests (Eventos do Fisco em Resposta ao Pedido de Prorrogação)

The Recipient Manifestation (Manifestação do Destinatário) events have a general deadline for registration, but specific rules apply depending on federal or state legislation.

• General Rule: Events can generally be registered up to 90 days after the NF-e authorization date.
• Rectifications: Once an event has been registered for an NF-e, any rectifications can only be performed within 30 days of the first manifestation.

Note that specific deadlines and mandatory requirements vary by federal segment, state (UF), document value, or the type of operation (e.g., refusal or cancellation).