| Oracle® Retail Fiscal Management User Guide Release 14.1.3.1 E89504-01 |
|
 Previous |
 Next |
ORFM supports the following inventory functionalities:
Transfer is the movement of merchandise from one location to another, either a warehouse or a store. When a transfer is initiated, ORFM creates and issues the related NF (based on the transfer information) for the merchandise to be transferred out. After the merchandise is shipped, the NF that was created, is matched with the related transfers in order to receive the merchandise in the receiving location.
Transfers can be of two types:
Transfers (Regular, Intra-company and Inter-company, single-legged transfers)
Two-legged Transfers (for finishing and repairing)
The NF processing flow of intra-company transfers is identical to intercompany transfers. The process flow for Transfers can be divided into the following subprocesses:
Transfers Creation in RMS
Transfer Shipment at Warehouse
Transfer Receiving at Store
Create the transfer in RMS either manually or automatically through APIs or allocation or replenishment.
|
Note: For information on creating transfers in RMS, see the Oracle Retail Merchandising User Guide. |
For the manually-created transfers, enter a valid utilization code.
The transfer is interfaced with warehouse management system. If the transfer is initiated in warehouse management system as a stock order, it flows to RMS. If the RMS initiated transfer is modified in warehouse management system, the modifications flows back to RMS.
Create an outbound NF in ORFM after the merchandise are shipped in warehouse management system.
The NF is based on the information provided by warehouse management system, which includes the transfer cost, and other master data.
|
Note: For seamless NF processing, transfer information has to be available in the Oracle Retail Merchandising System (RMS) before the transfer is shipped from the shipping location. |
The cost on the outbound NF generated is configurable based on the system option TSF_PURCHASE_PRICE. If this is set as Y, the last purchase price is the cost on the NF, else WAC if set as N.
|
Note: The above configuration is valid for intra company transfers only. |
Validate this NF. This NF is sent to Tax Engine to retrieve the CFOP, and for each line item and tax breakup details.
After the CFOP and tax breakup details are retrieved, approve the NF.
If the Auto-Approve indicator is enabled for the Utilization Code, the NF validation and approval is automatic.
As the outbound NF is approved, an inbound NF is created in the background in Validated status.
Print the NF and send it along with the shipment. The inventory in RMS has to be updated after the outbound NF is generated and approved.
After the shipment reaches the destination, retrieve the inbound NF that is available in ORFM.
|
Note: Because the inbound NF is created using the outbound NF, validation exclusively for data integrity is not required. The tax breakup and CFOP information for the inbound NF is available as it is generated. The NF is created in Validated status. |
Since the NF is in Validated status, submit the NF for receiving.
The NF receiving process is similar to the NF Processing for receiving except that there is no discrepancy and resolution process for transfers.
Create the transfer, and set the utilization code for transfers in RMS. After the merchandise is shipped in warehouse management system, create the NF in Exit mode for the warehouse.
For Store to Store Transfers/Store to Warehouse Transfers/Warehouse to Store Transfers/Warehouse to Warehouse Transfers, the outbound NF is automatically generated on shipment. Here the NF status would be worksheet or approved depending on Auto Approve Indicator value set at utilization level. After NF approval, ORFM sends shipment details along with calculated cost to RMS. RMS updates inventory and post transaction data for stock ledger updates and financial postings. The Inbound NF is auto created in Validated status. To process shipment receipt, you need to manually trigger publishing of NF Schedule/ASN to receiving location through Submit NF for Receiving option on NF screen.
|
Note: For information about adding utilization codes for transfers, see the Oracle RMS/ReSA Brazil Localization User Guide. |
To create the NF in the warehouse, do the following:
Navigate: From the RMS Start Menu, select Fiscal Management, then Login of Location. The Location Login window appears.
In the Location Login window, select the store/warehouse that is transferring the merchandise from the location list. Click OK. You are returned to the main menu.
From the RMS Start Menu, select Fiscal Management, then Receiving/Issue. In Contents Of Receiving/Issue window, click Edit. The Receiving/Issue Schedule window appears.
Select the schedule that is created in worksheet status. The Mode is Exit.
ORFM creates an outbound NF based on the information that flows from warehouse management system.
Click Fiscal in the Receiving/Issue Schedule window. The Fiscal Docs Find window appears.
In the Fiscal Docs Find window, click Add. The Fiscal Document window appears.
In the Fiscal Document window, the differences in values of the fields are as follows:
In the Fiscal Documents window, from the Options menu, select Validate. The CFOP and tax breakup is retrieved from Tax Engine.
The Header Taxes details are as shown below:
The Details tab of the Fiscal Documents window displays the line item detail taxes.
If the Auto-Approve indicator is enabled for the Utilization Code, the validation process needs no manual intervention.
Print the approved outbound NF, and send it along with the shipment. The on-hand inventory is reduced at the source warehouse.
As the outbound NF is approved, an inbound NF is created in the background in Validated status with a new NF number.
At the receiving store, select the location from the location list in the Location Login window.
Validated inbound NF is generated based on the approved outbound NF for the transfer.
In the Receiving/Issue Schedule window, select the schedule with the inbound NF. The schedule is in Pending for Receiving status.
In the Receiving/Issue Schedule window, click Submit. The receiving process is similar to that of PO Receiving, except that there is no discrepancy identification and resolution process available for transfers.
As the merchandise is received, the status of NF changes to Approved.
The business flow for two-legged transfer can be divided into three sub-processes as follows:
Transfer Creation
For two-legged transfers, create the transfer in RMS. If the transfer type is repair, the context type is Repairing. After the transfer is approved, RMS creates the second leg of the transfer as a separate transfer.
RMS publishes the first transfer to warehouse management system or store inventory management system.
If the context type is Repair, warehouse management system takes in the message and creates a stock order, where type = Repair.
|
Note: Stock orders where type = Repair are not selected in Wave. Repair stock orders are handled separately. |
In order to repair the merchandise, initiate a transfer in either WMS or RMS. If the transfer is used for stocking or finishing the merchandise, you must initiate the transfer in RMS only.
Two-Legged Transfer Shipment
After the merchandise is sent from either the warehouse management system or the store inventory management system, the shipment information is published. ORFM uses this shipment information. A NF is generated in Exit mode.
The transfer cost on the exit NF is equal to the weighted average cost (WAC). The taxes and CFOP are retrieved from Tax Engine.
After the approved NF is printed, the shipment is ready to move out of the location. The inventory in RMS is updated as the outbound NF is approved.
If the auto-receiver indicator is enabled at the finisher location, the in-transit quantities at the finisher location are automatically cleared. If the indicator is not enabled, RMS receives the receipt details.
It is assumed that the shipment quantity has been received at the finisher.
Two-Legged Transfer Receiving
When the finished/repaired merchandise is to be returned to the supplier, a valid NF has to be generated.
Enter the NF in the system that is generated by the repairer/finisher. This is inbound flow.
Validate the NF for data integrity, and send it to Tax Engine for inbound CFOP determination. Tax Engine does not return the taxes, as there is no discrepancy identification done for this transaction.
Submit the schedule containing this NF to store inventory management system or warehouse management system.
After physical receipt, ORFM uses the receipt message to process the NF. The application processes the NF as any other entry NF.
For processing of two-legged transfers in ORFM, you have to create the transfer in RMS with the context type as Repairing. The warehouse management system has to publish the shipment information before the NF processing for two-legged transfer is initiated in ORFM. ORFM generates a outbound NF in Approved status, based on the shipment information provided by warehouse management system.
For Two legged transfers with finisher, Outbound NF is automatically generated on shipment. Inbound NF needs to be manually generated. While capturing Inbound NF details in ORFM, you need to identify 'from' location as finisher.
To process NF for the two-legged transfer shipment, do the following:
Navigate: From the RMS Start Menu, select Fiscal Management, then Login of Location. The Location Login window appears.
In the Location Login window, select the store or warehouse that has to receive the shipment for repairing/finishing. Click the Location LOV to obtain the list of stores or warehouses. Select the location, and click OK.
In Contents of Fiscal Management, click Receiving/Issue. In Contents of Receiving/Issue, click Edit. The Receiving/Issue Schedule window appears. On the Receiving/Issue Schedule window, click the outbound NF generated by ORFM.
Click Fiscal. The Fiscal Docs Find window appears.
Click OK. The Fiscal Documents window appears.
In the Fiscal Document section, the Requisition Type is displayed as Repairing, and the Utilization field displays the values set in the RMS Transfer Maintenance screen.
If the Auto Approve parameter is set to 'Y', the NF is automatically approved. Otherwise, the NF has to be manually approved.
The inventory in RMS is updated, after the NF is approved.
In the Location Login window, select the location that receives the merchandise after the repairing/finishing work is done.
To receive the repaired/finished merchandise, create the schedule in worksheet status. Click Add in the Receiving/Issue Schedule window. The NF is created in Entry mode.
Select the schedule and click Fiscal in the Receiving/Issue Schedule window. The Fiscal Docs Find window appears.
Click Add. The Fiscal Documents window appears. Select Repairing from the Requisition Type LOV for this NF. Select the Utilization from the list. Set the Sub Type to External Finisher.
From the Options menu, select Validate. If there are no errors, the NF status changes to Validated.
Click OK. You are returned to the Receiving/Issue Schedule window. In the Receiving/Issue Schedule window, from the Options menu, select Sub. for Recv. The NF is submitted for receiving.
If there are no errors, from the Options menu, select Approve. The NF is approved, and the merchandise that has been repaired/finished can be received.
|
Note: Based on the NF-e line limit set and the item having the grouping attribute flagged or not (ST break out), the shipment is broken into multiple NFs in ORFM. |
The Fiscal Documents window has been adjusted for the receiving of Complementary NF for the Requisition Types TSF (Transfer) and IC (Intercompany Transfers).
Therefore you can select entry utilizations for the Transition Types TSF (Transfer) and IC (Intercompany Transfers) while entering a CNF.
The Complement button in opens the Complement Fiscal Doc window to associate the Complementary NF with the Main NF.
|
Note: The Main NF associated with the Complementary NF must be in status Approved for TSF (Transfers) and IC (Intercompany Transfers). |
The following fiscal utilization setups have been created to distinguish Transfer Returns from conventional Transfers:
Transfer Return Outbound
Setup:
Requisition Type is Transfer.
Issue type is Issue.
Mode type is Exit, since it is an exit transaction.
The Nature of Operations is associated with the NOP used to identify the transaction as Transfer Return.
Transfer Return Inbound
Setup:
Requisition Type is Transfer.
Issue type is Include.
Mode type is Entry, since it is an entry transaction.
The Nature of Operations is associated with the NOP used to identify the transaction as Transfer Return.
TSF (Transfer) Return Inter Outbound, for Exit Return Transfer Inter-company
Setup:
Requisition Type is Inter Company (IC).
Issue type is Issue.
Mode type is Exit, since it is an exit transaction.
The Nature of Operations is associated with the NOP used to identify the transaction as Transfer Return Inter-company.
TSF (Transfer) Return Inter Inbound, for Entry Return Transfer Inter-company
Setup:
Requisition Type is Inter Company (IC).
Issue type is Include.
Mode type is Entry, since it is an entry transaction.
The Nature of Operations is associated with the NOP used to identify the transaction as Transfer Return Inter-company.
Inventory adjustments allows total stock-on-hand (SOH) adjustments or unavailable (un-sellable) inventory for one or more item/locations.
In Brazil:
Stock outs may have taxes associated and requires the generation of a NF to properly account for them.
NFs can be generated based on inventory adjustments with proper setup through the link of a reason code in the Utilization configuration screen. The reason code must be the same code used in the inventory adjustment coming from inventory management system.
NFs generated based on a negative inventory adjustment are restricted to stock out transactions. For this type of transaction, the NF is issued in 'Exit' mode with source and destination being the same location that created the inventory adjustment.
Retailers can use inventory adjustment functionality associated to NF generation in order to support different fiscal processes such as 'donation' where the NF must be generated similarly to a stock out, but the destination is a third party entity, not the same as the source location. In this scenario the setup of the Utilization and Reason code is different and the NF is generated using the Standalone NF mode. This type of transaction supports negative and positive inventory adjustments.
Negative Stock Out Inventory Adjustments
The Utilization options are as follows:
Requisition type "Stock Out"
Issue "Issue"
Nature of Operation (must be configured accordingly to Tax Engine)
Mode "Exit"
Select Reason Code under Options menu.
The Reason code to be used must have same value of the inventory adjustment reason code set in WMS or SIM.
|
Note: The other options in Options menu (Parameters and Doc Type) must be configured accordingly. For more information, see the Utilization setup section. |
The store inventory management system, or the warehouse management system publishes the details of the negative inventory adjustment with the reason code previously configured in ORFM.
ORFM consumes the inventory adjustment and based on the utilization setup, creates an Exit NF.
If the auto-approve parameter of the utilization code is set to 'Yes', validation, and approval of the NF happens automatically. If the auto-approve parameter of the utilization code is set to 'No', validate and approve the NF manually.
After the NF has been approved, the inventory is updated in RMS.
|
Note: Based on the stock out Utilization setup, only negative inventory adjustments will generate a NF. Positive inventory adjustments are not supported in this type of setup. |
The configuration necessary in order to generate a standalone NF based on an inventory adjustment are as follows:
The Utilization options are as follows:
Requisition type "Direct NF"
Issue "Issue"
Nature of Operation (must be configured accordingly to Tax Engine)
Mode "Exit"
Select Reason Code under Options menu.
|
Note: The option Doc Type in Options menu must be configured accordingly. |
The Parameters option in Options menu must only have the following options enabled for this type of setup:
ICMS-ST Recovery
Item Utilization
All other options must be disabled.
|
Note: If an ORFM user selects the option "ICMS-ST Recovery", the system cannot allow the deletion of the reason code associated. |
The store inventory management system, or the warehouse management system publishes the details of the negative or positive inventory adjustment with the reason code previously configured in ORFM.
ORFM consumes the inventory adjustment and based on the utilization setup, creates a Standalone NF.
You need to access the NF form and complete the source or destination entity data in order to validate and approve the NF. In this scenario there is no auto-approve option.
After the NF has been approved, the inventory is updated in RMS.
O RFM will automatically create an exit Standalone NF considering the utilization associated to the inventory adjustment reason code.
ORFM user will be able to choose whatever third party as the 'addressee' of this Standalone NF.
The fields in the tab Destination Details are automatically filled with the location data that is creating the Entry NF and to which the goods will be received.
The tab Source Detail will be left for user to complete and will represent the origin of the transaction.
Brazilian retailers dealing in hard lines (electronics and furniture) or selling through e-commerce channel often take customer orders and ship merchandise directly to customers. For every customer order delivery of merchandise, they issue a Customer Nota Fiscal document to accompany the delivery.
Customer Orders are generated in external Customer Order Management (COM) system. Customer Orders are based on special orders created at a physical (brick and mortar channel) store or a virtual (e-commerce channel) store. Virtual e-commerce channel stores may be defined by client as per their business requirements. For example, they may be defined based on FedEx, United Parcel Service (UPS) delivery methods.
External COM system custom interfaces customer order details to RMS for further processing. In response to this request, RMS generates a Customer Order Transfer between warehouse and virtual store. RMS publishes this customer order transfer to the warehouse management system for picking and shipping of inventory for customer delivery. The warehouse management system communicates shipment details by publishing an ASN Out to ORFM/RMS. ORFM consumes this ASN Out and auto-generates a Customer Delivery NF of sales requisition type to accompany the shipment. This NF may be printed and included in the delivery. Processing of Customer Order Shipment is similar to transfer shipment. Primary difference is that only exit NF is generated in case of Customer NF, whereas both exit and entry NFs are generated for transfer shipments.
ASN Out is custom interfaced to External COM system and the External COM further interfaces customer order fulfillment sale transaction details to Oracle Retail Sales Audit (ReSA) for special order fulfillment sale posting.
|
Note: Customer Delivery NF is generated in Validated status and requires manual intervention for approval, if Auto Approve Indicator for its utilization is N (No). Customer Delivery NF is validated and generated in Approved status, if Auto Approve indicator is Y (Yes). |
A Future Delivery is the requirement where a customer places an order and receives the NF (Sale/Invoice), but the product is delivered on a future date. Therefore it is necessary to issue a second NF (Shipment). One or multiple shipments can be related to same Sale/Invoice NF. The Delivery covers the total of goods, just one NF for the Shipment will be issued.
The Future Delivery transaction can be a choice by the customer (end consumer) for convenience, or by the retailer mainly when there is not enough stock on hand but is expected to be on hand sometime in the future.
The following enhancements have been made in ORFM to handle Customer Order - Future Deliveries:
The Customer Order is captured by the OOC and then sent to OMS. OMS requests the Sale/Invoice NF from RFM, indicating that it is a Future Delivery CO, which is created with no association to a shipment. Only one NF can be issued for each Customer Order Future Delivery Sale.
Specific utilizations for each NF (Invoice and Shipment) are created to identify this transaction for tax calls purposes.
Later on, OMS submits a Customer Order fulfillment to a physical location (SIM or WMS), that results in a delivery NF requested to RFM. This request states that it is only a regular Sale.
