| Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Release 18.0 F13732-01 |
|
 Previous |
 Next |
| Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Release 18.0 F13732-01 |
|
Previous |
Next |
This section describes the integration through RIB and web services.
Customer Order Create is used for Customer Orders that are a type of Web Order integrated through a message (FulfilOrdDesc). These integrations are used for the customer order from the Order Management System (OMS).
The Customer Order Create failure message (FulfilOrdCfmDesc) is a message that will be sent out to external system when we get a Customer Order that comes into the system through the RIB and fails due to validation issues such as an invalid item. The purpose of the create failure is so other systems will know it has failed when it came in and that it is not being processed.
The Stock Order Status message (SOStatusDesc) will be sent out with an SI upon reserving inventory for the customer order.
A Stock Order Status message (SOStatusDesc) is sent out with a type of SI upon reserving inventory. This happens when more is picked than what was on the order due to tolerances. This could also occur when a substitute item is added during the picking process.
The Stock Order Status message (SOStatusDesc) with a type of SD will be published to un-reserve the original items inventory when a substitute item has been added during picking.
A Stock Order status message (SOStatusDesc) is sent out with a type of PP when picking is completed.
Item Substitutes are sent to EICS from the merchandising system through the item message (ItemDesc).
An ASN Out message (ASNOutDesc) is sent out upon dispatching of the Delivery. This will be done for pick-ups and for shipments.
The Stock Order Status message (SOStatusDesc) with a type of PP will be published for the pick quantity in the scenario that more was delivered than what was picked.
The Stock Order Status message (SOStatusDesc) with a type of SI will be published for the reserved quantity. This will occur when more was delivered than what was reserved. This can happen when picking was not required, the reservation occurs upon receipt of a delivery, and the full amount had not been received, therefore not reserved.
Customer Order Cancellations (FulfilOrdRef) will come into EICS from external system such as an OMS through the RIB. This service will perform all the validations to determine if it should create a reverse pick and whether or not that reverse pick should be auto completed.
Customer Order Cancellation Confirmation (FulfilOrdRef) is a message to send to OMS upon completing of the system-generated reverse pick.
Stock Order Status message (SOStatusDesc) with a type of SD will be published for the reserved quantity to un-reserve the inventory for the reverse pick for system-generated picks.
Stock Order Status message (SOStatusDesc) with a type of PU will be published for the reverse picked quantity to un-pick the inventory for system-generated picks.
The following integrations are in addition to the standard integrations that already exist such as receipt message, and so on:
The Stock Order Status message (SOStatusDesc) with a type of SI will be published for the reserved quantity.
The Stock Order Status message (SOStatusDesc) with type of PP will be published for the picked quantity.
RIB payloads are used to communicate information to external systems through RIB Integration.
| RIB Payload | Description |
|---|---|
| FulfilOrdDesc | RIB payload that contains information about a new web order type of fulfillment order to be created in. |
| FulfilOrdCfmDesc | RIB payload sent from EICS that contains fulfillment order information when that order creating in EICS failed |
| FulfilOrdRef | RIB payload that contains information about a fulfillment order cancelation. It is sent to EICS to convey a cancelation request and sent from EICS to convey actual cancellations. |
| SOStatusDesc | Sent from EICS to convey changes in item status for a specific fulfillment order. Such changes of status include (un)reservation and (un)picking. |
| ASNOutDesc | Sent from EICS to convey a delivery for specified fulfillment order. |
MERCHANDISING publishes the Purchase Orders created for the direct store deliveries using RIB messages. EICS subscribes to these messages and stores them in the EICS database to enable receipt against Purchase Orders.
MERCHANDISING publishes the unit cost of the item at the item/supplier/country level for EICS to use in the receiving process.
EICS publishes the receipts done against the Purchase Order to the merchandising system (Receiving message).
EICS publishes the DSD receipts created in EICS without a Purchase Order to the merchandising system (DSDReceipts and DSD Deals messages).
EICS publishes the receiver unit adjustment done for the deliveries that are already confirmed (receiving message).
EICS is also capable of subscribing to the vendor EDI ASNs through RIB using the ASN In message format.
RIB payloads are used to communicate information from EICS to external systems and from external system to EICS through RIB Integration.
| RIB Payload (Subscriber) | Description |
|---|---|
| PORef | RIB payload that contains reference level information of a purchase order.This payload is used for removal of purchase orders. |
| PODesc | RIB payload that contains detailed information of a purchase order.This payload is used for creation and modification of purchase orders. |
| ASNInRef | RIB payload that contains reference level information of an ASN. This payload is used for removal of an ASN. |
| ASNInDesc | RIB payload that contains detailed information about the ASN. This payload is used for creation of a direct delivery (document type= 'P') or a warehouse delivery (document type= 'D').
EICS consumes this payload from warehouse when source and/or destination for ASN is a warehouse system. |
| RIB Payload | Description |
|---|---|
| ReceiptDesc | RIB payload that contains detailed information of the direct delivery receipt. This is published when the purchase order is not null.
EICS also consumes this payload for warehouse receiving. |
| DSDReceiptDesc | RIB payload that contains detailed information of the direct delivery receipt. This is published when the purchase order is null. |
| SOStatusDesc | RIB payload sent from EICS to convey changes in item status for a specific fulfillment order.
EICS also consumes this payload from warehouse for stock movements originating at the warehouse. |
| InvAdjustDesc | RIB payload that contains information about destination of the adjustment and an InvAdjustDtl. |
Inventory adjustments integrate to MERCHANDISING at the item level using the RIB. EICS creates the adjustments and groups them together by a header with multiple items, but for integration purposes they are published out at an item level.
Inventory adjustments are published for all manual and external system generated adjustments where the Publish indicator for the reason code is checked. Adjustments are also published for other types of transactions in EICS where the merchandise system is expecting an adjustment for stock on hand updates, for example, receiving a DSD with damaged goods. An adjustment is created behind the scenes only for publishing purposes to notify the merchandising system to move the goods into the unavailable bucket. These system type adjustments are not considered an adjustment within EICS; however, they are published as such for integration purposes.
EICS subscribes to inventory adjustment messages from warehouse systems and updates the warehouse inventory buckets in EICS.
RIB payloads are used to communicate to external systems through RIB Integration.
The following table shows the list of RIB Payloads available for inventory adjustments.
| RIB Payload | Description |
|---|---|
| InvAdjustDesc | RIB payload that contains information about destination of the adjustment and an InvAdjustDtl. |
| InvAdjustDtl | Contains detailed information about the item adjustment. |
Items come to EICS from a merchandising system through the RIB (items, item loc messages). EICS also gets information about items associated to a supplier through the RIB. Extended attributes are not received or sent on RIB payloads.
| RIB Payload | Description |
|---|---|
| ItemDesc | This payload contains information about an item. It contains a wide variety of information about the item including suppliers, UPCs, ticketing information, image information, UDAs, and related items |
| ItemLocDesc | This payload contains information about an item at a specific location. |
| ItemSupDesc | This payload contains information about an item for a specific supplier. |
| ItemSupCtyDesc | This payload contains information about an item for a specific supplier within a specific country. |
Stock counts generate inventory adjustment when completed.
RIB payloads are used to communicate to external systems through RIB.
| RIB Payload | Description |
|---|---|
| InvAdjustDesc | RIB payload that contains information about destination of the adjustment and an InvAdjustDtl. |
| InvAdjustDtl | Contains detailed information about the item adjustment. |
EICS does not integrate using a web service to any other Oracle Retail products for stock counts.
The Transfer Shipping allows for creating shipment, dispatching shipment, canceling shipment, creating container, approving container, adjusting container, and canceling the container.
The Transfer Receiving dialog allows for confirming receipt, copying misdirected container, receiving container and detailed receiving.
This section covers creating transfer documents which are then included in a transfer shipment and dispatched to another store, warehouse, or finisher.
Transfer documents can be created in the following ways:
Requesting store can create a transfer request.
Sending store can initiate a transfer by creating a transfer.
Merchandising can create a transfer request.
Each transfer document will have one or more items.
EICS will publish messages to Merchandising when the following happen:
Transfer is rejected.
Transfer is approved.
Transfer quantity is updated from the shipment.
Transfer Shipment describes the containers and the items for the shipment taking place. The shipment may be for one or more transfer documents as long as the transfer is going to the same destination. Dispatching a shipment will update the transfer document.
The user can create a shipment without referencing existing transfers or can create a new transfer on fly (Ad hoc transfer) based on the shipment information.
This transaction captures a delivery that took place from a warehouse, store, or finisher to the store receiving the delivery. It describes the containers and the items of the delivery that should be received by the store. Receiving a container of the delivery will update the transfer document.
Business objects are used within the application code for all business processing.
EICS allows the setting up of configuration parameters for the store as well as the system through this Admin category.
| Business Object | Description |
|---|---|
| BuddyStore | Contains the unique ID and name of the buddy store object |
| RIB Payload | Description |
|---|---|
| SODesc | This message is received from external systems when a stock order/transfer has been created |
| SOStatusDesc | This message is received from external systems when a stock order/transfer has been modified. |
| SORef | This message is received from external systems when a stock order/transfer has been deleted. |
| RIB Payload | Description |
|---|---|
| ASNOutDesc | This message is sent to external systems when the transfer shipment is dispatched. |
| ManifestCloseVo | This message is received from an external system to indicate physical shipment has been accepted. This will attempt to auto-close the transfer shipment if all items are shipped. |
| ManifestDesc | This message is sent to an external system when manifesting is activated and a transfer shipping container is confirmed. |
| ShipInfoDesc | This message is sent to an external system when pre-shipment notifications are active and a transfer shipment is either submitted or dispatched (without previously being submitted). |
| SOStatusDesc | This message is sent to an external system when a transfer shipment container is saved with shipping quantities. It is also sent when a transfer shipment container is canceled but had shipping quantities. Increase and decrease of quantities is indicated by the SI or SD codes. |
| RIB Payload | Description |
|---|---|
| ASNInDesc | Sent from external system to indicate a delivery is tracking place. It creates a transfer delivery record within EICS when a store location is involved. |
| ReceiptDesc | Sent to external system when a transfer delivery is confirmed.
Sent from external warehouse system when a transfer delivery is received at the warehouse. |
RTVs can only be created by a request from MERCHANDISING:
Each vendor return will have one or more items.
Each RTV shipment will tie back to a single vendor return document.
RTV shipment can be created in two ways:
From an externally initiated approved vendor return document.
Creation of ad hoc vendor return shipment which will create an approved vendor return on the fly.
Each vendor return shipment will have one or more containers; each container in turn will have one or more items.
EICS may publish messages when the following happens:
RTV shipment container is updated, and saved (Return To Vendor Publish)
RTV shipment is cancelled or rejected (Return To Vendor Publish)
RTV shipment is dispatched (Return to Vendor Publish and Ship Info Desc Publish, if dispatched without submitting)
RTV shipment is submitted (Ship Info Desc Publish)
RTV shipment container is confirmed (RTV manifesting, if configured)
RTV shipment is submitted (Pre-shipment notification, if configured)
The following payloads are used in RTV operations.
| RIB Payload | Description |
|---|---|
| RTVReqDesc | This payload is sent from an external system to indicate a request for a vendor return. It creates or updates a vendor return document within EICS. It contains a series of RTVReqDtl. |
| RTVReqDtl | This payload contains the detailed information about the items on the vendor return. |
| RTVReqRef | This payload contains reference information about a vendor return when an external system wishes to attempt to cancel the return. |
| RTVDesc | This payload is sent from EICS to external systems when an RTV shipment is dispatched.
This payload is sent from external warehouse system for vendor returns originating at warehouse. |
EICS provides a large range of web services to manage the processing of information that is controlled within EICS. Each web service covers a topical area of functionality within ECIS and contains numerous operations within to accomplish this functionality. This document is only meant as an outline or summary into using EICS web services and assumes the user has access to the fully documented APIs through the publishing of the web services themselves.
This document is intended to be used by someone who has read and understands all the functional areas and business functionality described in the Oracle Retail EICS User's Guide and Oracle Retail EICS Administration Guide.
The following list contains a summary of the web services available in EICS.
| Service | Description |
|---|---|
| Web Service: ActivityLock |
This service is used to manage the locking of data within EICS. Data needs to be locked to be updated securely. |
| Web Service: StoreFulfillmentOrder |
This service is used to manage fulfillment orders within EICS. It allows for the cancellation and rejection of orders and items. |
| Web Service: FulfillmentOrderDelivery |
This service is used to manage fulfillment order deliveries (outgoing shipment to customers). It allows the creation, cancellation and dispatch of deliveries. |
| Web Service: FulfillmentOrderPick |
This service is used to manage fulfillment order picking within EICS. It allows the creation, deletion and confirmation of a pick to complete a fulfillment order. |
| Web Service: FulfillmentOrderReversePick |
This service is used to manage fulfillment order reverse picking within EICS. It allows the creation, update, deletion and confirmation of a reverse pick. |
| Web Service: InventoryAdjustment |
This service is used to manage inventory adjustments within EICS. It allows the creation, update, cancellation and confirmation of inventory adjustments. |
| Web Service: StoreNotification |
This service is used to inject event or information notifications that are then delivered to users through our clients. |
| Web Service: POSTransaction |
This service processes external point-of-sale transactions updating the inventory accordingly. A point-of-sale is considered an externally managed transaction (internally and externally managed transaction are covered later in this document). |
| Web Service: ProductGroup |
This service is used to create or update a product group. |
| Web Service: ProductGroupSchedule |
This service is used to create, update, or cancel a product group schedule. |
| Web Service: RfidInventory |
This service is used to create, update or delete a RFID facility zone. It is also used to refresh inventory and to process RFID events. |
| Web Service: ReplenishmentGap |
This service is used to create, update, or delete a replenishment gap. |
| Web Service: ShelfAdjustment |
This service is used to create, update, cancel or confirm a shelf adjustment. |
| Web Service: ShelfReplenishment |
This service is used to create, update, cancel or confirm a shelf replenishment. |
| Web Service: ShipmentReason |
This service is used to retrieve shipment reasons codes to use when creating shipments. |
| Web Service: StockCount |
This service is used to retrieve the details of a stock count or a stock count child (section of stock count). |
| Web Service: Store |
This service is used to retrieve information about stores such as store detail, associated stores, or transfer zones. |
| Web Service: StoreInventory |
This service is used to lookup information about inventory positions and has several different operations to do so. |
| Web Service: StoreInventoryUIN |
This service is used to create, update, generate or read a UINs. |
| Web Service: StoreItem |
This service is used to lookup various information about an item within the store. |
| Web Service: StoreItemPrice |
This service is used to lookup prices about items within a store. |
| Web Service: StoreTransfer |
This service is used to create, update and request a transfer, which describes the intent to ship items to another store or to a warehouse. It is also used to approve or reject that request. It can be used to directly create, update, approve, cancel, or close an actual transfer. |
| Web Service: TransferDelivery |
This service is used to update, receive, or confirm a transfer delivery (delivery arriving from another store or warehouse). It is also used to create, update, receive, cancel, or confirm the containers on that delivery. |
| Web Service: TransferShipment |
This service is used to create, update, submit, or dispatch a transfer shipment (shipment going out to another store or warehouse). It is also used to create, update, cancel, or confirm the containers on that shipment. |
| Web Service: VendorDelivery |
This service is used to update, receive, reject, or confirm a vendor delivery (delivery arriving from a supplier). It is also used to create, update, cancel, or confirm the containers on that delivery. |
| Web Service: VendorReturn |
This service is used to create, update, approve, cancel, or close a vendor return document, which describes the intent to ship items to a supplier. |
| Web Service: VendorShipment |
This service is used to create, update, open, submit, cancel submit or dispatch a vendor shipment (outgoing shipment to a supplier). It is also used to create, update, cancel, submit or confirm the containers on that shipment. |
Empty Response
In the cast that a web service does not return any information (an empty list), the external system needs to understand that this is a valid response that indicates no item, transaction or queried information was found or retrieved. For example, performing a lookup in which the search criteria entered matched no input.
Error Return Key
Errors returned through a web service will be in the form of a key. This key should be translated into correct language and verbiage by the external system. EICS will not do this translation or provide English verbiage for the encountered web service error.
Boolean Data Type
If a Boolean is the data type on the interface to EICS, and no value is provided, EICS will default the value to False.
Configured System Options in EICS
Web services apply system configurations to the request that are coming in through the web service, but assumes that all input validation that requires user interaction to confirm has been completed by the access or of the web service. This system configuration user-interaction option will be assumed to have been confirmed during the web service processing. In case the system option is a fixed restriction that does not require user interaction, and the input fails this restriction, the web service will return an error. For example:
Shipping inventory when inventory is less than 0 can be allowed by the user of EICS. The web service assumes that the third party application did prompt the user or that their business always allows the user to do this activity.
Adding a non-ranged item requires both a system configuration option to be enabled and the user to confirm the process. If the system configuration does not allow it, the web service will block the transaction and return an error. If the system configuration does allow adding non-ranged items, it is automatically assumed that a user confirmed its addition and the web service adds the item.
Allowing Receiver Unit Adjustments are dependent on a period of time. If a receiver unit adjustment were to come into EICS after that period of time, it would automatically be rejected and the web service would return an error regardless of presentation or confirmation of user done by the external system.
Internally Initiated
Internally initiated indicates the EICS was responsible for the original creation of the transaction being processed. A web service that creates a new transaction within EICS to be managed creates an internally initiated transaction.
Externally Initiated
Externally initiated indicates that another system created the transaction, has information about it, and notifies EICS of its creation through a notification system, not by requesting EICS create new information. EICS might manage the data after the notification, but did not create the data.
Internally Managed
Internally managed data is information in which EICS is responsible for tracking its state and processing its life cycle. Our deliveries and shipments are primary examples of this. They may be externally initiated or internally initiated, but either way, they are internally managed. EICS is responsible for approving, picking, packing, manifesting, and dispatching the system and internally manages that process.
Externally Managed
Externally managed data is information that EICS does not process or track and is simply informed about after the externally managed data is complete. Point-of-sale transactions are a perfect example of this. We do not manage the sale, but once it is complete, EICS is notified and adjusts the inventory accordingly.
Web Services
EICS web services are intended for integration in order to allow a system using those services to control the flow and processing within EICS. Our web services are primarily designed (almost all of them) to internally manage the information. The services are intended to be used real time with the steps such as approving, picking, and dispatching occurring with real time access to EICS web services while the process is happening.
EICS web services are not designed for externally managed information. If a system is controlling the state managements itself and not informing ECIS until later, this will produce out-of-sync inventory. For example, if you create a shipment, pack the shipment, and send it out and then a day later use the web service, to create, update, and dispatch the shipment, all dates and processing of inventory movements will be tagged with the later date as if they occurred real time when the web service is used. Another example is creating an inventory adjustment and approving it three days later and sending it to EICS after it is approved. Both the creating of the adjustment and approving of it is intended to be real time. When we receive the information later, both the create date and approval date are at the moment we receive it (not the dates they were managed in the external system).
The point-of-sale service is the only externally managed service, where the timestamp on the service can be any date and EICS handles the logic of dating things according to that timestamp.
This section discusses the general approach and design standards for naming and intent regarding operations within a web service.
Lookup
Lookup operations take either an identifier of a set of criteria and find all the relevant records associated to it. A thin or light view of the data being asked for is returned giving reference to information you can do further interrogation on.
Read
Read operations take an identifier and return all relevant information to it. It may only be one level however. For example, reading a transfer shipment returns only all the information at the shipment level and does not read information at the container or item level. Usually the entity that contains items will also retrieve the items. Reading a container will return the container information and the item information within.
Create
Create usually inserts and generates something new and returns an identifier, reference, or handler to that information. Create normally does not take a great deal of information, such as items or anything, but rather gives you a set of IDs that then lets you update the transaction with that reference.
Save or Update
Save or update is used to modify the data usually without changing state on the transaction. The save or update operation is used to add items, remove items, edit attributes, change quantities and all the other tasks one does during a process.
Approve, Cancel, Confirm or Dispatch
Activities that change state take in a simple identifier and then process that state change. To dispatch a shipment, you pass in a reference only to the shipment and it becomes shipped, updating the inventory. This means all changes are done through the save operations prior to making the state change.
If some data could not be processed, the web service will return a system fault or a validation fault. In the case of a validation fault, the Fault will be returned to accessing system and the fault string will contain "VALIDATION_ERROR". This fault will come with a number of problem details that contain name value pairs. The following are some common problem detail information that can be useful in figuring out the source of the error in the accessing system.
| Problem Detail Name | Value |
|---|---|
| ERROR | This describes the error (for example: INVALID_INPUT) |
| OBJECT | This describes the parent data object of the input data that contained the error. |
| OBJECT_ID | Identifies the object that contained the error. |
| ATTRIBUTE | Identifies the specific attribute that had an error. |
EICS follows the same business rules when processing information from a web service as it does from any of its clients, so the same business rules and functionality that exist in the User's Guide also exists for the web service. Understanding the basic functionality will help interpret why the validation or processing error occurred.
Web services available in EICS:
The following operations are available within the ActivityLock web service.
| Operation | Description |
|---|---|
| lookupActivityLock | Retrieves information about one or more activity locks that match the input criteria. |
| readActivityLock | Retrieves detailed information about a single lock using its identifying reference. |
| createActivityLock | Created an activity lock on a transaction. |
| deleteActivityLock | Deletes an activity lock thereby releasing processing on a transaction. |
Standard Usage
An activity lock is a record indicating the user, time, and a piece of information (a transaction) that should be considered "locked". All server processing validates that the accessing user has a lock on the information before updating, notifying the current user if someone else has modified the information while they were locked and preventing the stale update.
Developers should create locks on information prior to performing update calls and delete locks when the update if finished. For example, create a lock on inventory adjustment with ID 123 with the ActivityLock service, then use saveInventoryAdjustment in the Inventory Adjustment service with Adjustment 123, and then delete the activity lock using the ActivityLock service. If you do not gain the lock, you will receive an error when attempting to save an inventory adjustment.
The following operations are available within the FulfillmentOrderDelivery web service.
| Operation | Description |
|---|---|
| lookupFulfillmentOrderDeliveryHeaders | Retrieves summary information for fulfillment order deliveries that match the search criteria input. |
| readFulfillmentOrderDeliveryDetail | Reads the complete detailed information about a fulfillment order including items and quantities. |
| createFulfillmentOrderDelivery | Creates a new fulfillment order delivery including items and quantities in an in-progress status to be further worked on. |
| cancelFulfillmentOrderDeliverySubmission | Cancels the fulfillment order review and moves it back into in-progress status for further work. |
| dispatchFulfillmentOrderDelivery | Dispatches the fulfilment order delivery completing the delivery and updating the inventory. |
| submitFulfillmentOrderDelivery | Submits the fulfillment order delivery for review prior to dispatching. |
| updateFulfillmentOrderDelivery | Updates a fulfillment order delivery including items and quantities. This operation requires an activity lock. |
Standard Usage
A user can create a delivery by using createFulfillmentOrderDelivery references the fulfillment order to make a delivery for. The user can then use updateFulfillmentOrderDelivery to fill in all the quantities that are going to be shipped and finally use dispatchFullfillmentOrderDelivery to indicate that the order has been shipped out, which moves the inventory appropriately.
The following operations are available within the FulfillmentOrderPick web service.
| Operation | Description |
|---|---|
| lookupFulfillmentOrderPickHeaders | Retrieves summary information for fulfillment order picks that match the search criteria input. |
| readFulfillmentOrderPick | Reads the complete detailed information about a fulfillment order pick including items and quantities. |
| confirmFulfillmentOrderPick | Confirm the fulfillment order pick which allows it to move on to the delivery cycle. |
| deleteFulfillmentOrderPick | Deletes a fulfillment order pick. |
| createFulfillmentOrderPickByFulfillmentOrder | Generate a pick based on the information in a fulfillment order. |
| createFulfillmentOrderPickByBin | Generate a pick based on a number of bins selecting orders as needed to fill the bins. |
| updateFulfillmentOrderPick | Update the item and quantity information about a pick. This operation requires an activity lock. |
Standard Usage
Picking is used to reserve or set aside quantities for a later delivery. The user can create a pick for an order using createFulfillmentOrderPickByFulfillmentOrder or create a bin to places multiple orders in with createFulfillmentOrderPickByBin. The picked quantities can be updated through the updateFullfillmentOrderPick operation and when the pick is finished, it can be finalized with confirmFulfillmentOrderPick which sets assigned the goods as reserved in inventory.
The following operations are available within the FulfillmentOrderReversePick web service.
| Operation | Description |
|---|---|
| lookupReversePickHeaders | Retrieves summary information for fulfillment order reverse picks that match the search criteria input. |
| lookupReversePickDetail | Reads the complete detailed information about a fulfillment order reverse pick including items and quantities. |
| createReversePick | Creates a new fulfillment order reverse pick for the specified fulfillment order. |
| deleteReversePick | Deletes a fulfillment order reverse pick. |
| updateFulfillmentOrderReversePick | Updates the items and quantities on a fulfillment order reverse pick. This operation requests an activity lock. |
| confirmReversePick | Confirms the fulfillment order reverse pick completing the process and assigning the inventory back to a location within the store system. |
Standard Usage
Reverse Picking is used to take reserved quantities and place them back into available inventory. The user can create a reverse pick with createReversePick. The quantities to return can be updated through the updateFulfillmentOrderReversePick operation and when the reverse pick is ready, it can be finalized with confirmReversePick which moves reserved inventory back into available inventory.
The following operations are available within the StoreNotification web service.
| Operation | Description |
|---|---|
| processPOSTransactions | Processes a point-of-sale transaction or transactions through an asynchronous process. This is designed to optimize the processing of large numbers of point-of-sale transaction (up to a limit of 5,000 PosTrnItm details). |
Standard Usage
POS may integrate its transactions to EICS using this web service. The service processes point-of-sale transactions through an asynchronous process. This service only allows 5,000 overall PosTrnItms, though they may be distributed between any number of actual PosTrn transactions. Exceeding this limit causes a web service fault to occur. These transactions may belong to multiple store identifiers. The processing operation validates the input, parses the payload information, creates a POSTransaction object within EICS, and stores these records to be processed later. See Sales Processing for additional information.
The following operations are available within the InventoryAdjustment web service.
| Operation | Description |
|---|---|
| lookupInventoryAdjustmentReason | Retrieve a complete list of adjustment reasons that can be used when updating or saving an inventory adjustment. Reason codes are attached to each line item. |
| lookupNonSellableQuantityType | Retrieve a complete list of non-sellable quantity types. These code indicate the reason that unavailable inventory in unavailable. |
| lookupInventoryAdjustmentHeader | Retrieve summary information about inventory adjustment transactions based on the search criteria sent. |
| readInventoryAdjustmentDetail | Retrieve the complete detailed information about an inventory adjustment, including its item information, based on a unique reference/id. |
| saveInventoryAdjustment | Creates or updates the information about an inventory adjustment in the data store. You can alter information about items and quantities using this operation. This operation requires having an activity lock. |
| confirmInventoryAdjustment | Confirms the inventory adjustment, updating all the inventory positions, and closing the adjustment. |
| saveAndConfirmInventoryAdjustment | Performs the functionality of saveInventoryAdjustment and immediately thereafter performs the confirmInventoryAdjustment functionality. See those operations. |
| cancelInventoryAdjustment | Cancel an inventory adjustment. This can only be done prior to the inventory adjustment being confirmed. |
Standard Usage
A new inventory adjustment can be created using the saveInventoryAdjustment operation. Alternatively, the user can lookupInventoryAdjustmentHeader to find a specific inventory adjustment to work on. Either way, saveInventoryAdjustment can be used to update the information on an open adjustment. The lookupInventoryAdjustmentReasons will retrieve the reasons codes that need to be assigned to items when you update an adjustment. When the adjustment contains all the information you need, the confirmInventoryAdjustment operation will finalize the inventory adjustment and shift the inventory appropriately.
The following operations are available within the ProductGroup web service.
| Operation | Description |
|---|---|
| lookupProductGroupHeader | Retrieves list of summary information about a product group that match the search criteria input. |
| readProductGroup | Retrieves the detailed information about a single product group based on its unique reference. |
| saveProductGroup | Creates or updates a product group. The input contains all the detailed information about the product group. An activity lock is needed for this operation. |
Standard Usage
With this web service, the user can create or update the contents of a product group, a collection of items associated with a certain type of grouping, such as stock counts. The user can find the product group with lookupProductGroupHeader, read in the entire product group with readProductGroup and then, if the group is still open, update the contents of the product group with saveProductGroup.
The following operations are available within the ProductGroupSchedule web service.
| Operation | Description |
|---|---|
| lookupProductGroupScheduleHeader | Retrieves list of summary information about a product group schedule that match the search criteria input. |
| readProductGroupSchedule | Retrieves the detailed information about a single product group schedule based on its unique reference. |
| saveProductGroupSchedule | Creates or updates a product group. The input contains all the detailed information about the product group schedule. An activity lock is needed for this operation. |
| cancelProductGroupSchedule | Cancels the product group schedule. |
Standard Usage
With this web service, the user can create or update the contents of schedule, which uses a product group to generate activity within EICS. The user can find the schedule with lookupProductGroupScheduleHeader, read in the entire schedule with readProductScheduleGroup and then, if the schedule is still open, update the contents of the schedule with saveProductGroupSchedule.
The following operations are available within the ReplenishmentGap web service.
| Operation | Description |
|---|---|
| lookupReplenishmentGapHeaders | Retrieves list of summary information about replenishment gaps that match the search criteria input |
| readReplenishmentGap | Retrieves the detailed information about a single replenishment gap based on its unique reference. |
| saveReplenishmentGap | Creates a new replenishment gap or updates the detailed information about a replenishment gap. If update, this operation requires an activity lock. |
| deleteReplenishmentGap | Deletes a replenishment gap. |
Standard Usage
With this web service, the user can create or update the contents of replenishment gap list which can then be used in creation of shelf replenishment within EICS. A new replenishment gap list can be created using saveReplenishmentGap. The user can update existing replenishment gap list with saveReplenishmentGap, find replenishment gap lists with lookupReplenishmentGapHeaders, read in the entire replenishment gap list with readReplenishmentGap and delete a replenishment gap list with deleteReplenishmentGap.
The following operations are available within the RfidInventory web service.
| Operation | Description |
|---|---|
| deleteRfidZone | Deletes a zone within a facility. A zone cannot be deleted if RFID tags still exist within the zone. |
| lookupRfidZones | Returns details about all the zones within a particular facility. |
| processRfidEvents | Processes Radio-Frequency-Identification based events. |
| refreshInventory | Refreshes the inventory for items within a faciltiy to match the current count of RFID tags. |
| saveRfidZone | Creates or updates the details of a facility zone. |
Standard Usage
With this web service, the user can create or update RFID zone within EICS. A new RFID zone can be created using saveRfidZone. The user can update existing RFID zone list with saveRfidZone, find RFID zome lists with lookupRfidZones and delete a RFID zone with deleteRfidZone. The user can process a RFID based events using processRfidEvents and refreshes the inventory for items with refreshInventory.
The following operations are available within the ShelfAdjustment web service.
| Operation | Description |
|---|---|
| lookupShelfAdjustmentHeaders | Retrieves list of summary information about shelf adjustments that match the search criteria input. |
| readShelfAdjustment | Retrieves the detailed information about a single shelf adjustment gap based on its unique reference. |
| saveShelfAdjustment | Creates a new shelf adjustment or updates the detailed information about a current shelf adjustment. If update, this operation requires an activity lock. |
| confirmShelfAdjustment | Confirms a shelf adjustment completing the workflow and moving inventory positions. |
| cancelShelfAdjustment | Deletes a shelf adjustment. |
Standard Usage
Shelf adjustments are used to adjust the shop-floor or backroom stock in case of any discrepancy. A new shelf adjustment can be created using saveShelfAdjustment. The user can update existing shelf adjustment with saveShelfAdjustment, find shelf adjustment with lookupShelfAdjustmentHeaders, read in the entire shelf adjustment with readShelfAdjustment, cancel a shelf adjustment with cancelShelfAdjustment and confirm a shelf adjustment with confirmShelfAdjustment.
The following operations are available within the ShelfReplenishment web service.
| Operation | Description |
|---|---|
| lookupShelfReplenishmentHeaders | Retrieves list of summary information about shelf replenishments that match the search criteria input. |
| readShelfReplenishment | Retrieves the detailed information about a single shelf replenishment gap based on its unique reference. |
| createShelfReplenishment | Creates a new shelf replenishment. |
| updateShelfReplenishment | Updates the detailed information about a current shelf replenishment. This operation requires an activity lock. |
| confirmShelfReplenishment | Confirms a shelf replenishment completing the workflow and moving inventory positions. |
| cancelShelfReplenishment | Deletes a shelf replenishment. |
Standard Usage
Shelf replenishment is used to replenish shop-floor stock from backroom or delivery bay. A new shelf replenishment can be created with createShelfReplenishment. The user can find shelf replenishments with lookupShelfReplenishmentHeaders, read in the entire shelf replenishment with readShelfReplenishment, update the shelf replenishment with updateShelfReplenishment, confirm the shelf replenishment with confirmShelfReplenishment and cancel the shelf replenishment with cancelShelfReplenishment.
The following operations are available within the ShipmentReason web service.
| Operation | Description |
|---|---|
| lookupAllShipmentReasons | Retrieves all the shipment reasons configured for store shipments. |
Standard Usage
This web service exists to allow customers to retrieve information about shipment reasons that can be assigned to line items on outgoing shipments. The shipment based web services taking the code identifier and thus, you will need to read in these shipment reasons to be able to select and apply valid reason codes.
The following operations are available within the StockCount web service.
| Operation | Description |
|---|---|
| lookupStockCountHeaders | Retrieves list of summary information about a stock counts that match the search criteria input. |
| readStockCountDetail | Retrieves the detailed information about a single stock count based on its unique reference. This contains a list of summary information about the child counts. |
| readStockCountChild | Retrieves the detailed information about a single stock count child. |
Standard Usage
The stock count web services are design primarily to export information for third party counting. You first lookup the headers, choose your head, retrieve all the details for the stock count, which does not contain item information but does contain a list of child count references. You can use these references to grab the full details of a child count which includes items and quantities.
The following operations are available within the Store web service.
| Operation | Description |
|---|---|
| lookupAutoReceiveStore | Retrieves all stores that allow auto-receiving of inventory from the input store. |
| lookupAssociatedStore | Retrieves all stores that are associated to the input store. They are sometimes called buddy stores. |
| lookupStoresInTransferZone | Retrieves all stores in the same transfer zone as the input store. |
| readStoreDetail | Retrieves the detailed information about a single store from the input unique reference. |
Standard Usage
The Store web service is used to retrieve information about stores. There are no updates. They are used to determine such information as whether or not you can ship to certain stores (such as those in transfer zones).
The following operations are available within the StoreFulfillmentOrder web service.
| Operation | Description |
|---|---|
| lookuFulfillmentOrdersHeaders | Retrieves summary information for fulfillment orders that match the search criteria input. |
| readFulfillmentOrderDetail | Reads the complete detailed information about a fulfillment order including items and quantities. |
| createFulfillmentOrderDetail | Creates a new fulfillment order with detailed information, including items and quantities. |
| cancelFulfillmentOrderDetail | Cancels quantities on a fulfillment order. This may cancel the entire order or just reduce or cancel quantities for specific items |
| rejectFulfillmentOrder | Rejects the fulfillment order indicating that the store will be unable to fulfill that particular order |
Standard Usage
Unlike some of the other web services, fulfillment order is not managed within EICS. Instead, EICs manages the picking and delivery, but the order itself is managed by an external order management system. Web services are supplied to find and read the details of a fulfillment order, but updates are not allowed. Instead, the external system use createFulfillmentOrderDetail to notify EICS of a new order to ship, cancelFulfillmentOrderDetail to reduce or cancel quantities (note that they cannot be increased), or call rejectFulfillmentOrder to notify EICS that the order has been rejected.
The following operations are available within the StoreInventory web service.
| Operation | Description |
|---|---|
| lookupAvailableInventory | Retrieves basic availability information for multiple items at multiple locations. Only transaction-levels items are processed (UPCs are not allowed) and only current inventory is returned. The service supports up to 200 items at 150 locations. |
| lookupAvailableInventoryAllStores | Retrieves basic availability information for a single item at all store locations. Only transaction-levels items are processed (UPCs are not allowed) and only current inventory is returned. |
| lookupInventoryInStore | Retrieves a broad set of inventory information for several items at several stores, broken down into various inventory groupings. |
| lookupInventoryInTransferZone | Retrieves a broad set of inventory information for items within the specific transfer zone, broken down into various inventory groupings. |
| lookupInventoryForBuddyStores | Retrieves a broad set of inventory information for associated or buddy stores, broken down into various inventory groupings. |
| lookupFutureInventory | Retrieves the future inventory information (such as inbound, ordered quantities and expected dates) for an item and store location. |
| lookupAvailableInventoryAllWarehouses | Retrieves inventory information for a single item at multiple warehouses. Only transaction-level items are processed and only current inventory is returned. |
Standard Usage
The StoreInventory is meant to retrieve inventory position information. Available inventory lookups are much smaller and quicker to respond than full inventory lookups. Future inventory is separated from current positions as it is much more time consuming to retrieve. Those who access the web services should give consideration to the purpose before choosing which operation to use.
The following operations are available within the StoreInventoryUIN web service.
| Operation | Description |
|---|---|
| createUIN | Create a new UIN without changing store inventory. |
| generateUIN | Generate new UINs without changing store inventory. |
| readUINDetail | Returns details about a UIN in store inventory. A UIN reference is not unique, so this may return detailed information for UINs across multiple items. |
| updateUIN | Updates an existing UIN without changing store inventory. |
Standard Usage
This web service is used to create, generate, update or read UIN in store inventory.
The following operations are available within the StoreItem web service.
| Operation | Description |
|---|---|
| lookupItemHeaderByItem | Retrieves list of summary information about an item that match the item-based search criteria input. |
| lookupItemHeaderBySource | Retrieves list of summary information about an item that match the source or location-based search criteria input. |
| lookupItemHeaderByUDA | Retrieves list of summary information about an item that match the UDA (User Defined Attribute)-based search criteria input. |
| lookupItemHeaderByInventory | Retrieves list of summary information about an item that match the inventory-based search criteria input. |
| lookupItemCfa | Retrieve a list of custom flexible attributes for the specified item and store. |
| lookupItemUda | Retrieve a list of user defined attributes for the specified item and store. |
| readItemDetail | Retrieves the complete detailed information a single item based on its unique reference. |
| lookupRelatedItem | Retrieves a list of summary information about items related to the item used as input criteria. |
| saveItemImage | Inserts a new display image or QR code image for the specified item. The service returns immediately and the information is processed asynchronously. |
Standard Usage
This web service is used to find items and retrieve information about items. The only exception is the ability to create new image-based information about an item.
The following operations are available within the StoreItemPrice web service.
| Operation | Description |
|---|---|
| lookupItemPriceHeader | Retrieve a summary list of item price information based on input criteria. This only retrieves information known to EICS and has no access to a pricing system. |
| readItemPrice | Retrieves the full details a single item price record based on its unique reference. |
| lookupItemPriceOnEffectiveDate | Retrieves the item price of an item for a specific date. |
Standard Usage
This web service is used to retrieve information about prices that are known to EICS. Integration with pricing systems updates EICS information about item prices on a continual basis. These web services give a view into EICS information only.
The following operations are available within the StoreNotification web service.
| Operation | Description |
|---|---|
| createNotification | Creates a new notification within the system. These notifications are displayed in the client applications. |
Standard Usage
This web service is designed for external system that handle related activities to EICS. With this web service, they can send notifications into EICS of activity that needs to take place based on something that has occurred in another system.
The following operations are available within the StoreTransfer web service.
| Operation | Description |
|---|---|
| lookupTransferHeader | Retrieve a summary list of transfers that matches the input criteria. |
| lookupTransferContext | Retrieves all the transfer context options available to assign to a transfer. |
| readTransfer | Retrieves the detailed information about transfer, including its items and quantities, based on a unique reference. |
| createTransferRequest | Creates a brand new transfer request (Location 1 requesting a transfer from Location 2). |
| saveTransferRequest | Updates a transfer request allowing user to change items and quantities. This must be done prior to requesting it, which finalizes the transfer request. This requires an activity lock. |
| createTransfer | Generates a new transfer that you can add details to. The saveTransfer method must be used to update details such as items and quantities of the transfer. |
| saveTransfer | Updates a previously approved transfer item and quantity details. This operation requires an activity lock. |
| saveTransferApproval | Updates items and quantities on a transfer in requested status that is currently in the process of being approved, but has not yet been approved. This operation requires an activity lock. |
| requestTransfer | Updates the status to Requested, finally the transfer request. This allows the opposite location to view the new request for transfer of goods. This operation requires an activity lock. |
| approveTransfer | Approves a transfer request converted the transfer request into an approved transfer. This operation requires having an activity lock. |
| rejectTransfer | Rejects a transfer in request status which prevents the transfer request from becoming a transfer. This operations requires having an activity lock. |
| cancelTransfer | Cancels an approved transfer. This operations requires having an activity lock. |
| closeTransfer | Closes a processed or partially processed transfer finalizing the state of the transfer. This operations requires having an activity lock. |
Standard Usage
The process is started by one store creating a transfer request from a shipping store using createTransferRequest. The requesting store can continue modifying the transfer request using aveTransferRequest until it is ready to notify the shipping store, when it then uses the requestTransfer to the shipping store. The shipping store can then begin picking items for the transfer and updating the transfer using the saveTransferApproval operation. When all the quantities the shipping store are willing to ship are determined, the shipping store uses approveTransfer to finalize the approval of the transfer. Alternatively, they can choose to reject the transfer using rejectTransfer. It is possible for a shipping store to create a transfer document without going through the request and approval process by using createTransfer and saveTransfer.
The following operations are available within the TransferDelivery web service.
| Operation | Description |
|---|---|
| lookupTransferDeliveryHeaders | Retrieves basic information about one or more transfer deliveries that match the criteria specified. This operation is used to find a delivery arriving at the store. |
| readTransferDeliveryDetail | Retrieves the entire set of information about a transfer delivery header based on the identifier you pass to it. |
| updateTransferDelivery | Updates the header information on a transfer delivery. This operation requires an activity lock. |
| receiveTransferDelivery | Receives all the currently open and active containers on a transfer delivery by defaulting quantities into all the unreceived items. This does not move inventory, only defaults quantities. This operation requires an activity lock. |
| confirmTransferDelivery | Confirms a transfer delivery actually receiving the goods into inventory and updating all the inventory positions. This moves the transfer delivery to a completed status. This operation requires an activity lock. |
| lookupTransferDeliveryContainerHeaders | Retrieves summary information about every container on a transfer delivery based on the unique delivery reference. |
| readTransferDeliveryContainerDetail | Reads the entire details of a container including items and quantities based on a unique container reference. |
| createTransferDeliveryContainer | Generates a new container on the transfer delivery and returns a reference to use so that items and quantity can be added later. |
| updateTransferDeliveryContainer | Updates the items and quantities on a transfer delivery container. This operation requires an activity lock. |
| receiveandConfirmTransferDeliveryContainer | It first defaults receiving quantity on the items within the container and then executes the same locking as the confirmTransferDeliveryContainer. This operation requires an activity lock. |
| confirmTransferDeliveryContainer | Confirms a transfer delivery container as received and updates all the inventory positions. This operation requires an activity lock. |
| cancelTranferDeliveryContainer | Cancels a transfer delivery container moving it to missing status. Changes cannot be made to a canceled container. |
| openTransferDeliveryContainer | Re-opens an already confirmed container moving it back into in-progress status. |
| lookupTransferDeliveryOrders | Retrieves any customer orders associated with the transfer delivery based on the delivery's unique reference. |
| lookupMisdirected
TransferDeliveryContainers |
Retrieves summary information about containers that may have been misdirected based on a set of search criteria as input into the operation. |
Standard Usage
After reading a transfer delivery using lookupTransferDeliveryHeader, you can read the header detail with readTransferDelivery or container list with lookupTransferDeliveryContainers. You can then use updateTransferDelivery to update header attributes and updateTransferDeliveryContainer to update items and quantities in the container. To quickly receive the quantities, receiveTransferDeliveryContainer automatically fills in quantities, and when quantities are entered confirmTransferDeliveryContainer finalizes the container (and if appropriate configurations and business rules apply) immediately updates the inventory. If receiveTransferDelivery or confirmTransferDelivery is used, then all containers will either be received or confirmed respectively.
The following operations are available within the TransferShipment web service.
| Operation | Description |
|---|---|
| lookupTransferShipmentHeader | Retrieves basic information about one or more transfer shipments that match the criteria specified. This operation is used to find a shipment. |
| readTransferShipmentDetail | Retrieves the entire set of information about a transfer shipment header based on a unique reference. |
| createTransferShipment | Creates a new and empty transfer shipment and returns a reference to the shipment. |
| saveTransferShipment | Updates the information on a transfer shipment header. |
| submitTransferShipment | Submits the transfer shipment for review before final dispatch. |
| cancelSubmittedTransferShipment | Cancels the submission of the transfer shipment for review. |
| dispathTransferShipment | Dispatches a transfer shipment. This moves the shipment to dispatched state and updates the inventory. A transfer shipment cannot be modified after dispatch. Dispatch should occur only after all containers are confirmed. |
| cancelTransferShipment | Dispatches a transfer shipment. This moves the shipment to dispatched state and updates the inventory. A transfer shipment cannot be modified after dispatch. Dispatch should occur only after all containers are confirmed. |
| cancelTransferShipment | Cancels a transfer shipment. |
| lookupTransferShipmentContainer | Finds all the containers on a specific shipment and retrieves basic identification information about each container. |
| readTransferShipmentContainer | Reads the specific and complete contents of a container. |
| createTransferShipmentContainer | Creates a new transfer shipment container on the shipment and returns a reference to it. |
| saveTransferShipmentContainer | Updates the information about a transfer shipment container including adding and removing items and quantities. |
| confirmTransferShipmentContainer | Confirms that a transfer shipment container is ready for shipment and marks the container as no longer editable. |
| cancelTransferShipmentContainer | Cancels a transfer shipment container on the shipment. |
| openTransferShipmentContainer | Re-opens a confirmed container on a shipment prior to the shipment being dispatched so that changes can be made to the container. |
Standard Usage
To create a shipment for a transfer document, you lookup the transfer shipment using lookupTransferShipmentHeader. If it does not exist, you could create one for the document using createTransferShipment. You then create a container on the shipment using createTransferShipmentContainer. You can update the container with items and quantities using saveTransferShipmentContainer. You then confirm the container using confirmTransferShipmentContainer. Repeat the process for each container as needed. Once all containers are confirmed, you submit if configured using submitTransferShipment and finally dispatch the shipment using dispatchTransferShipment. Dispatching the shipment finalizes the shipment and relieves the inventory.
The following operations are available within the VendorDelivery web service.
| Operation | Description |
|---|---|
| lookupVendorDeliveryHeaders | Retrieves basic information about one or more vendor deliveries that match the criteria specified. This operation is used to find a delivery from a supplier. |
| lookupPurchaseOrderHeaders | Retrieves basic information about one or more purchase orders that match the criteria specified. |
| readVendorDeliveryDetail | Retrieves the entire set of information about a vendor delivery header based on a unique reference. |
| createVendorDelivery | Generate a new vendor delivery heaver and returns a referenced to the delivery. |
| updateVendorDelivery | Updates the information on a vendor delivery header. This does not include containers, items, or quantities. This operation requires an activity lock. |
| receiveVendorDelivery | Updates the quantities on a vendor delivery filling in any unreceived items within the containers of the delivery with a default value. It "receives" missing quantities but no inventory positions are updated. This operation requires an activity lock. |
| confirmVendorDelivery | Confirms the vendor delivery updating inventory positions and completing the delivery. This operation requires an activity lock. |
| rejectVendorDelivery | Rejects the vendor delivery placing it in rejected status. This operation requires an activity lock. |
| cancelVendorDelivery | Cancels the vendor delivery placing it in canceled status. This operation requires an activity lock. |
| lookupVendorDeliveryContainerHeaders | Retrieves summary information about every container on a vendor delivery based on the unique delivery reference. |
| readVendorDeliveryContainerDetail | Reads the entire details of a container including items and quantities based on a unique container reference. |
| createVendorDeliveryContainer | Generates a new container on the vendor delivery and returns a reference to use so that items and quantity can be added later. |
| updateVendorDeliveryContainer | Updates the items and quantities on a vendor delivery container. This operation requires an activity lock. |
| confirmVendorDeliveryContainer | Confirms a vendor delivery container as received and updates all the inventory positions. This operation requires an activity lock. |
| cancelVendorDeliveryContainer | Cancels a vendor delivery container moving it to missing status. Changes cannot be made to a canceled container. |
| openVendorDeliveryContainer | Open Vendor delivery container. This will re-open a container after receipt allowing it to be received again. |
| lookupVendorDeliveryOrders | Retrieves any customer orders associated with the vendor delivery based on the delivery's unique reference. |
| lookupVendorDeliveryAdjustments | Retrieves any external receipt adjustments that exist for the delivery based on the specified unique reference. |
| cancelSubmitVendorDeliveryContainer | Opens a submitted container for further updates, moving the status to in-progress. |
| submitVendorDeliveryContainer | Moves the status of the container to submitted and prevents further updates. The container may still be confirmed. No inventory positions are updated via this operation. |
Standard Usage
After reading a vendor delivery using lookupVendorDeliveryHeader, you can read the header detail with readVendorDelivery or container list with lookupVendorDeliveryContainers. You can then use updateVendorDelivery to update header attributes and updateVendorDeliveryContainer to update items and quantities in the container. To quickly receive the quantities, receiveVendorDeliveryContainer automatically fills in quantities, and when quantities are entered confirmVendorDeliveryContainer finalizes the container (and if appropriate configurations and business rules apply) immediately updates the inventory. If receiveVendorDelivery or confirmVendorDelivery is used, then all containers will either be received or confirmed respectively. You can re-open container using openVendorDeliveryContainer. To prevent further updates to the container can use submitVendorDeliveryContainer. Submitted container can be re-opened and moved to in-progress status for further updates using cancelSubmitVendorDeliveryContainer.
The following operations are available within the VendorReturn web service.
| Operation | Description |
|---|---|
| lookupVendorReturnHeader | Retrieves basic information about one or more vendor return documents that match the criteria specified. |
| readVendorReturnDetail | Retrieves the entire set of information about a vendor return, including items and quantities, based on a unique reference. |
| saveVendorReturn | Updates the entire set of information about a vendor return, including items and quantities. This operation requires an activity lock. |
| approveVendorReturn | This marks an in-progress vendor return as approve for shipment. This operation requires an activity lock. |
| cancelVendorReturn | Cancels a vendor return indicating no further items and quantities should be shipped for the return. |
| closeVendorReturn | Closes a vendor return document moving it from in-progress to canceled, rejected, or complete status depending on the state of shipped quantities. |
Standard Usage
The user may access lookupVendorReturnHeader to find vendor returns to deal with. Once the proper vendor return is found, readVendorReturnDetail will retrieve all the details of the vendor return including items and quantities. The saveVendorReturn operation is then used to update quantities that are expected to ship. Once the vendor return reaches its final state, the operation approveVendorReturn will approve the return and get it ready for shipment.
The following operations are available within the VendorShipment web service.
| Operation | Description |
|---|---|
| lookupVendorShipmentHeaders | Retrieves basic information about one or more vendor shipment headers that match the criteria specified. |
| lookupReturnContext | Retrieves all the context options that are available to assign to a vendor return shipment. |
| readVendorShipmentDetail | Retrieves the detailed information about a vendor return header based on a unique reference. It does not include information about containers or items. |
| saveVendorShipment | Creates a new vendor shipment header if not identifying reference is set, or updates the vendor shipment header information if a unique reference is sent as part of the date. When used as an update, an activity lock is needed. |
| submitVendorShipment | Submits the vendor shipment for review before final dispatch. |
| cancelVendorShipmentSubmission | Cancels the submission of the vendor shipment for review. |
| cancelVendorShipment | Cancels a vendor shipment. This moves the shipment to canceled status. Changes cannot be made to a canceled shipment. |
| dispatchVendorShipment | Dispatches a vendor shipment. This moves the shipment to dispatched state and updates the inventory. A vendor shipment cannot be modified after dispatch. Dispatch should occur only after all containers are confirmed. This operation requires an activity lock. |
| closeVendorShipment | Closes a vendor shipment using business logic to determine its final state. It cancels the shipment of remaining quantities. Changes cannot be made after a shipment is closed. |
| lookupVendorShipmentContainerHeaders | Retrieves summary information about all containers within a vendor shipment based on the unique reference of the shipment. |
| readVendorShipment
ContainerDetail |
Reads the specific details, including items and quantities, about a container specified by its unique reference. |
| saveVendorShipmentContainer | Update the details of a container, including items and quantities. This operation requires an activity lock. |
| confirmVendorShipmentContainer | Confirms that the container is ready for shipment. A confirmed container cannot be modified. This operation requires an activity lock. |
| cancelVendorShipmentContainer | Cancels a container on the shipment removing it from the shipment. |
| openVendorShipmentContainer | Opens a confirmed container placing it back into in-progress status so that items can be added or removed from the container. |
Standard Usage
To create a shipment for a vendor return document, you lookup the vendor shipment using lookupVendorShipmentHeader. If it does not exist, you could create one using createVendorShipment. You then create a container on the shipment using createVendorShipmentContainer. You can update the container with items and quantities using saveVendorShipmentContainer. You then confirm the container using confirmVendorShipmentContainer. Repeat the process for each container as needed. Once all containers are confirmed, you submit if configured using submitVendorShipment and finally dispatch the shipment using dispatchVendorShipment. Dispatching the shipment finalizes the shipment and relieves the inventory.
Full web service API documentation can be found at: [This spot should contain the correct official terminology that points to Retail Reference Architecture > Enterprise Integration Guide > Retail Service Backbone > RSB Service Summary
EICS integrates with POS systems and Sales Audit systems to ensure that the inventory positions are accurate. This is especially important where accurate up-to-date inventory positions are required to reduce customer disappointment when trying to locate items that appear in inventory or delays in filling customer orders. POS is the primary source of sales, returns, void, and some customer order transaction information to EICS. ReSA sends only modified or new POS transaction records to EICS.
POS systems integrated with EICS can do the transaction notifications using a web service. Sales Audit systems can only communicate through a file import process.
The following features are part of this integration:
Real-time web service integration
Batch integration
Audited sales data integration
Automatic disposition processing for returns
Batch processing and ReSA processing are discussed elsewhere as are the store and system configurations that might determine how the sale is processes.
The following figure shows how a POS, such as Xstore Point of Service, Retail Sales Audit, and EICS are integrated. A POS generates an RTLog containing all the POS transactions and sends it to the Oracle Retail Sales Audit system (ReSA). ReSA sends the audited modified or new transactions to EICS. ReSA also sends the POS transaction upload file to merchandising to update inventory. Xstore is interfaced with EICS to update the inventory transactions near real time through a web service. Other POS systems can also use a batch to import transactions directly into EICS. EICS also processes the POS transactions that have been changed or entered into the sales audit system and updates the inventory based on the delta.
There are two reasons for POS to send sales data directly to EICS and not to the auditing system:
Real-time inventory updates to support Commerce Anywhere are critical. A possible round trip from POS to ReSA to EICS takes too long in the dynamic inventory environment of today.
POS is the application that owns sales data and ReSA owns audited data. Architecturally, it makes more sense to have data supplied by the owner of that data. POS sends sales data and ReSA sends audit changes to EICS.
As part of the sales processing, EICS updates the inventory depending on the nature of the transaction. The following are the supported transaction types for the sales processing: Sale, Return, and Post Void of these transactions. The audit system should not modify the post void transactions. A change to a void is not supported by EICS.
In EICS, the Retail Sales Audit import process, POS Transaction import process, and POS Transaction web service process support the following types of customer orders.
For layaway and on hold, EICS supports create, update, cancel, and pickup/delivery. For external web order type, only pickup transactions performed in POS are sent to EICS.
Pickup transactions, both in-store and external, cannot be voided or modified by sales audit and if these transactions are modified by sales audit system, EICS just drops the transaction and does not process.
|
Note: Current Xstore functionality is limited to only layaway and on hold orders. Web order processing is not supported in this release. |
When the Enable Item Disposition in the Transaction Update store admin parameter is turned on, POS has the opportunity to move inventory for return and post void transactions to 'unavailable' or 'out of stock'. This is especially useful in some environments where items returned have to be disposed of or have to be reprocessed.
The external sale transaction coming into EICS may include a reason code that is mapped to the inventory adjustment reason codes in EICS. Point of Service maps the EICS reason codes, and the reason codes are sent to EICS in the web service or file extract for the return and post void transactions. EICS first processes the return or post void and updates stock on hand. Next, if the indicator is set and a reason code exists, EICS checks this reason code with the one in inventory adjustment reason code table. If a valid match is found, EICS generates an inventory adjustment to notify external systems and execute the disposition instructions tied to the inventory adjustment reason code. Based on the disposition mapped to the reason code, EICS moves the returned inventory to not for sale or out of stock and updates the history trail. If sub-buckets are used, they are also updated if the movement is to not for sale.
If the reason code received is invalid/not present/mapped incorrectly, the system writes an error log and continues to process the stock on hand part of the transaction.
The second method is controlled through the sales process. The sales transaction information can contain a wastage percentage for variable unit of measure items. If that is not present on the sales transaction coming in, EICS looks up the wastage percentage and uses that for inventory reduction beyond the sale.
When the sales records indicate the record is a drop ship, EICS does not perform any processing of this record since the drop ship process implies the inventory is shipped from a third-party location and not from the store.
EICS only processes SKU or UPC numbers. GS1 databars, or any other smart barcodes such as VPLUs or Type-E barcodes, should have been extracted to their SKU or UPC number by the POS system.
In addition, EICS only updates inventory for stock holding items. Non-inventory items do not update any stock on hand and are not processed.
Items with the store pack inventory indicator turned off are automatically broken down and the inventory of the component items is updated.
In order for access to a an external manifesting system to take place, the customer must first setup Carrier Type as "Third Party" and the Carrier Service (Manifest Type) must be Parcel (P). Configuration controls whether manifesting is done for a transfer to store, finisher, or warehouse. In addition, configuration controls manifesting for a return to vendor shipment or a customer order delivery.
Carrier services with manifest type of "O" (Other) and "H" (Home Fleet) do not go through the manifesting system. When Manifest Type is "O," EICS prompts the user to enter the carrier address where the shipment is to be sent for fulfillment. Manifest Type of "H" is within the company and therefore, does not prompt the user for an address.
Some carriers require weight, dimension, or both values to be sent in the manifest payload. If so, the carrier's service should have either the weight indicator or carton dimension indicate set to active (or both) during their carrier service setup.
EICS supplies an outbound and inbound Shipment Manifest SOAP web service. The following are supported service operations:
A web service is used to send all the shipment information to the external manifesting system and also to receive close shipment requests from external systems.
A web service accepts requests from external systems to close shipments. It is used to find those "Submitted" shipments for the provided tracking ID, carrier, service and date, and dispatch those shipments.
|
Note: EICS supplies a WSDL and XSD that defines the web service, operation, and data content. This web service will need to be implemented either for the manifesting system or a plug-in set up. |
ShipmentManifestService
This web service notifies an external manifesting system that a manifest needs to be created.
| Service Operation | Description |
|---|---|
| createManifest | Requests the external manifesting system to create a new parcel manifest for an input transaction. |
StoreShipmentManifestService
This web service receives a message from an external manifesting system that the items on the manifest have been picked up.
| Service Operation | Description |
|---|---|
| closeManifest | Instructs EICS that submitted shipments have been picked up by the carrier. |
When shipping to customer during the fulfillment order workflow, EICS retrieves the address for the order delivery from an external order managements system. When viewing delivery address information within the client application, it also retrieves it from an external system. The web service is defined to connect to an OrderManagementService.
CustomerOrderAddressService
| Service Operation | Description |
|---|---|
| queryCustomerOrderAddress | Retrieves detailed address information for the order and customer information passed to it. |
