Skip to content

← Home

Oracle Cloud: Working Around the nItemPed Limit in Internal Transfers

#Oracle Cloud#Brazil Localization#FDG#FDC#NF-e#Collaboration Messaging
September 30, 2026
Se tem preguiça de ler, clique aqui pro TL;DR

The complexity of the Brazilian fiscal and tax system is nothing new and creates important challenges for ERPs, which need to continuously adapt to local requirements and particularities.

Within this context, I want to share a technical scenario that can arise in Oracle Cloud internal-transfer implementations.

In a transfer between units, such as between a head office and its branches, issuing an NF-e to accompany the material during transportation may be mandatory.

Fiscal Document Generation (FDG) generates the fiscal document and allows the creation of an extract file containing the information required for a fiscal partner to format the fiscal document XML and communicate with the tax authority. Oracle — Fiscal Document Extract

After authorization, the structured XML can return to the destination organization, be transformed by Collaboration Messaging, and be captured by Fiscal Document Capture (FDC). Oracle — Internal Transfer of Fiscal Documents

Summary flow:

Transfer Order > Shipment > FDG > Fiscal Partner > SEFAZ > NF-e XML > Collaboration Messaging > FDC > Receipt

The issue

For FDC to correctly relate the received document to the transfer, we need to identify the shipment and its corresponding line.

In the NF-e XML, one possible approach is:

<xPed>Shipment Number</xPed>
<nItemPed>Shipment Line Identifier</nItemPed>

The limitation is in the NF-e layout required by SEFAZ: nItemPed accepts a maximum of 6 digits, while xPed accepts from 1 to 15 characters. NF-e — MOC 7.0, NF-e/NFC-e Layout

When the Oracle line identifier exceeds 6 digits, the fiscal partner cannot send the complete value in nItemPed and must truncate or adjust it before transmission to SEFAZ.

This is the critical point: truncating the identifier removes the original line value and can create collisions between different identifiers, making it harder for FDC to correlate the document correctly.

The alternative

The alternative was to use infAdProd to carry the complete line identifier. The field supports up to 500 characters in the NF-e layout. NF-e — MOC 7.0, infAdProd

The design becomes:

Shipment Number > xPed
Line Identifier > infAdProd

To carry the complete identifier, we use the infAdProd tag in the XML.

For TRANSFER ORDER SHIPMENT shipments, we use an FDG rule in which the value intended for infAdProd is retrieved from the ZX_LINES_DET_FACTORS table:

CASE
    WHEN H.EVENT_CLASS_CODE = 'TRANSFER ORDER SHIPMENT'
    THEN TO_CHAR(
           (
             SELECT NVL(LINK_TO_TRX_LINE_ID, TRX_LINE_ID)
               FROM ZX_LINES_DET_FACTORS
              WHERE TRX_ID           = L.TRX_ID
                AND TRX_LINE_ID      = L.TRX_LINE_ID
                AND APPLICATION_ID   = L.APPLICATION_ID
                AND ENTITY_CODE      = L.ENTITY_CODE
                AND EVENT_CLASS_CODE = L.EVENT_CLASS_CODE
           )
         )
    ELSE L1E_1.LEGAL_MESSAGE_TEXT
END AS LEGAL_MESSAGE_TEXT

With this approach, the line ID travels in the XML through the infAdProd tag, preserving the complete identifier.

Collaboration Messaging adjustment

When the authorized XML returns to Oracle, Collaboration Messaging transforms the message before FDC processing.

The Oracle Cloud path is:

Tools > Collaboration Messaging > Manage Collaboration Message Definitions

The definition used for the inbound NF-e points to an XSL responsible for the mapping. Collaboration Messaging documentation confirms that the message definition references the XSL file used for the transformation. Oracle — Collaboration Message Definitions

The standard behavior is:

<n9:SourceDocumentLine>
    <xsl:value-of select="ns3:prod/ns3:nItemPed"/>
</n9:SourceDocumentLine>

For our solution, we added logic to the XSL so that it stops retrieving the ID from nItemPed and starts retrieving it from infAdProd:

<n9:SourceDocumentLine>
    <xsl:choose>
        <xsl:when test="
            (ns3:prod/ns3:CFOP = 6151 or
             ns3:prod/ns3:CFOP = 5151 or
             ns3:prod/ns3:CFOP = 6557 or
             ns3:prod/ns3:CFOP = 5557)
             and normalize-space(ns3:infAdProd) != ''">

            <xsl:value-of select="ns3:infAdProd"/>

        </xsl:when>

        <xsl:otherwise>
            <xsl:value-of select="ns3:prod/ns3:nItemPed"/>
        </xsl:otherwise>
    </xsl:choose>
</n9:SourceDocumentLine>

The idea is simple:

NF-e XML > infAdProd > Collaboration Messaging XSL > SourceDocumentLine > FDC

Only the selected CFOPs use infAdProd. For all other documents, the standard nItemPed behavior remains unchanged.

Result

With this design, the complete line identifier can travel through the NF-e outbound and inbound process without depending on the 6-digit limitation of nItemPed.

The technical flow is:

Shipment > FDG > Fiscal Partner > infAdProd > SEFAZ > XML > Collaboration Messaging > SourceDocumentLine > FDC > Receipt

It is important to remember that infAdProd is a fiscal field in the NF-e. Therefore, this type of use should be validated with the fiscal team and with the partner responsible for the integration.

It is also recommended to avoid direct changes to seeded Collaboration Messaging definitions and to keep the customization separate whenever possible.

Public references