Important Points on FBDI for Initial On-Hand Load in Oracle Fusion Inventory

  

Key Considerations for Using FBDI in Initial On-Hand Load – Oracle Fusion Inventory

When an organization implements Oracle Fusion Cloud Inventory for the first time, one of the key tasks is to bring in the legacy stock balances into Fusion. This is done through the Initial On-Hand Load process, which establishes the opening balances of items across inventory organizations, subinventories, and locators.

The purpose of this blog post is to highlight and document the key considerations when using the File-Based Data Import (FBDI) template for Initial On-Hand Load in Oracle Fusion Inventory. Getting it right ensures that the system reflects accurate inventory positions, supports smooth transaction processing, and provides a reliable baseline for costing and valuation.

This post brings together the practical points, common pitfalls, and best practices that every consultant, implementer, or business user should be aware of before executing the on-hand load. By following these guidelines, you can minimize errors, streamline the migration process, and achieve a clean and validated inventory cutover into Oracle Fusion.

1.      Purpose of Initial On-Hand Load

• To migrate existing stock quantities from legacy/previous ERP systems into Oracle Fusion.
• Provides a baseline inventory position for go-live.
• Serves as the starting point for all subsequent transactions (receipts, issues, transfers, work orders, etc.).
• Ensures inventory valuation and costing can begin correctly from day one.

2.      Standard Practice: On-Hand Load via FBDI

The most widely used method is File-Based Data Import (FBDI). Oracle Fusion Inventory Management supports FBDI for Miscellaneous Receipt transactions, providing an efficient way to upload large volumes of data. With its structured and repeatable framework, FBDI is ideal for businesses managing high transaction volumes or undergoing frequent data migrations, helping ensure accuracy, speed, and control in inventory operations.

• Template: InventoryTransactionImportTemplate.xlsm
• Import Process:
1. Populate the template with item balances.
2. Generate the CSV, zip it, and upload to UCM.
3. Run scheduled process Load Interface File for Import.

Import process = Create Inventory Transactions

Data File: Select the CSV File uploaded in the UCM folder

4. Run Manage Inventory Transactions to move data into Fusion base tables.
5. Verify quantities using Manage On-Hand Quantities UI.

3.      Prerequisites

• Items must be defined and assigned to respective inventory organizations before on-hand load.
• Subinventories and locators must be created and active.
• UOM and conversions (if required) must be set up.
• Cost profiles, valuation structures, and costing setups should be ready if Costing is enabled.

4.      Key Mandatory Fields/Columns in FBDI Template

• *ORGANIZATION_NAME → Inventory Organization Name in which the on-hand quantities are to be loaded
• Make sure to enter the exact name of the organization as per the setup.
• *PROCESS_FLAG → 1
• This flag indicates whether transaction is ready to be processed by the Transaction Manager or Worker.
• Keep it 1 for all the records to be loaded in the FBDI file for on-hand quantities.
• *TRANSACTION_MODE → 3
• This flag indicates whether the transaction is to be processed in immediate (1), concurrent processing mode (2) or background processing mode (3).
• Best practice is to keep it 3 for using the background processing mode to process the bulk records without impacting the system performance.
• LOCK_FLAG → 2
• This flag indicates whether the transaction is locked by the Transaction Manager or Workers ('1' for locked, '2' or NULL for not locked).
• This prevents two different Workers from processing the same transaction.
• You should always keep it 2 indicating that the transaction is not locked and is ready to be processed by the Transaction Manager or Worker.
• ITEM_NUMBER → Item for which the on-hand quantities are to be loaded.
• This refers to the Item Number from Oracle Fusion system.
• The Items must be created and assigned to the organization beforehand.
• If there is a requirement to capture the item numbers from the legacy system for future reference purposes, then a cross
• SUBINVENTORY_CODE → The Subinventory Name in which the on-hand quantities are to be loaded.
• Subinventory must be created before using it in the FBDI template.
• LOCATOR (if applicable)
• This is required if the subinventory is locator controlled.
• Enter the Locator Code in the appropriate segment e.g., LOC_SEGMENT4 if you are using only Aisle for tracking the locators.

• *SOURCE_CODE
• This indicates a transaction source identifier.
• It is used for auditing and process control purpose hence it is prudent to use some meaningful name here as this is a Free Text entry with limitations of 30 varchar.
• The codes like PRODCONVERSION, UATCONVERSION, CRPCONVERSION, PRODCONVERSIONPHASE1, PRODCONVERSIONPHASE2 etc. can be used in the FBDI file.
• *SOURCE_HEADER_ID
• You can have a common source header ID in the FBDI file.
• This will be populated as Transaction Header ID.
• The Transaction Header ID can be used to execute the Create Inventory Transactions process.
• *USE_CURRENT_COST → This flag indicates whether the current item cost will be used for the transaction or cost will be entered by item cost component.
• Y - signifies current cost will be used.
• N - signifies cost will be entered by item cost component.
• If the value for USE_CURRENT_COST is set as 'N' then it is mandatory to pass a value for 'TRANSACTION_COST_IDENTIFIER'.
• This cost identifier will be the same value that is used in the 'CST_I_INCOMING_TXN_COSTS' tab in the import template, and it will have the cost mentioned with the COST_COMPONENT_CODE.
• TRANSACTION_TYPE_NAME → Miscellaneous Receipt
• This indicates the Transaction Type Name.
• The values are based on Transaction Type Name in INV_TRANSACTION_TYPES_TL.
• The best practice is to use the standard transaction type as Miscellaneous Receipt for loading the on-hand quantities.
• This is case sensitive, so it is critical to ensure that the transaction name is correctly entered.
• *TRANSACTION_QUANTITY → The On-hand quantity to be loaded in the respective combination
• TRANSACTION_UOM → UOM in which stock is maintained.
• Populate TRANSACTION_UOM field with correct value.
• Please note that TRANSACTION_UOM field is the UOM code in which the on-hand is available.
• This field is meant for internal UOM_CODE, however  TRANSACTION_UNIT_OF_MEASURE field is meant for UOM display name.
• TRANSACTION_DATE
• This indicates the actual Transaction date as per the legacy system.
• There is no timestamp used.
• Date must be entered in YYYY-MM-DD format.
• The transaction date validation happens with reference to number of days mentioned in the below profile.
• ORA_INV_TRANSACTION_CREATION_DATE_VALIDATION

• This validation will work only if the profile INV_TRANSACTION_DATE is setup No validation (Profile Level = Site).

• The Transaction Date on the INV_TRANSACTIONS_INTERFACE has to be in correct format. Whatever date is provided in the spread sheet please remember to search the transaction in UI with the same date.

• The Search Completed Transaction UI always defaults to the current date. So, if correct Transaction Date is not provided, the system won't show the transaction.

·       For Lot or Serial Controlled item INV_TRANSACTION_LOTS_INTERFACE and INV_SERIAL_NUMBERS_INTERFACE tabs must be populated with the correct data.

·       On the FBDI spreadsheet when populating inventory data with lots or serials, there should be logical links among all the tabs.

o   e.g., If the Transaction data the Transaction Quantity is specified as 20, there should be a total of 20 Serial numbers.

o   If on the serial number tab, the FM_SERIAL_NUMBER is "A001" either "A020" has to be provided on TO_SERIAL_NUMBER field or 20 lines have to be entered with value in FM_SERIAL_NUMBER field.

 

5.      Special Scenarios to Consider

·       Lot-controlled items → mandatory lot number.

·       Original Lot Expiration Dates and Actual Aging.

·       Serial-controlled items → serial list required.

·       Project-driven supply chain → project/task mandatory.

 

6.      Post-Load Validation

• Use Manage On-Hand Quantities screen in Inventory to confirm the quantities loaded.
• Cross-check with legacy stock reports.
• Run Inventory Valuation Reports if costing is active.
• Perform a sample transaction (e.g., issue/receipt) to validate downstream accounting.

 

7.      Key Takeaways:

·       Initial On-Hand Load is a one-time, business-critical activity during Oracle Fusion Inventory go-live.

·       Using FBDI with appropriate transaction type, organizations bring in clean, validated stock balances into Fusion without impacting GL.

·       Strong pre-checks, proper mapping of lot/serial/project attributes, and reconciliation are key to a smooth cutover.

·       Perform a trial run with a limited set of items before full load.

·       Break files into manageable sizes (e.g., <50k records per file).

·       Ensure data cleansing in legacy system (no negative or duplicate balances).

·       Use unique transaction references for traceability, easy identification & troubleshooting.

·       Validate quantities with legacy data before posting.

·       Reconcile on-hand quantities with legacy reports after import.

·       Plan for cut-off timing (stop legacy transactions before load to avoid mismatch).

·       Do not use FBDI approach for regular transactions after go-live — use normal Fusion transactions instead.

 

Document Creation Method in Oracle Fusion Purchase Orders

 Document Creation Method in Oracle Fusion Purchase Orders

In Oracle Fusion, the Document Creation Method field in the Purchase Order (PO) header specifies how the purchase order was created in the system. This attribute provides visibility into the origin of the PO and helps in tracking, reporting, and auditing procurement activities.

Typical Values:

The Document Creation Method may display different values depending upon the way PO was created in the system –

DOCUMENT_CREATION_METHOD	PO Creation Option Used	Description
AUTOCREATE	Process Requisitions	The PO is created through ‘Process Requisitions’ UI using the approved requisitions
AWARD_SOURCING	Complete Sourcing Award	Create a purchasing document when awarding a negotiation.
COPY_DOCUMENT	Duplicate Purchase Order	The PO is created using a Duplicate option from the existing PO
CREATEDOC	Generate Orders	The PO is created by a program that will create purchase orders for those requisition lines requesting products or services setup for automated buying.
ENTER_PO	Create Purchase Order	The PO is crated manually from scratch using the Create Order UI.
PDOI	Import Purchase Order	Purchase orders are imported from external systems.
PO_REST_SERVICE	Purchase Order REST Service	A REST service is used to create purchase orders from external systems.
PO_WEB_SERVICE	Purchasing Web Service	A Web service is used to create purchase orders from external systems.
PROCESS_REQS_REST	Process Requisitions REST Service	A REST Service for Processing Requisitions to place an order with identified supplier.

 

These values are defined in the - Manage Standard Lookups: PO_DOCUMENT_CREATION_METHOD

 

 

 

 

Why is it Important?

• The Document Creation Method acts as a key audit attribute for buyers and finance teams.
• It helps distinguish between POs that were manually created vs. system generated.
• It is useful for troubleshooting, compliance, and procurement analytics.

Business Use:

• Procurement Teams can analyze how many POs are auto generated versus manually created.
• Audit & Compliance teams can track the origin of purchasing activity.
• Operations can measure efficiency by checking the adoption of automation (e.g., auto-generated vs. manual).

 

Few Notable Scenarios:

Although the document creation method of AUTOCREATE indicates that the PO was originally autocreated from a Requisition, there would be a few scenarios where despite the PO's document_creation_method = AUTOCREATE, the links between the Requisition and PO would no longer exist. Here are such scenarios-

Scenario#1 Cancelling the PO line autocreated from Requisition

1.1.    Autocreate PO#1111 from Requisition#111, Line 1.
For PO#1111, po_headers_all.document_creation_method = AUTOCREATE.

1.2.    Add some additional lines to PO#1111. Save and get the PO approved.

1.3.    Now Cancel the PO line that was autocreated from Requisition#111, Line 1 and keep the newly added lines as it is.

In this case, the document creation method on the PO will be 'AUTOCREATE', however no Requisition lines are linked to this PO.
po_distributions_all.req_distribution_id will be null. Also, for Requisition#111, Line 1, po_requisition_lines_all.line_location_id will be null.

Scenario#2 Deleting the PO line autocreated from Requisition

2.1.    Autocreate PO#2222 from Requisition#222, Line 1.

For PO#2222, po_headers_all.document_creation_method = AUTOCREATE.

2.2.    Add some additional lines to PO#2222. Save and get the PO approved.

2.3.    Now Delete the PO line that was autocreated from Requisition#222, Line 1.

In this case, document creation method on the PO will be 'AUTOCREATE', however no Requisition lines are linked to this PO.
po_distributions_all.req_distribution_id will be null. Also, for Requisition#222, Line 1, po_requisition_lines_all.line_location_id will be null.

 

In summary:
The Document Creation Method in PO headers is more than just metadata — it provides transparency into how purchase orders are generated in Oracle Fusion, enabling better control, auditing, and process improvement.