fulfillmenttools
API documentationIncident ManagementFeedback
Developer Docs
Developer Docs
  • Developer docs
  • Getting Started
    • Quickstart
    • Integration tutorial
      • Adding facilities
      • Adding listings to facilities
      • Configuring stocks
      • Carrier configuration
      • Placing orders
      • Checkout options
      • Distributed Order Management System (Routing)
      • Local fulfillment configuration
    • Free trial
  • Technical Basics
    • Access to fulfillmenttools
    • Feature status
    • Available regions
    • Backup policies
  • Connecting to fulfillmenttools
    • Client SDKs
    • commercetools connect
    • OpenID connect
      • Configure Microsoft Entra ID / Azure Active Directory
      • Configure Keycloak
  • API
    • Core concepts
      • Authentication & authorization
      • API Versioning & lifecycle
      • Assign user to jobs
      • Localization
      • Resource timestamps
      • Custom attributes
      • Article attributes
      • Recordable attributes
      • Data update guarantees
      • Rate limits & scaling
      • Retries
      • Performance on test vs. production systems
      • Load testing
    • API calls
      • Postman
      • cURL
      • GraphQL Explorer
    • GraphQL API
    • RESTful API
      • Pagination interface
      • RapiDoc
      • OpenAPI 3.0 Spec
    • Eventing
      • Structure of an event
      • Available events
        • Event flows
      • Eventing example
      • Event export
  • Integration Guides
    • Address formats for specific carriers
    • Basics
      • Article categories
      • Audits
      • Custom services & bundled line items
      • Facilities
      • Facility groups
      • GDPR configuration
      • Listings
      • Orders
        • Order types
        • Order status
      • Remote configuration
      • Receipts
      • Search
      • Subscribe to events
      • Sticker
      • Stocks
      • Storage locations
      • Tags
      • Users
    • Channel inventory
    • Facility discounts
    • Inbound process
    • Outbound stocks
    • Purchase order
    • Receipt
    • Routing strategy
    • Show sticker to clients
    • Stow jobs
  • More Integration Guides
    • Carrier management
      • Introduction to carrier configuration
      • Required data when operating carriers
      • Adding & connecting carriers to facilities
      • Custom carrier
    • Configurations for order fulfillment
      • Picking configuration
      • Packing configuration
      • Handover configuration
      • Printing and document configuration
      • Packing container types
      • Parcel tag configuration
      • Headless order fulfillment
      • Short-pick reasons
      • External documents in order fulfillment
      • Service jobs
      • Load units
      • Running sequence
    • DOMS - distributed order management system (routing)
    • External actions
    • Interfacility transfer
    • Notifications
    • Availability & promising
    • Returns
Powered by GitBook
On this page
  • General Process Description
  • Process Statuses Calculation Flow
  • Description of Different Status
  • Preface
  • lastDomainEntityStatuses
  • domainStatuses
  • domsStatus & operativeStatus
  • status
  • returnStatus
Edit on GitHub
  1. Integration Guides
  2. Basics
  3. Orders

Order status

Last updated 1 day ago

General Process Description

A process is the link between entities on our platform. Every order, pick job, handover job etc., references one process, and every process keeps the IDs of its entities. Furthermore, the process houses the different status of the different domains, modules, and entities. The detailed process documentation can be found in our .

Important note

The expression domain for the fields in the process class is not correct. Correct is module instead of domain. This will be fixed in the future.

Some fields of the process class:

{
    "id": "111-222-333",
    // ...
    "pickJobRefs": [],
    "handoverJobRefs": [],
    // ...
    "status": "CREATED",
    "domsStatus": "CREATED",
    "returnStatus": "NOT_AVAILABLE",
    "operativeStatus": "CREATED",
    "domainStatuses": [
        "PICKING": "CREATED",
        // ...
    ],
    "lastDomainEntityStatuses": [
        {
            "domain": "PICKJOB",
            "status": "CREATED",
            "entityId": "123456789"
        },
        // ...
    ]
    // ...
}

Process Statuses Calculation Flow

The different status of the process are calculated depending on their predecessors. The start status is the lastDomainEntityStatuses (at the bottom in the image), with this the domainStatuses are calculated. domsStatus and operativeStatus are calculated from the domainStatuses. The final overall status based on domsStatus and operativeStatus.

Description of Different Status

Preface

Our platform contains different domains and modules. Every domain has multiple modules, and every module includes entities like a PickJob in the PICKING module or a RoutingPlan in the ROUTING module.

For the different Process-Status-Calculation, only the DOMS and LOCAL OPERATIONS modules are taken into account.

lastDomainEntityStatuses

Contains only the last status of every entity. An entity (e.g. RoutingPlan, PickJob or HandoverJob) status change in a module (e.g. PACKING or ORDER), will update the entry of the corresponding entity in this list.

Example JSON:

"lastDomainEntityStatuses": [
    {
        "domain": "ROUTING_PLAN",
        "status": "FINISHED",
        "entityId": "ROUTING-A-0000-1111"
    }, {
        "domain": "ROUTING_PLAN",
        "status": "FINISHED",
        "entityId": "ROUTING-B-0000-1111"
    }, {
        "domain": "PICKJOB",
        "status": "CREATED",
        "entityId": "PICK-A-2222-3333"
    },
    // ...
]

Because the noticed status in lastDomainEntityStatuses must be work with all entities from different modules, these saved status are NOT the original status that is defined in the module. The original status is mapped into one, which can be used across all modules.

domainStatuses

Contains module clean statuses that will be calculated from the module entities from the lastDomainEntityStatuses. For example, we have ONE status for PICKING or SHIPPING.

Example JSON:

"domainStatuses": [
    "ORDER": "FINISHED",
    "ROUTING_PLAN": "FINISHED",
    "PICKING": "CREATED",
    // ...
]

domsStatus & operativeStatus

Each of these two statuses contains a clear domain status. For the calculation of these two statuses, the associated module statuses from the domainStatuses list are taken.

status

This is the overall status, and it will be calculated with the two statuses domsStatus and operativeStatus.

returnStatus

This status tracks the progress of returns associated with this order. As long as no returns are in progress, this status will be NOT_AVAILABLE. Contrary to other process status like domsStatus or operativeStatus, the returnStatus does not influence the overall status of the process. This is because an order is counted as complete once all its items are shipped. If a return is issued later on, the progress should not be reopened. The process will remain CLOSED, only its returns will be IN_PROGRESS.

The overall status enum type is called DomainStatus and can be found in our .

The status enum type is the same like in lastDomainEntityStatuses, DomainStatus and can be found in our .

The status uses an enum type that is called ProcessStatus and can be found in our .

It uses the same enum type ProcessStatus like the two predecessor statuses. It can be found in our .

documentation
documentation
documentation
documentation
documentation
Drawing
Drawing