| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
 Previous |
 Next |
| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
Previous |
Next |
ORFM is integrated with other Oracle Retail applications including RMS, RWMS, and SIM. Because RMS and ORFM share the same instance and same database schema, ORFM can look up the RMS database tables and vice versa. A purchase order (PO) or transfer created in RMS is directly accessible to ORFM. Supplier, location or item level fiscal attributes that are set in RMS can be accessed by ORFM through direct database look up.
ORFM integrates with SIM and RWMS through RIB (for real-time integration). If Brazil localization is enabled, SIM or RWMS should not be allowed to physically receive any inventory before fiscal receiving (inbound NF Processing) is completed in ORFM. After physical receiving in SIM or RWMS, the inventory in RMS should not be updated until fiscal receipt and physical receipt comparison is done in ORFM and the discrepancy (if any) is resolved as explained above.If Brazil localization is enabled, RMS inventory is not updated immediately when any inventory is shipped out from RWMS or SIM. The inventory movement information should be sent to ORFM for the generation of outbound NF. After approval of the outbound NF, ORFM should send the inventory updates to RMS. For more information, see the Outbound Operations Process Flow diagram in the "Overall Solution Landscape" section.In the subsections below, each transaction with a different integration flow (other than the base application) for Brazil is detailed.
The following topic and sub topics are covered in this chapter:
Purchase orders are created in RMS and communicated to Vendor; Vendor sends items back to retailer based on purchase order and generates invoice to retailer. Based on items received, invoice is adjusted by retailer and payment is made to the vendor. PO can also be created by ORSIM through direct store delivery functionality and communicated to RMS.
In Brazil, receiving without a valid PO number is not allowed because fiscal receiving must precede physical receiving. Therefore, a direct store delivery without a PO cannot be received in SIM. A PO created in RMS is sent to RWMS and SIM through RIB as per the base process flow. The PO created flows to the Third Party Tax Rules through the Tax Integration Layer, along with the fiscal attributes of the suppliers, receiving locations, and the items. The Third Party tax engine calculates the tax breakdown and sends it back to RMS through Tax Integration Layer.
|
Note: RTIL is the layer for Tax Rules integration and PL/SQL is the layer for Synchro. |
A purchase order goes through the following process and is published to RWMS or SIM:
The purchase order is created in RMS.
The purchase order, along with the PO's fiscal attributes, are published to Tax Integration Layer.
The Brazil tax information is retrieved and appended to the purchase order and sent back to Tax Integration Layer.
Tax Integration Layer publishes the tax breakdown of the purchase order.
The purchase order is published to SIM or RWMS.
|
Note: Steps 2, 3 and 4 depicted above are specific to Brazil localization. Steps 1 and 5 are the same as in base RMS. |
ORFM has direct access to the PO created in RMS and the related fiscal details. This is required to validate and match the Nota Fiscal.
The following PO details are relevant to ORFM:
PO header information
Order supplier master data
Order supplier site master data
Order supplier site fiscal attributes
Delivery supplier master data
Delivery supplier site master data
Delivery supplier site fiscal attributes
Destination locations master data
Destination location fiscal attributes
PO detail information
Non-merch cost details
Item master data
Item fiscal attributes
For a PO with a warehouse as the receiving location, the NF schedule status is Submitted. The message confirming that fiscal receiving is complete is published to RWMS through the Oracle Retail Integration Bus (RIB).
The RIB message contains the following information:
Schedule number
PO number
Receiving physical warehouse number
Distinct item IDs per PO
Consolidated quantities per item-PO
UOM
One Nota Fiscal may contain items pertaining to several POs, and one schedule may contain several Nota Fiscal documents. It is likely that the supplier ships the same item on a PO through multiple NFs, and these NFs are part of the same schedule. If so, ORFM consolidates the item quantity by PO number before publishing it to RWMS.
After the automatic appointment creation, the RWMS user can schedule the appointment and proceed with the physical receiving. If Brazil localization is enabled in RWMS, receiving an item that is not in the appointment or receiving any extra quantity than in the appointment is restricted. Any such overage should be received separately in RWMS as an overage receipt.After completing the receipt, as the appointment is closed, the receipt and the overage receipt are published by RWMS through RIB. RMS consumes these messages and the Subscription API routes the messages to ORFM (in Brazil Environment). When receiving, the same receipt message is used that is used to update receipt information to RMS. Though not all fields in the receipt message are relevant to ORFM, ORFM still consumes the entire message and persists it until the RMS inventory is updated.
The Receipt Overage message is a RIB message from RWMS to ORFM.
The message contains the following information:
Schedule Number
ASN Number (Null for Warehouse receipts)
Item Id
Quantity Over-received
UOM
Reason Code
After ORFM consumes the Receipt and Receipt Overage messages, the discrepancy between physical and fiscal receiving is processed through the discrepancy resolution module. The correction letter and/or Return NF (for an overage receipt) are generated. No inventory updates happen in RMS for the overage receipt.For the received items, the taxes are stripped from the unit cost to arrive at the tax-exclusive cost, additional cost components (if any) are added to calculate the actual landed cost, and the inventory and WAC updates are sent to RMS along with the NF number. Other than the cost and NF, all other information regarding the shipment is taken from the receipt message received from RWMS.
For a PO with Receiving Location as a Store, if the NF schedule status is Submitted, the ASNs (ASNin) are generated and published to SIM. SIM then consumes this message to create the inbound ASN.
One NF can contain items pertaining to several POs, and one schedule can contain several NFs. It is likely that the supplier ships the same item on a PO through multiple NFs, and these NFs are part of the same schedule. If so, ORFM consolidates the item quantity by PO number before publishing it to SIM.
After the ASN message is received, the SIM user can proceed with the physical receiving. For Brazil localization, PO receiving without a valid inbound ASN is not permitted in SIM. In addition, receiving an item that is not in the ASN, or receiving any extra quantity than in the ASN, is restricted.
SIM can enforce this restriction in the following ways:
The user can continue receiving inventory beyond the expected quantity on the NF, but the extra quantity will be removed from the transaction when confirming the delivery.
The user is not allowed to receive any units above the expected quantity.
When receipt is completed for each ASN, the receipt and the overage receipt per ASN are published to RMS through RIB. For a receipt, the same receipt message is used that is used to update receipt information to RMS. The RMS subscription API does not consume the receipt message for the Brazil environment, but it is diverted to ORFM. ORFM stores the information in a staging table until all the ASNs in a schedule are received. The schedule status is changed to Received only when all the ASNs in a schedule are received. Referential integrity between the schedule number and the ASN is maintained in ORFM. SIM has no visibility to the schedule number. Not all the fields in the receipt message are relevant in ORFM, but ORFM still needs to consume the entire message and persist it until RMS inventory is updated.The Receipt Overage message is a RIB message from SIM to ORFM.
After ORFM receives the Receipt and Receipt Overage messages, the discrepancy between physical and fiscal receiving is processed through the discrepancy resolution module. As required, the correction letter and/or Return NF (for an overage receipt) are generated. No information about the overage receipt flows to RMS from ORFM. For over-receipt, no inventory updates happen in RMS.For the received items, the taxes are stripped off from the unit cost to arrive at the tax-exclusive cost. Additional cost components (if any) are added to calculate the actual landed cost. ORFM then calls RMS to update inventory and WAC. Other than the cost and the NF number, all other information regarding the shipment is taken from the receipt message that SIM has published.
A transfer (inter-company as well as intra-company) or allocation created in RMS is sent to RWMS and SIM through RIB.
ORFM has direct access to the transfer and the related fiscal details.
Transfers are created to move items from one location (source) to other (destination). Location could be store or warehouse.
|
Note: The following section uses warehouse-to-warehouse transfers to illustrate the transfer process. Other transfer processes, including warehouse-to-store, and store-to-store are similar from an ORFM perspective. |
If a warehouse-to-warehouse transfer (or allocation) is initiated in RMS, the transfer request flows to RWMS (Sending Location and the Receiving Location) through RIB.
|
Note: The sender warehouse and the recipient warehouse may run on the same instance or different instances of RWMS. If both warehouses run on the same instance of RWMS, RWMS-1 and RWMS-2 in the above image would be the same. |
If a warehouse-to-warehouse transfer is initiated in RWMS, it flows to RMS and the other RWMS through RIB. If the RMS-initiated transfer is modified in RWMS-1, the modifications flow back to RMS and the other RWMS.
In Brazil, each inventory movement (shipment) should be accompanied by a fiscal document (NF). When the shipment goes out of the source warehouse, an NF is generated and approved. When RWMS ships the transfer out, ORFM is informed about the ASNout details so that the outbound NF can be generated. On approval of the outbound NF, the on-hand inventory of the source warehouse and in-transit inventory of the destination warehouse are updated in RMS. The ASNout should be sent to the destination warehouse too, so that the destination warehouse generates the appointment and is prepared for the receiving.
When the transfer is picked and shipped in RWMS-1 at the source warehouse, ASNout is published and is subscribed to by RMS and RWMS of the destination warehouse simultaneously. In the Brazil environment, RMS routes the ASN message to ORFM. On consuming the ASN, ORFM generates the outbound schedules and outbound Nota Fiscal documents using the ASNout information. The tax information and the CFOPs are published on the NFs. NFs are validated before approval. On NF approval, the ASNout information is used to update the RMS inventory subsequently. The on-hand inventory of the source warehouse is decreased and the in-transit inventory for the destination warehouse is increased.
When the shipment arrives at the destination warehouse, the user is expected to create an inbound schedule using the outbound schedule. There should be an inbound NF for each outbound NF in the schedule, and a one-to-one relationship must exist between the outbound schedule and inbound schedule, as well as outbound NFs and inbound NFs. As the schedule is entered and validated (retrieve appropriate inbound CFOPs through TaxWeb Tax Rules), the schedule can be submitted to RWMS-2 for receiving. Because RWMS-2 already has the ASN information, it is enough that the message published to RWMS-2 contains just the schedule number and the ASN numbers grouped under the same schedule. To avoid introducing a new RIB message, the schedule is submitted with the entire ASN (referred to as secondary ASN). RWMS can ignore the other information in the message and can just refer to the ASN numbers. The schedule number can be null, as in the case of publishing an ASN to SIM.RWMS should create one appointment per schedule and combine all the ASNs for that schedule under the same appointment. After scheduling the appointment, the RWMS user can proceed with the physical receiving. It is possible that the user finds a discrepancy between the NF and the physical receipt. Any overage is consumed by ORFM, but no discrepancy resolution against overages is performed. In case of under-receipt, the receipt message coming from RWMS is the same as that of the ASN. In case of under-receipt in the destination warehouse, the inventory mismatch in the source warehouse should be handled manually by doing an inventory adjustment. In the Brazil environment, the RMS subscription API routes the receipt, overage, and inventory adjustment messages to ORFM. If the inventory adjustment reason code is associated with an utilization code, the NF should be generated in ORFM.On receiving the receipt message from RWMS-2, the inventory updates are done in RMS. The in-transit inventory at the destination location is reduced and on-hand inventory is increased. WAC is recalculated for the destination location. Subsequent to the inventory updates for receipts, the inventory is updated for the inventory adjustment for any under-receipt.After physical receiving is done at RWMS-2, RWMS-2 publishes the receipt and overage receipt (if any) message to ORFM through the RMS subscription API. Though ORFM may consume this message, ORFM does not use the information for updating the inventory. Any over-receipt at RWMS is handled outside the system.
|
Note: EG transfers created directly in RWMS without prior creation of a transfer in RMS is not supported in Brazil Localization install. Only EG transfers created using stock order subscriber is supported. |
An RTV request can be initiated in RMS (for returns from store), or in SIM and RWMS. An RTV request initiated in RMS should flow to SIM through RIB as per the existing flow.
When the RTV is picked and shipped from the warehouse, an RTV Shipment message should flow from RWMS to RMS through RIB. In the Brazil flow, after consuming the message, RMS routes it to ORFM; ORFM consumes the message from RMS.Using the information in RTV Shipment message, ORFM should generate the outbound RTV NF. If there is reference to the inbound NF (through which the stock was received), the tax information is also retrieved from the inbound NF. If no inbound NF reference is required, the system should obtain the tax information through the TaxWeb Tax Rules. The TaxWeb Tax Rules should return appropriate CFOPs too. The NF should then be auto-approved. The shipment can leave the warehouse on printing of the approved NF.The inventory updates are done in RMS and on-hand inventory is reduced. After the RMS updates are successful, the NF is approved. The RTV cost communicated to RMS is the tax-exclusive cost of the inventory returned. While making the transaction data entry, RMS should compare the RTV cost with the WAC, and if there is a mismatch, RMS should post a cost variance appropriately.In Brazil, any outbound shipment should have a valid approved outbound NF accompanying it. Neither RWMS nor ORFM can control the outbound trailer leaving the warehouse or store without a valid NF. Business discipline must be followed to ensure this.If for any reason the outbound NF cannot be generated or approved, the shipment cannot leave the source location. The RTV needs to be cancelled in that case. The system currently does not handle the cancellation of an RTV post-shipment from RWMS. It needs to be handled through manual inventory adjustments in RWMS and RMS simultaneously.
From an ORFM perspective, RTV shipments from stores are similar to RTV shipments from RWMS. When the RTV is shipped from the store, the RTV Shipment message flows from SIM to RMS through RIB. In a Brazil environment, RMS should direct the message to ORFM.Using the information in the RTV shipments message, ORFM generates the outbound RTV NF, obtains the tax information through the TaxWeb Tax Rules, matches the NF with the requisition (transfer request in RMS, if available), and approves the NF. The shipment can leave the warehouse on printing of the approved NF.During NF approval, the inventory updates and transaction data posting API in RMS is called. After RMS updates are successful, the NF is approved.
Fiscally, in the Return to Vendor operation it is assumed that the same merchandise received from supplier will be return. In Brazil, as any merchandise movement, this process requires a specific NF document to accompany the returning merchandise. This NF must obligatorily refer the NF received from the supplier for the PO, with the same tax basis and rates applied. Considering this, for tax compliance, the quantities returned must be lower or equal to the quantity received in the PO.
As government system authorize electronically a NF document, if no reference PO NF is specified in the RTV NF, it will be rejected for authorization. And as fiscally a return operation must fiscally reflect the original operation, if the same tax basis and tax rates are not applied, retailers will be subject to penalties.
When Balance Control for RTV is Enabled (FM_SYSTEM_OPTIONS.VARIABLE = 'BALANCE_CONTROLE_RTV' = 'Y'), the process to create a RTV NF consider the received quantity from a PO NF to create as many as lines/references to fullfil the RTV message quantity.
In the RTV NF creation, if the returned quantity to vendor is not sufficient to meet the balance from the most recent PO NF, the process will search the next previous NF(s), inserting new lines/references NF up to reach the total quantity returned to vendor.
The same RTV item can be inserted multiple times considering the following information from PO NF with different fiscal documents, Unit Cost, Triangulation information.
After RTV NF created, use reference from each item to retrieve taxes from PO NF and calculate them in proportion to quantity returned.
The third party management system sends Retail Merchandise Authorization (RMA) information to ORFM. ORFM consumes this information and creates an inbound NF in Pending for Receiving status which informs the user that NF is created and waiting for the goods to be received.
Once the goods are received at warehouse, WMS sends the returns receipt message to the third party. The third party sends the Processed RMA information to ORFM and at the same time it sends the RTLOG file to ReSA for inventory updates.
The user can cancel the NF in ORFM, if the goods are not received at WMS.
Following are the assumptions:
RMA is supported only in WMS since Return Receiving process is not supported by SIM
You need to attach Virtual Store to the Warehouse in RMS so that RTLOG files can be created for that virtual store
RTLOG files is generated by Third party order management system and sent directly to ReSA after the completion of RMA
You need to create RMA manually in RWMS during the physical receiving with NF, since there is no integration between ORFM and RWMS for RMAs
Third party order management application sends the costing information of the items related to corresponding RMA to ORFM
Third party Order Management application validates the customer ID along with its fiscal details before sending to ORFM
Only the processed status is sent, when the RMA processing is completed in Third party Order Management application
There is no Discrepancy Identification and Resolution process for RMA
In Brazil, the inventory adjustment may also require NF generation, depending on the reason for which the inventory was adjusted. The same inventory adjustment reason codes defined in RMS are available in RWMS and SIM. In ORFM, the utilization codes are associated with the reason codes. It is not mandatory that each reason code is associated with some utilization code, but if the reason code is associated with the utilization code, an outbound NF is generated. Because the inventory adjustment is done in SIM or RWMS, an Inventory Adjustment message should be published by SIM or RWMS. This message requires no changes to support Brazil specific flows. The message is consumed by RMS, and the subscription API routes it to ORFM in the Brazil environment. If the reason code associated with the inventory adjustment requires NF generation, an outbound NF is generated. After the NF validation and approval, the inventory in RMS is updated. If the reason code associated with the inventory adjustment does not require NF generation, using the same information received in the Inventory Adjustment message, RMS inventory is updated.
|
Note: In Brazil, a positive inventory adjustment is not legal. Therefore it is assumed that the user will perform a negative inventory adjustment each time. The NF generated will then be an outbound NF. |
A retailer can send goods out to an external finisher or supplier for either finishing work such as printing, dying, or embroidery, or repair in the case of damaged goods. After the job is done, the finisher or supplier returns the goods to the same or a different location. While the goods are out of warehouse or store for repair or finishing, RMS needs to account for the inventory as the retailer's inventory.This flow needs to be handled through two-legged transfers. The first leg of the transfer corresponds to the inventory being sent from the retailer's location (warehouse or store) to the finisher's location. The second leg corresponds to the receiving the finished goods (same or different SKU) or repaired goods back from the finisher at the retailer's location. Because the finisher's location is an outside location, the retailer is not responsible for the receiving or shipping at those locations.
When goods need to be sent to external finishers for finishing work, a two-legged transfer must be initiated in RMS, with transfer type as manual requisition. The first leg of the transfer (warehouse to finisher) flows to RWMS through RIB. RWMS persists it as a regular stock order. RWMS needs to do no special processing for such stock orders. When goods need to be sent to external finishers or suppliers for repair, a two-legged transfer can be initiated in RMS, with the transfer type as manual requisition and the context type as repair. The first leg of the transfer (warehouse to finisher) flows to RWMS through RIB. RWMS stores it as a stock order with the type set to Repairing. All Repairing types of stock orders need special processing in RWMS. A regular wave should not select these stock orders for picking. These stock orders are picked manually, and only the inventory associated with appropriate trouble code can be picked up for repairing.RWMS, as the physical owner of the inventory, has better visibility to the goods that need to be repaired. Therefore, a repairing stock order can be initiated in RWMS as well. As a stock order with the type of Repairing is created in RWMS, it flows to RMS through RIB. RMS, on consuming the message, creates a two-legged transfer with a context type of Repairing with the final location as the same origin warehouse. As the required stock is picked and shipped at RWMS (for the external finisher's location), the ASNout message is published. ORFM consumes this message through the RMS subscription API and generates an outbound NF with Repairing as the requisition type. During NF validation, tax information is retrieved from TaxWeb Tax Rules, and NF matching is done with the requisition document. RMS inventory is updated, and then the NF is approved. On NF approval, the shipment is dispatched from the warehouse. RMS publishes the information of the second leg to RWMS through RIB subsequent to the inventory updates. RWMS does not maintain any link between the first and the second legs of the transfer. For RWMS, the two legs of the transfer should be two independent transactions. The second leg does not need to have context type as Repairing. If it is, RWMS ignores it if the recipient is the warehouse.If the Auto Receive Stock indicator is enabled for the supplier in RMS, the on-hand inventory at the finisher's location is increased immediately as the stock is shipped from the retailer's location. If the indicator is disabled, on shipment of stock from retailer's location, in-transit inventory is increased at the external location. The on-hand inventory is updated only after RMS receives a receipt message from the finisher.
As the shipment leaves the warehouse, the first leg of the transfer is concluded from an ORFM perspective.
Receiving a two-legged transfer (second leg) is similar to transfer receiving or WO return receiving. The only difference is that the primary ASN is not already available in RWMS when the NF and schedule is entered in ORFM. The finisher ships the finished or repaired items (same or different SKUs) back to the warehouse along with the NF. As the shipment reaches the warehouse, a schedule is created and the inbound NF is entered into the system. The requisition number for the NF should be the main transfer number (two-legged). Each time, the requisition number on the NF should be the one in RMS. As the NF and schedule go through the tax validation and matching process, the schedule is submitted to RWMS for physical receiving. The message that flows from ORFM to RWMS through RIB should be equivalent to an ASNout message and should contain the schedule number and all the ASN details. The message should be detailed and should contain following fields:
ASN Number (ORFM should generate the ASN# and maintain the next up sequence number for it).
Requisition Number (the secondary transfer number)
Receiving Warehouse Number
Distinct Item Ids per transfer leg two
Consolidated Quantities per item-requisition
UOM
Schedule number
Container ID (ORFM should generate the container number and should maintain the next up sequence)
As RWMS receives this message, an automatic appointment (per schedule) is created and the ASN is linked to the appointment. After scheduling the appointment, physical receiving takes place. The user may find discrepancies between the NF and the physical receipt. In case of an overage, RWMS sends a separate overage message. Any over-receipt at RWMS is handled out of the system. In case of under-receipt, the receipt message coming from RWMS contains the same information as the ASN (items and quantities). Any inventory received short should flow to ORFM (through RIB and RMS subscription APIs) as a separate inventory adjustment message. After ORFM consumes the receipt message, the inventory updates are done in RMS. The in-transit inventory at the destination location is reduced and on-hand inventory is increased. WAC is recalculated for the destination location. Subsequent to the inventory updates for receipts, the inventory should be updated for the inventory adjustment for any under-receipt.
When goods need to be sent from a store to an external finishers for finishing work, a two-legged transfer needs to be initiated in RMS, with the transfer type set as manual requisition and no context type. The first leg of the transfer (store to finisher) should flow to SIM through RIB. SIM should persist this as a return to warehouse (RTW) request.When goods need to be sent out to external finishers or suppliers for repair, a two-legged transfer can be initiated in RMS, with the transfer type set to manual requisition and the context type to Repairing. The first leg of the transfer (warehouse to finisher) flows to SIM through RIB. SIM persists this as a return to warehouse request.Because SIM is the physical owner of the inventory, it has better visibility to the goods that need to be repaired. Therefore, a repairing RTW can be initiated in SIM as well. As a RTW with the type set to Repairing is created in SIM, it should flow to RMS through RIB. RMS, on consuming the message, creates a two-legged transfer, with the context type set to the value from the transfer created in SIM, and the final location as the same origin store. As the required stock is shipped from the store (for the external finisher's location), the ASNout message is published. RMS consumes this message and the subscription API directs it to ORFM. ORFM generates an outbound NF with Repairing as the requisition type. During NF validation, tax information is retrieved from TaxWeb Tax Rules. NF matching is done with the requisition document and on NF approval, the shipment is dispatched from the warehouse. RMS inventory is updated on NF approval. RMS publishes the information of the second leg to SIM through RIB after the inventory updates. SIM needs to maintain a link between the first and the second legs of the transfer because of serial-numbering requirements. RMS, while publishing the second leg to SIM, references the original transfer number. The second leg does not need to have the context type set to Repairing. SIM persists this transfer as a warehouse delivery.If the Auto Receive Stock indicator is enabled for the supplier in RMS, the on-hand inventory at the finisher's location is increased immediately as the stock is shipped from the retailer's location. If the indicator is disabled, on shipment of stock from retailer's location, in-transit inventory is increased at the external location. The on-hand inventory is updated only after RMS receives a receipt message from the finisher.As the shipment leaves the store, the first leg of the transfer is concluded from the ORFM perspective.
Receiving a two-legged transfer (second leg) is similar to a transfer receiving at a store. The only difference is that the primary ASN is not already available in SIM when the NF and schedule is entered in ORFM. The finisher ships the finished or repaired items (same or different SKUs) back to the warehouse along with the NF. As the shipment reaches the store, a schedule is created and the inbound NF is entered into the system. The requisition number for the NF should be the main transfer number (two-legged). As the NF and schedule go through the tax validation and matching process, the ASN is published to SIM for physical receiving. The message that flows from ORFM to SIM through RIB should be the equivalent of an ASNout message. The auto-receiving indicator should be 'Y' for this ASN. The detailed message should contain the following information:
ASN Number (ORFM should generate the ASN number and maintain the next up sequence number for it)
Requisition Number (the secondary transfer number)
Receiving store ID
Distinct Item IDs per transfer leg-two
Consolidated quantities per item-requisition
UOM
Container ID (ORFM should generate the container number and should maintain the next-up sequence)
Auto-receiving indicator (value should be 'Y')
As SIM receives this message, the ASN is automatically received and a receipt message is sent to ORFM. On receipt of the receipt message from SIM, the inventory updates are done in RMS. The in-transit inventory at the destination location is reduced and on-hand inventory is increased. WAC is recalculated for the destination location.
ORFM can integrate with other Oracle Retail products, such as SIM and RWMS, through Oracle Retail Integration Bus (RIB). RIB utilizes a publish and subscribe (pub/sub) messaging paradigm with some guarantee of delivery for a message. In a pub/sub messaging system, an adapter publishes a message to the integration bus that is then forwarded to one or more subscribers. The publishing adapter does not know or care how many subscribers are waiting for the message, what types of adapters the subscribers are, what the subscribers current states are (running/down), or where the subscribers are located. Delivering the message to all subscribing adapters is the responsibility of the integration bus.
See the Oracle Retail Integration Bus Operations Guide and other RIB documentation for additional information.
ORFM integrates with RTIL through a HTTP based interfaces. See "RTIL Architecture" for additional information.
ORFM integrates with Synchro through interface tables. See Chapter 12, "Maintaining Tax Related Data - Synchro".
The Nota Fiscal receiving (inbound) and issuing (outbound) are controlled within ORFM and all integration with RMS, RWMS, and SIM is based on the physical movement of the products.
When ORFM is enabled, SIM and RWMS are not allowed to physically receive any inventory prior to fiscal receiving (that is, inbound Nota Fiscal processing) is completed in ORFM. After physical receiving in SIM or RWMS, the inventory in RMS is not updated until the fiscal receipt and physical receipt comparison is completed in ORFM and any discrepancy is resolved.
Figure 4-14 outlines the ORFM business process for inbound operations.
The inbound process flow is as follows:
Enter the Nota Fiscal (NF) in the Oracle Retail Fiscal Management (ORFM) system.
When the shipment arrives at the warehouse or the store, create a schedule and enter the NFs received.
|
Note: You can link more than one NF to a schedule. |
After NF entry, validate the NFs. In the validation process, the application checks for data integrity. Match the NF with the requisition documents in Retail Merchandising System (RMS). This process is called as Fiscal Receiving.
If the NF and the PO does not match, the NF is in discrepancy. You can identify the following discrepancies with the ORFM application:
Unit Cost Discrepancy for each item in the NF
Quantity Discrepancy for each item in the NF
Tax Discrepancy at aggregate level (such as NF header level or individual item level) for all the applicable taxes
After validation, send the schedule to the Warehouse Management System (RWMS), and Store Inventory Management (SIM). After physical receiving, RWMS and SIM publish the receipt updates to ORFM. This completes the NF processing.
After NF processing is complete, ORFM calls RMS to update inventory and WAC.
Send the transaction data in RMS and ORFM to a financial application. For fiscal reporting purposes, send the NF data in ORFM to the fiscal reporting system like TaxWeb.
Because the Nota Fiscal contains taxation information, ORFM calls the tax engine for calculations during the receiving and issuing of a Nota Fiscal.
When ORFM is enabled, RMS inventory is not updated immediately when any inventory is shipped out from RWMS or SIM. The inventory movement information is first sent to ORFM for the generation of the outbound Nota Fiscal. After approval of the outbound Nota Fiscal, ORFM sends the inventory updates to RMS.
The outbound process flow is as follows:
Enter the outbound shipment information in SIM or RWMS and send it to ORFM.
ORFM sends the outbound shipment information to the tax engine. The tax engine figures the tax information and returns it to ORFM.
Create the Nota Fiscal based on the outbound shipment information and the tax information.
After NF processing is complete, ORFM calls RMS to update inventory and WAC.
ORFM supports the triangulation process. Triangulation is a typical purchase transaction where the PO is raised for a supplier (referred to as main/ordered supplier) but the goods are shipped to the retailer by a different supplier (referred to as the delivery supplier). In Brazil, for triangulation transactions, NFs are received from both the main and delivery suppliers. Both the NFs are for the same stock but the details on both the NFs may vary. For example, federal tax such as IPI usually appears on the main supplier's NF, while state taxes such as ICMS and ICMS-ST usually appear on the delivery supplier's NF.
ORFM supports generation of NF through EDI. Supplier will interface the NF details to RFM and is captured in the EDI tables. RFM has a batch which when run fetches data from the EDI tables and generates the NF in Worksheet status. The NFs are generated with the header, detail, informed header taxes, informed detail taxes, payment information, and complementary details fetched from the EDI tables interfaced by the supplier.
RWMS is integrated with the ORFM through RIB for the below business transactions:
ORFM publishes the Appointment Quantity based on the NF details to WMS
WMS schedules the Appointment based on the above information
WMS can over-receive/under-receive during physical receipt. The over-receipt is through new overage screen in WMS
The receipt information with the damaged and overage details are published by WMS to ORFM and ORFM to RMS
WMS and ORFM subscribes to the ASN information from the sourcing location
After the ASN is processed in ORFM, a secondary ASN is published to the warehouse receiving the transfer
The warehouse will receive against the secondary ASN and the receipt information is interfaced to ORFM through RIB
Brazil requirements are strict for receiving exactly what is on the NF. ORFM provides delivery information to RWMS, from which the user creates receiving appointments. The ability to alter appointment quantities is not available based on system parameter configuration. Validation exists to compare the appointment quantities with the quantities supplied by ORFM. Users can split items as needed by altering case pack sizes, but the totals must match with ORFM. The System Configuration Parameter -- appt_update_allowed should be set to N to disallow the appointment quantities being updated during receiving.
Requirements for each appointment are grouped into the same unique schedule number provided by ORFM. That schedule number is added to the appointment table and is searchable by users.
Nota Fiscal (NF) is a Brazilian fiscal legal document that needs to be generated to follow the physical movement of goods. ORFM handles the specific processing.SIM is impacted by NF in the following ways:
Shipping to warehouse or vendor
DSD Receiving
Transfer receiving
Inventory Adjustments and stock counts
Receive Unit Adjustments
The receiving process in SIM for internal (warehouse and store) deliveries does not allow under receiving or over receiving because of the following:
Transfers cannot be modified in Brazil through the user interface security; they are auto-received.
No adjustments are allowed in Brazil.
For warehouse deliveries, NF and SIM obtain the ASN information from the warehouse. After the ASN has been processed in NF, SIM obtains a second ASNin message. This message launches a new auto-receive process. Security is used to limit users' access to the warehouse delivery dialog. The reason for SIM to still subscribe to the ASNin message from RWMS or another store is so that the system knows which items are on their way while they are in transit, for more accurate inventory information.
Enterprise Business Suite (EBS) is integrated as financial system with Oracle Retail applications including RMS/ReSA. Financial integration between Oracle Retail and EBS is provided in the Oracle Retail Financial Integration (ORFI), Oracle Financial Operations Control Integration Pack for Oracle Retail Merchandising Suite, and E-Business Suite Financials. The Brazilian localized extensions that need to be used in conjunction with the ORFI are discussed in this section.
As part of the existing ORFI Integration, the EBS financial module communicates foundation information for supplier setup, payment terms, exchange rates, and chart of accounts to RMS/ReSA. In base version of Oracle Retail, EBS Financial module also communicates Chart of Accounts (COA) to ReIM. In Brazil localization, chart of accounts is not interfaced, and needs to be manually set up in ORFM.
Transaction information is communicated from RMS/ReSA to EBS Financial General Ledger through Oracle Data Integrator (ODI). In base version of Oracle Retail, ReIM communicates payment requests to EBS Accounts Payable (AP) through Retail enabled ODI. In Brazil localization, ORFM has built upon similar interface tables (AP Stage head and detail) as ReIM to publish accounts payable data. These tables are used to publish NF payment data from ORFM to EBS.
The following are discussed as a part of EBS integration:
Supplier Setup and Integration
ORFM AP Integration Stage Head and Detail
EBS AP allows setup of Brazilian specific fiscal attributes during supplier setup in a Brazil localized environment, for suppliers located in Brazil. These attributes are passed from EBS to RMS. The Vendor subscription API in RMS is enhanced to subscribe to additional fiscal attributes of the supplier.These fiscal attributes are passed from EBS AP to RMS in both Supplier Create and Supplier Update/Modify messages flows. Fiscal attributes added to new suppliers/sites that are newly created as well as modifications to these attributes will flow through to RMS as part of the integration.
The global attributes are passed from EBS AP to RMS and consumed at RMS. These attributes are captured in RMS as L10N Attributes (LFAS).
Table 4-2 provides the additional attributes that are passed from EBS AP to RMS and consumed at RMS.
Table 4-2 Additional Brazil Localization attributes passed from EBS AP to RMS
| EBS Field | Description | RMS Field | Description |
|---|---|---|---|
|
global_attribute9 |
EBS-Inscription Type (CNPJ or CPF) |
If type = "CNPJ" then TAXPAYER_TYPE="J"if type = "CPF" then TAXPAYER_TYPE = "F" |
Mapped to Taxpayer type field |
|
global_attribute10 |
EBS-Inscription Number |
If type = "CNPJ" concatenate fields global_attribute10, global attribute11 and global attribute12 into RMS field CNPJ If type = "CPF" concatenate fields global_attribute10 and global attribute12 into RMS field CPF |
Concatenate and record value under CNPJ or CPF field |
|
global_attribute11 |
EBS-Inscription Branch |
||
|
global_attribute12 |
EBS-Inscription Digit |
||
|
global_attribute13 |
EBS-State Inscription |
IE |
Mapped to IE field |
|
global_attribute14 |
EBS-City Inscription |
IM |
Mapped to IM field |
|
global_attribute17 |
SUFRAMA |
SUFRAMA |
Mapped to SUFRAMA |
|
NIT |
EBS - NIT (Numero de Inscrição do Trabalhador perante a previdencia social) - only for individual taxpayers |
NIT |
Mapped to NIT (Numero de Inscrição do Trabalhador perante a previdencia social) - only for individual taxpayers |
|
ISS_CONTRIB_IND |
EBS - ISS contributor indicator |
ISS_CONTRIB_ID |
Mapped to ISS contributor indicator |
|
SIMPLES_IND |
EBS - SIMPLES contributor indicator |
SIMPLES_CONTRIB_ID |
Mapped to SIMPLES contributor indicator |
|
ST_CONTRIB_IND |
EBS - ST contributor indicator |
ST_CONTRIB_ID |
Mapped to ST contributor indicator |
|
RURAL_PROD_IND |
EBS - Rural producer |
RURAL_PROD_IND |
Mapped to Rural producer |
|
ICMS_CONTRIB_IND |
EBS - ICMS contributor indicator |
ICMS_CONTRIB_IND |
Mapped to ICMS contributor indicator |
|
IPI_IND |
EBS - IPI contributor indicator |
IPI_IND |
Mapped to IPI contributor indicator |
|
PIS_CONTRIB_IND |
EBS - PIS contributor indicator |
PIS_CONTRIB_IND |
Mapped to PIS contributor indicator |
|
COFINS_CONTRIB_IND |
EBS - COFINS contributor indicator |
COFINS_CONTRIB_IND |
Mapped to COFINS contributor indicator |
|
IS_INCOME_RANGE_ELIGIBLE |
EBS - is income rage eligible indicator |
IS_INCOME_RANGE_ELIGIBLE |
Mapped to Is Income rage eligible indicator |
|
IS_DISTR_A_MANUFACTURER |
EBS - is the distributor a manufacturer indicator |
IS_DISTR_A_MANUFACTURER |
Mapped to Is the distributor a manufacturer indicator |
|
ICMS_SIMPLES_RATE |
EBS - ICMS SIMPLES rate |
ICMS_SIMPLES_RATE |
Mapped to ICMS SIMPLES rate |
|
Address_line4 |
EBS - Neighborhood |
NEIGHBORHOOD |
Mapped to neighborhood |
The recommended setting for Brazil localization is that you need to setup 01 address type as externally managed along with 04/06 address types. If you choose to internally manage the 01 address type, then the assumption is that it will be a Brazilian address and country (same as country on the 06 or 04 address type). RMS will not validate such settings and if you do not follow, it may cause issues in a Brazilian Localized environment.
As ReIM is not part of the Brazil solution, the ReIM to AP flow is replaced with an ORFM to AP flow.
Transaction data in ORFM maintains NF information so that it can be sent to the financial application. Different transaction codes are used for tax-exclusive cost (also referred as BC), cost components (such as freight or insurance), taxes that are input creditable, and taxes that affect cost (non-input credit type).For tax-related transaction data, the user can configure the system to make a separate entry for each tax code. By doing so, the user can map the same transaction code having different tax codes in different accounts.
Following tables describe the cross mapping between financial staging tables in ORFM and AP:
Table 4-3 Header level mappings between financial staging tables in ORFM and AP
| Product: E-Business Suite Version: 12.1.3Table: AP_INVOICE_LINES_INTERFACE (Target) | Product: Retail ORFMVersion: 14.1.3Table: FM_AP_STAGE_HEAD (Source) | |||
|---|---|---|---|---|
| Column Name | Data Type | Column Name | Data Type | Comments |
|
INVOICE_ID |
NUMBER |
FISCAL_DOC_ID |
NUMBER |
Populated with ORFM internal sequencing ID |
|
INVOICE_NUM |
VARCHAR2 |
FISCAL_DOC_NO |
VARCHAR2 |
Populated with the NF fiscal doc ID |
|
INVOICE_TYPE_LOOKUP_CODE |
VARCHAR2 |
FISCAL_TYPE_LOOKUP_CODE |
VARCHAR2 |
Type of Invoice (can be Standard, Credit or Prepayment) |
|
INVOICE_DATE |
DATE |
TRAN_DATE |
DATE |
Populated with the NF issue date |
|
VENDOR_ID |
NUMBER |
VENDOR |
NUMBER |
Supplier corresponding to the Supplier Site on the NF |
|
VENDOR_SITE_ID |
NUMBER |
ORACLE_SITE_ID |
NUMBER |
Supplier site ID of the 'Remit to site' corresponding to the Supplier on the NF |
|
INVOICE_AMOUNT |
NUMBER |
AMOUNT |
NUMBER |
|
|
INVOICE_CURRENCY_CODE |
VARCHAR2 |
CURRENCY_CODE |
VARCHAR2 |
Currency based on System Option Setup |
|
EXCHANGE_RATE |
NUMBER |
EXCHANGE_RATE |
NUMBER |
|
|
EXCHANGE_RATE_TYPE |
VARCHAR2 |
EXCHANGE_RATE_TYPE |
VARCHAR2 |
|
|
TERMS_ID |
NUMBER |
BEST_TERMS |
VARCHAR2 |
Populated with best terms id picked based on 'Best Terms calculation' logic that uses terms on the Supplier/ POs that are present on the NF |
|
SOURCE |
VARCHAR2 |
RFM |
Populated with value 'RFM' |
|
|
ORG_ID |
NUMBER |
ORG_UNIT |
NUMBER |
|
|
TERMS_DATE |
DATE |
BEST_TERMS_DATE |
DATE |
|
Table 4-4 Detail/Line Level mappings between financial staging tables in ORFM and AP
| Product: E-Business Suite Version: 12.1.3Table: AP_INVOICE_LINES_INTERFACE (Target) | Product: Retail ORFMVersion: 14.1.3Table: FM_AP_STAGE_DETAIL (Source) | |||
|---|---|---|---|---|
| Column Name | Data Type | Column Name | Data Type | Comments |
|
INVOICE_ID |
NUMBER |
FISCAL_DOC_ID |
NUMBER |
Populated with ORFM internal sequencing ID |
|
LINE_TYPE_LOOKUP_CODE |
VARCHAR2 |
LINE_TYPE_LOOKUP_CODE |
VARCHAR2 |
Type of invoice line (Item, Tax, Miscellaneous) |
|
AMOUNT |
NUMBER |
AMOUNT |
NUMBER |
|
|
ACCOUNTING_DATE |
DATE |
CREATE_DATE_TIME |
DATE |
|
|
DIST_CODE_CONCATENATED |
VARCHAR2 |
SEGMENT1 - SEGMENT20 |
VARCHAR2 |
|
|
ORG_ID |
NUMBER |
ORG_UNIT |
NUMBER |
|
For information on how to implement EBS, see the following MOS article:
https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?id=1580812.1
