| Oracle® Retail Store Inventory Management Store User Guide Release 16.0 E76179-08 |
|
 Previous |
 Next |
| Oracle® Retail Store Inventory Management Store User Guide Release 16.0 E76179-08 |
|
Previous |
Next |
This chapter covers ordering. The following topics are covered:
Item Requests: Request inventory for individual items.
Store Orders: Request inventory for purchase orders and warehouse transfer requests.
This section covers inventory requests for individual items.
Item Requests provide the ability for the store to request inventory for individual items. Inventory can be requested for items that are ordered by the central merchandising system or for items that are fully replenished based on store requested demand. The inventory is sourced to the store based on the corporate replenishment setup. This can be either a delivery from a warehouse or a drop ship from the supplier. The actual sourcing, delivery timings, and final quantities remain a function of the replenishment system.
Features include:
Manual creation of item requests
Scheduled item requests
Saving of item requests
Editing and deleting saved manual and system-created item requests
Printing of the Item Request Report
Each item request will have a requested delivery date
Item Requests may have a delivery timeslot
A retailer has certain items that are needed at different times of the day. Within an item request, a timeslot for the delivery can be specified, so it is possible to order doughnuts in the morning, sandwiches at lunch, and hot meals in the evening.
A retailer realizes that they are often out of dairy items or have too much spoilage because of very variable customer purchase habits. The retailer decides to have the store order what is needed by scheduling an item request product group for the Dairy Department for each Monday. An item request is generated on Monday for the dairy items and the retailer walks through the items on the request and enters in the needed quantity. The item request is fired off to the merchandising system and three days later the items arrive at the store on a warehouse to store transfer or supplier direct deliveries.
Item requests exist under the Inventory Management menu. From the Item Request List screen, the user can filter the item request records as needed. The user can create, view, edit, save, and confirm item requests.
This section covers system parameters, store parameters, and security.
System Parameters
Item Request UI Limit
Values: 1 - 100,000�
Default: 1500�
Topic: UI�
Editable: Yes
This parameter is used when breaking down the item request into smaller, more manageable item request transactions. This limitation is in addition to the value entered by the user on the Product Group Detail screen, which also helps to limit the size of the transaction.
Store Parameters
Display Item Request Delivery Timeslot
Values: Yes/No�
Default: Yes�
Topic: Item Request�
Editable: Yes
Yes: The delivery timeslot will be used within item requests.
No: Delivery timeslots will not be used, and will not be displayed in item requests.
Security
Security exists for:
Accessing, creating, editing, deleting, and requesting an item request.
Adding items to item requests.
Data permissions for the delivery timeslots.
This section describes the available screens.
Item requests are requests for goods within the store driven by a store user. The Item Request List screen displays all of the item requests that are in a "Pending" status. A Filter option is available to further search on the item request record. All item requests can be found in this dialog, those created within SIM manually as well as the system generated. The system-generated item requests will have a description which will be that of the product group schedule. All item requests will have a department populated, which will have the department which makes up most of the items on the item request. If there is more than one department on the item request, then a "+" sign will follow the department name.
From the Item Request List screen, the user has the potential to perform numerous tasks. The user can print, create, and delete an item request. The user can double click an item request which allows for viewing and editing.
The Item Request Filter screen is accessed by selecting the Filter button on the Item Request List screen. The filter allows a user to search for item requests using various search criteria. After applying the filter, the user will be returned to the Item Request List screen with the item requests displayed per the entered criteria.
The user access the Item Request Detail screen when selecting an item request or the Create option from the Item Request List screen.
Manual Item Request
The manual creation of an Item Request involves defining a requested delivery date. This is the date in which the goods are needed into the store. The requested delivery date must be greater than or equal to today. Any store order replenishment item added to the item request in which the store order reject indicator is set to "Yes" will need to have a requested delivery date on the request greater than the next delivery date for the item, or the item cannot be requested. These dates, flags, and settings are set up in the external replenishment system.
The request delivery timeslot can be selected at the header of the request and will be used to default to all new store order items added from that point onwards. The user can modify the timeslot on the item level if needed. The timeslot is used to specify a time during the day in which the items are needed, thus allowing for multiple delivery times in the day. Timeslots can only be defined for items which are store order replenishment items. The data permissions exist for delivery timeslots.
At the line item level, items are added to the item request. The system will show the available stock on hand as well as the in transit quantities to assist in the request making process. All items need a quantity even if it is zero to indicate no inventory is needed. Items must be ranged items to the user's store in order to be added. This is necessary, otherwise, processing cannot occur on the request in RMS.
The user can print an item request, save the item request into "Pending" status to complete later, or request complete the item request ("Completed"). Once the item request is completed it can no longer be edited. There are no inventory updates for item requests. The request is published to the merchandising system to be processed.
The system generated item request calculates the requested delivery date as well as the expiration date based on the product group; it cannot be edited. The system-generated item request will be populated with the items that get generated from the item request batch based upon the Item Request Product Group. These items can be deleted, and new items can be added. All other details for a system-generated item request are the same as that of the manual creation.
The Product Group Detail screen is used for various tasks within the application. For more details, see Chapter 2, "Admin and Configuration.". Item Request Product Groups are used to create groups of items that will be put into system-generated item requests. These system-generated item requests can be used as a worksheet and modified before completing and sending out.
The value entered into Days before Expiration will be added to the system date to calculate the expiration date for the item request. This is the date by which the user must request the items. This value will be used during the batch process to cancel old "pending" item requests. The days before delivery value will be added to the system date to derive the requested delivery date for system-generated item requests. The requested delivery date must be greater than the expiration date.
Items, Supplier, Promotion ID, and Hierarchy can be added as product group elements to the product group. When adding individual items to the product group, it does not matter if the item is store orderable or not, the item will get added to the item request. For all other elements, the item will only get added to the item request if it is store orderable. For more information, see "Batch."
System-generated item request product groups are scheduled using the Product Group Scheduler. A start and end date is defined along with a schedule for when it should reoccur. Those groups scheduled for today are generated upon completing the schedule whereas the others will be processed through the Item Request batch.
A SIM user is able to use item request functionality to request items regardless of the replenishment type normally used by the merchandising system to replenish the item. All items are sourced from either a warehouse or through a supplier depending on the sourcing parameters for the item specified in the replenishment system. Items specified as using Store Order replenishment (or items that are not set up for auto-replenishment at all) are sourced through the creation of one-off purchase orders or warehouse transfer requests only after the store has requested inventory using the Item Request functionality. There is no correlation in SIM between the purchase order/transfer and the item request.
Any quantities requested for items that have a replenishment type other than Store Order are added above and beyond the quantity that is normally sourced through the replenishment system on the item's next replenishment review date. However, if the requested delivery date falls prior to the item's next replenishment review date, the request is sourced through the creation of a one-off purchase order or warehouse delivery instead. All inventory requested is sourced to the store at the earliest possible date given the replenishment review date, the supplier or warehouse lead time, and any other factors that may influence the time it takes a delivery to reach the store.
SIM allows for creation of manual as well as system-generated item requests. Once created, from a technical point of view, the processing logic is the same for both manual and system-generated item requests.
From a technical perspective, item requests are also designed to have a single header record and one or more detail records.
Business objects are used within the application code for all business processing. The following business objects are used for item requests:
| Business Object | Description |
|---|---|
| ItemRequest | Contains header information about the item request including status. |
| ItemRequestLineItem | Contains detailed information about a specific item on the item request including order quantity and delivery timeslot. |
This section provides information on the integration for item requests.
RIB
Once an item request is created and requested in SIM, an outbound message with MESSAGE_FAMILY as InvReq and MESSAGE_TYPE as InvReqCre is created. This message contains the header as well as detail records for the item request. The message is staged and then published to the merchandising system through RIB.
| RIB Payload | Description |
|---|---|
| InvReqDesc | RIB payload that contains information about destination of the request, the request type, and an InvReqItem. |
| InvReqItem | Contains detailed information about the item including the quantity. |
Web Service
SIM supplies the Item Request Web Service:
| Service Operation | Description |
|---|---|
| lookupDeliveryTimeSlot | Retrieves all delivery time slots. |
| lookupItemRequestHeader | Retrieves item request headers based on search criteria. The header does not contain item related information. |
| readItemRequestDetail | Retrieves fully detailed information about an item request. |
| cancelItemRequest | Cancel the item request. |
System-Generated Item Requests
The Item Request batch will run and find all of the item request product group schedules with schedule dates of the date of the batch execution. The system will take all items attached to the product group and put them on the item request. Items that were added to the product group as a hierarchy, supplier, or promotion will only be added to the item request if they are store order replenishment items and inventory holding. Individual items will be added regardless of being a store order defined item.
|
Note: Franchise and consignment items will also not be extracted. |
If there are any items that are marked as store order items with a Reject Store Indicator of "Yes," the requested delivery date must be after the next delivery date for the item, or those items will not be put on the item request.
If there are pending system-generated item requests out there already, the batch will validate that the expiration date and requested delivery date (defined on the product group) have not passed yet. If they are in the past, then they will get updated to "Canceled."
The following database tables are used in item requests:
| Table Name | Description |
|---|---|
| ITEM_REQUEST | Contains item request records with the requested delivery date. |
| ITEM_REQUEST_LINE_ITEM | Contains detailed records for an item on item request along with the requested quantity and delivery slot ID. |
| DELIVERY_SLOT | Contains delivery slot information which is used by each line item on item request. |
| RPRT_ITEM_REQUEST_V | This view contains item request header information as well as detailed item records for an item request. |
This section covers inventory requests for purchase orders and warehouse transfer requests.
The Store Orders functionality gives the user the ability to request inventory using both Purchase Orders and Warehouse Transfer Requests in the merchandising system (RMS) from within the store. It empowers the store by giving the store user the ability to manage stock shortages and increased demand. When creating a store order, the user can select either a warehouse or a supplier as the source and add the items and quantities required to the order. The Store Orders functionality will then use web services to communicate with the merchandising system (RMS) in order to validate that all of the data is correct before creating (and/or approving) the store order.
Store ordering also provides the ability to view, create, modify, and approve orders generated through the replenishment process before they are approved. Store orders allow for the manipulation of the transfer or order directly in RMS.
This workflow illustrates how a retail store notices a sudden increase in demand, places the order to the warehouse which can act promptly to deliver the ordered items.
Store Orders functionality only exists on the PC application.
A retailer has milk and eggs that are set up on semi-auto replenishment. A Purchase Order gets generated in RMS for the milk and eggs in Worksheet status. The store manager opens the Purchase Order for the milk and eggs within the Store Orders dialog. The manager updates the quantities and approves the purchase order.
A retailer has a need to order more cornflakes due to the high demand of a current promotion. A retailer creates a store order to the warehouse for more boxes of cornflakes.
Store orders exist under the Inventory Management menu only on the PC application. From the Store Orders (list) screen, the user can filter store orders records as needed. The user can create, view, edit, save, and confirm store orders.
System Parameters
Restrict Store Purchase Orders to Store Orderable Items
Values: Yes/No�
Default: Yes�
Topic: Store Orders�
Editable: Yes
Yes: Only Store Orderable replenishment type items will be allowed to be added to the store order.
No: Any item can be added to the store order.
Display Unit Cost for Direct Deliveries
For details, see Chapter 9, "Direct Store Delivery."
This section describes the available screens.
The Store Orders screen displays all of the store orders that are in a "Pending" status within SIM. "Pending" records are those Purchase Orders that are in "Worksheet" or "Submitted" and those Warehouse Transfers that are in "Input" or "Submitted" within RMS. A Filter option is available to further search on the store order record.
From the Store Orders screen, the user has the potential to perform numerous tasks. The user can print, create, and delete store orders. A user can double click a store order in the list which allows for viewing and editing.
The Store Order List Filter is accessed by selecting the Filter button from the Store Orders screen. Criteria can be entered and applied. The results will display on the Store Orders screen.
The Store Orders Detail screen is accessed through the Create button or by selecting a store order from the Store Orders screen. The first step in creating a store order is to define a source for the order of either Warehouse or Supplier. The source can only be selected when creating a new transaction.
Supplier
The Supplier ID can be entered, or the user can use the Supplier Lookup function to identify a supplier. The supplier must be an Active supplier. The Not After Date, which is the latest date the items can arrive into the store, will be enterable for store orders to a supplier. All items added to the store order must be supplied by the selected supplier. The unit cost (Item/supplier/country) can be displayed and edited for the item on the store order, if the system is configured.
Warehouse
For store orders sourced by a warehouse, the user must first select a warehouse from the list of warehouses. All items added to the store order must exist at that warehouse.
Non-ranged items cannot be added to store orders. The system can be configured to restrict the items added to the store order to those which are Store Orderable replenishment items. The store order can be saved as "Pending" to complete at a later time or "Approved" and changes can no longer be made.
The Item Orders Screen is accessed by the Item's Orders button on the Store Order Detail screen. The Item Orders lists the store orders (associated with the user's current login store) that contain the item selected on the Store Order Detail screen (regardless of the status of the store order). The system will display only single location Purchase Orders and Warehouse Transfer Requests.
The Item Sales Screen is accessed by the Item's Sales button on the Store Order Detail Screen. The Item Sales screen lists the current login store's (historical) weekly sales figures for the item selected on the Store Order Detail Screen.
|
Note: This will display as many weeks of sales data as RMS holds history. |
The Deals Query screen is accessed through the Deals button on the Store Order Detail screen. It will display all deals associated with the selected item and supplier on the store order. The deal must be active and after the Not Before Date but less than the Not After Date of the store order. Deals are only available for store orders sourced by a supplier.
The SIM statuses will map to statuses in RMS as follows:
| SIM Status | RMS PO Status | RMS Warehouse to Store Transfer Request Status |
|---|---|---|
| Pending | Worksheet | Worksheet |
| Approved | Approved/Submitted | Approved/Submitted |
| Closed | Completed | Closed |
Purchase Orders that are created and approved using the Store Orders dialog in SIM will integrate from RMS to SIM using RIB (purchase order message) and appear within the Direct Store Delivery Dialog (Purchase Order List).
Warehouse to Store Transfers that are created and approved using the Store Orders dialog in SIM will integrate from RMS to SIM using RIB (transfer message) and appear as Planned Warehouse and Delivery on the Item Detail screen.
The Store Orders functionality gives the ability to view, create, modify, and approve both purchase orders and warehouse transfer requests in the merchandising system (RMS) from within the SIM application directly.
From a technical approach, store orders are designed to have a single header records and one or more detail records.
When creating a store order, the user can select either a warehouse or a supplier as the source and add the items and quantities required to the order. The store orders functionality will then use APIs to communicate with the merchandising system (RMS) in order to validate that all of the data is correct before creating (and/or approving) the store order.
Once a store order is created in SIM, it invokes the external web-services and passes the object "StoreOrder" to create/modify the store order in RMS. Once the order is created, it returns the order ID.
Business objects are used within the application code for all business processing. The following business objects are used for store orders:
| Business Object | Description |
|---|---|
| StoreOrder | Contains header-level information on store order and a group of StoreOrderLineItems associated to it. |
| StoreOrderLineItem | Contains detailed information about a single line item on a store order. |
| ItemSale | Contains information on item sales that includes sales value, quantity, and sales type. |
This section provides information on the integration for shelf replenishment.
RIB
There is no integration through RIB to other Oracle Retail products.
Web Services
SIM supplies a number of SOAP web services for the processing of store order and their related transactions. Each area is its own service containing relevant operations.
SIM supplies the StoreOrder Web Service SOAP web service which has following service operations:
| Service Operation | Description |
|---|---|
| findStoreOrders | Find all the store orders that match the criteria in the filter. |
| updateStoreOrderLineItems | Updates all the store order line items for the store order inserting new lines if they exist. |
| create | Create a store order in the system. |
| update | Update a store order within the system. |
| delete | Delete a store order from the system. |
| findItemSales | Find the item sales for a store and item. |
| findDeals | Retrieves deals for the parameters criteria. |
| pingExternalService | Contact the external service and transmit the message to see if the external service is functioning. |
| createTempRecordsForPrint | Create a store order in the system for printing. |
