Retail Order Management

Retail Order Management provides clients with a reliable and scalable Platform-as-a-Service model. Clients can manage orders from multiple brands, sites, and customer touch points. It optimizes order distribution by determining the most efficient source for order fulfillment. And it includes an extensive set of reporting/business intelligence capabilities. Optional modules include store fulfillment and payments.

This solution provides tight orchestration across the entire technology value chain, spanning several key areas: distributed order management, omnichannel inventory management, and reporting. Retail Order Management is design to serve either as a part of an integrated commerce solution, or as a standalone solution integrated with third party storefronts.

Retail Order Management provides a powerful foundation for omnichannel success. Learn more: Retail Order Management.

Integration Architecture

The architecture underlying access to Retail Order Management is a combination of real-time web services, with periodic data file transfers for larger volumes of product, and fulfillment records, as well as for integrations into third-party systems. This combination allows the highest possible performance to the system overall while balancing the need for up-to-date information and actions.

Included Capabilities

Each client of the Retail Order Management API integration has the opportunity to take advantage of the following capabilities:

Function Integration Capable with Retail Order Management
Order Management Standard
Payment Processing Standard (Marketplace orders are paid through the marketplace.)
Tax / Duties Calculation Standard
FulFillment Standard (Using our fulfillment services or 3rd-party fulfillment.)
Inventory Management Standard
Consumer Transactional Emails Standard (Order-based transactional e-mails provided by eDialog integration adhere to any terms, conditions and fees agreed to outside Retail Order Management.)
Customer Service Standard (When using our customer service tools, service rates may apply.)
Address Validation Standard
Store Reporting Standard – Reporting documentation for available reports and reporting self-service functionality available outside of this document.

Web Service Layer Architecture

The Retail Order Management web service layer provides the ability for remote software applications to execute e-commerce operations via the public Internet using the availability and domain expertise of Retail Order Management. The web service layer provides:

  • 24/7 availability
  • On-demand access to e-commerce operations
  • A common XML interface
  • Secure access to Retail Order Management

The web service layer is comprised of a series of discrete services organized by subject area. The entry point to these services is the Public API that exists behind the API Security Layer.

Client applications send XML messages via the https (secure http protocol) to defined URI locations utilizing a REST-compliant techniques and receive XML responses to those requests.

All service integrations are accomplished via web service calls from the client system to Retail Order Management. Acknowledgements and error handling are supported and documented within each of the underlying services. Each service is represented as a series of .xsd files along with an accompanying URI structure.

The design of the Retail Order Management services provide:

  • Access to e-commerce functions in a simple, easy to understand interface.
  • Secure calls with no sensitive or secret information exposed in HTTP access logs.
  • A descriptive URI structure to enable detailed analytics capabilities.

In order to achieve these capabilities, Retail Order Management service integrations employ a RESTful URI structure, but use only POST actions. This structure provides a consistent interaction while maintaining security and functionality.

Schemas

The Retail Order Management service schemas are all combined under a single namespace. Whenever possible, they use a common set of types. This reduces the overall variability of parameters within each service call and allows for a cleaner and simpler implementation.

The individual schema file names follow the conventions outlined in each of the respective sections corresponding to the appropriate URI calls, along with the additional type files.