Revision

Date

Description

To be announced

Added extra information authorisation: “Basic ”||"Base64 encoding of username and password joined by a single colon : "

Media Order B2C: Yaml file version 1.3.0. Changelog version 1.2.0 to version 1.3.0:

  • Add Article with ArticleId as product identification for dedicated stock

  • Use either EAN or Article in placeOrder (EAN is now optional), if both are supplied the EAN is used and Article is ignored

  • Report either EAN or Article in getOrderStatus based on provided input in placeOrder

MediaShipment: Yaml file version 1.0.0 version 1.1.0. Changelog version 1.0.0 to version 1.1.0:

  • Add ArticleId as product identification for dedicated stock

  • Report either EAN or ArticleId in getShippingUnit based on provided input in placeOrder

Test and order simulation added

Add Tag matrix for Green and Standard option

Update yaml file MediaOrderNotify v.1.0.2.yaml

Update generic error messages

Align with updated order notifications

Update yaml file MediaOrderB2C v1.2.0.yaml

Update MediaOrderB2C version

Correct resource for notifyOrder and notityShipment

Update yaml versions

Add volume limits and error messages; Correct typo in process flow diagrams

Add flows and sequence diagrams

Add operations

Initial document

Introduction

This document contains a description of the standard interfaces for implementation of data exchange with CB via webservices.

Tag matrix for Green and Standard option

CB has two options for submitting e-commerce orders:

  • Green option no document attached to shipment

  • Standard option packing slip or invoice included with shipment

The entire set for the standard data exchange with CB consists of the following documents and files:

File versus webservice. Communication about orders is based on the receiving channel, i.e. file base communication is used for orders received via file based interfaces and webservice communication is used for orders received via the webservice MediaOrderB2C. Order are processed independent from the receiving channel

Mapping berichten naar webservices B2C.xlsx

The mapping from file based to webservice based messages

File based

Webservice operation

OPDNAW

placeOrder

ANNOPD

cancelOrder

UITOPD

notifyOrder / getOrderStatus + notifyShipment / getShippingUnit

NUITOP

notifyOrder / getOrderStatus

Authentication & Authorisation

MediaOrderB2C
S.v.p. checken en voorbeeld doorgeven

Basic - username:password   “Basic ”||"Base64 encoding of username and password joined by a single colon : "

Webservice information

Webservice approache

REST - Representational State Transfer

MediaOrderB2C

Definition

Resource

Orders

Operations provided by CB:

placeOrder

Send one (1) order to CB

cancelOrderLine

Cancel one (1) orderline

getOrderStatus

Retrieve the status if one (1) order

MediaOrderNotify

Definition:  is dit nog wel de juiste yaml versie?

MediaOrderNotify v1.0.2.yaml

Resource: 

Notifications

Operations provided by you:

notifyOrder

CB calls your webservice to inform you about status updates of an order

Authentication mode

CB supports:

  • Basic - username:password   “Basic ”||"Base64 encoding of username and password joined by a single colon : "

  • Token 

MediaShipment

Definition

Resource

ShippingUnits

Operations provided by CB:

getShippingUnit

Retrieve the shipment information for a shipping unit

MediaShipmentNotify

Definition:  is dit nog wel de juiste yaml versie?

MediaShipmentNotify v1.0.0.yaml

Resource: 

Notifications

Operations provided by you:

notifyOrder

CB calls your webservice to inform you about shipment for your order

Authentication mode

CB supports:

  • Basic - username:password   “Basic ”||"Base64 encoding of username and password joined by a single colon : "

  • Token 

Content type

The content /body in the request and response has to be, will be in json format

‘Optional’ parameter

For any optional Attribute ons of th following options applies:

  • be filled with the correct value

  • be left out

  • be filled with ““ (read empty)

An optional parameter may therefore never be filled with the value null

URL Test

Healthcheck niet opgenomen

MediaOrderB2C base: https://media.tst.cb-api.nl/mediaorderb2c

  • /v2/orders

  • /v2/orders/{OrderId}/status

  • /v2/orders/{OrderId}/orderlines/{OrderLineId}

MediaShipment base:  https://media.tst.cb-api.nl/mediashipment

  • /v2/shippingunit/{ShippingUnitId}

URL Production

Healthcheck niet opgenomen

MediaOrderB2C base: https://media.cb-api.nl/mediaorderb2c

  • /v2/orders

  • /v2/orders/{OrderId}/status

  • /v2/orders/{OrderId}/orderlines/{OrderLineId}

MediaShipment base: https://media.cb-api.nl/mediashipment

  • /v2/shippingunit/{ShippingUnitId}

Supported SSL/TLS protocols

TLS 1.2

TLS 1.3

Overview webservices

This chapter gives an overview of the available interaction patterns for data exchange with CB. The figure below gives an high level overview of the CB system landscape and the available webservice operations.

MoB2C_Overview_webservices.jpg

The webservices provide online creation and cancelation of media orders at CB. Changes to an order (other than cancel) are not available. Resending an order is possible only when the order was not accepted by CB earlier. 

Operations

Order - placeOrder

The operation placeOrder supports sending one order for a customer. An order can contain multiple orderlines, each for a specific title. Confirmation of the operation is provided with a http-response-code.

Check order identification (Requestor Order Id)

The identification of an order is used to check if an order already exists in the CB systems. If this is the case the new order is rejected. Only open orders are taken into account, so closed/cancelled orders are ignored.

Order type

The operation is available for order types ShipBuyer (LNAFN), ShipOwner (LNEIG) and ShipSecundaryOwner (LMEONE).

Sender and Owner

In the common scenario for media orders the sender requests CB to ship titles owned by a publisher to a consumer. This scenario identifies the publisher as owner, the sender (shop) as buyer from the owner and the consumer as receiver (and buying from the shop). An alternative scenario is secondary ownership, in this alternative scenario the sender (shop) already purchased titles from the publisher and requests CB to ship from its own stock.

Party

Because parties where goods have to be delivered are not known by CB the PartyType “ReceiverAddress,” is mandatory and all name and address information must be provided.

Values added services (VAS)

VAS activities can be controlled by means of special handling instructions for the order.

Examples of instructions:

Available special handling instructions must be agreed upon in advance by requestor and CB.

cancelOrderLine

The operation cancelOrderLine supports cancellation of one orderline. Cancellation is available until the orderline is released for production (“vrijgegeven”). Confirmation of the operation is provided with a http-response-code. The operation requires the OrderId and OrderLineId as input and is available for orders entered via webservices only.

getOrderStatus

When the status of an order or orderline is changed a notifyOrder message is sent. This is the preferred trigger to call the operation getOrderStatus.

The operation getOrderStatus provides the status summary of the requested order. An order can contain multiple orderlines, each for a specific product. The status of every orderline is reported separately. An orderline can also be reported in multiple statuses, for instance when part of the quantity is available and ready for production and the remaining quantity is in backorder. If (a part of) the order is not delivered, the status includes an explanation why.

The operation requires the OrderId as input and available for orders entered via webservices only.

Available statuses for notifyOrder:

Shipment - getShippingUnit

When a shipment is ready to be shipped a notifyShipment message is sent per available shipping unit. The operation getShippingUnit provides the contents of the shipping unit and the relation to order and orderlines. An order can be shipped in multiple shipping units.

The operation requires the ShippingUnitId as input.

Available statuses for notifyShipment:

Response messages

MediaOrderB2C

HTTP code

Error code

Description/Message

getOrderStatus

placeOrder

cancelOrderLine

200

Request executed

(tick)

204

Request executed

(tick)

(tick)

206

Request executed with pending status

(tick)

(tick)

400

Request failed

(tick)

(tick)

401

Not authorised

(tick)

(tick)

(tick)

404

Order not found

(tick)

(tick)

HTTP code

Error code

Description/Message
The list of error codes within these groups may change in time without notice

getOrderStatus

placeOrder

cancelOrderLine

CEP-***

CEP-002

The request does not comply with the yaml definition; Value is not one of the possible/allowed values

[instance value (\"1234567890\") not found in enum (possible values: [\"SecundaryOwnerStock\",\"SecundaryOrPrimary\",\"PrimaryOwnerStock\",\"PrimaryOrSecundary\"]), format attribute \"decimal\" not supported, format attribute \"int32\" not supported]

(tick)

CEP-002

The request does not comply with the yaml definition; Value does not meet regex

 [ECMA 262 regex \"^[^#]*$\" does not match input string \"#\", format attribute \"int32\" not supported]

(tick)

CEP-002

The request does not comply with the yaml definition; Value does not meet set minimum or maximum value

[numeric instance is lower than the required minimum (minimum: 6000000, found: 123), format attribute \"decimal\" not supported, format attribute \"int32\" not supported]

(tick)

CEP-003

Authentication/Authorisation error

You are not authenticated

(tick)

WMO-***

WMO-00503

The request encountered a mapping error, mainly due to incorrect shipment date(s); Delivery period and delivery date cannot both be given

If Delivery is specified, then either DeliveryDate or DeliveryPeriod must be supplied

(tick)

WMO-00508

The request encountered a mapping error, mainly due to incorrect shipment date(s); Date must be in the future

The DeliveryDate is in the past

(tick)

WMO-00509

The request encountered a mapping error, mainly due to incorrect shipment date(s); Invalid date

Invalid date for Delivery/DeliveryPeriod/Till: <Submitted ShipmentPeriod.Till> compared to Delivery/DeliveryPeriod/From <Submitted ShipmentPeriod.From> 

(tick)

WMO-00510

The request encountered a mapping error, mainly due to incorrect shipment date(s); Date must be in the future

The Delivery/DeliveryPeriod/From is in the past

(tick)

WMO-00511

The request encountered a mapping error, mainly due to incorrect shipment date(s); Date must be in the pastThe

The Delivery/DeliveryPeriod/Till is in the past

(tick)

HTTP code

Error code

Description/Message
The list of error codes within these groups may change in time without notice

getOrderStatus

placeOrder

cancelOrderLine

OMS-***

(tick)

OMS-01268

Order not found <OrderId>

(tick)

OMS-01342

Orderline was already cancelled

(tick)

OMS-01269

Unable to cancel order. Order already processed 

(tick)

OMS-01378

Crossdock orderline can not be cancelled

(tick)

OMS-01373

Unable to cancel orderline. Orderline already promoted to the Warehouse

(tick)

Process flows

This chapter contains the identified flows when using webservices to order physical books at CB. The most common and regular scenario is describes in the happy flow. In addition 7 frequent scenarios are described in alternative flows.

Happy flow

The customer orders one or more products, stock is available and the order is shipped in one shipment.

Process flow diagram Happy Flow v1 2 grootte aangepast.jpg

Flow description:

Alternative Flow 1 – multiple shipments

The customer orders multiple products and stock is available for all products. At pick and pack multiple shipping units are created. The order is shipped in multiple shipments.

Process flow diagram Alternative Flow 1- v1 2.jpg

Flow description:

Alternative Flow 2 – multiple shipments due to partial backorder

The customer orders multiple products and stock is available for at least one product. Also at least one product is in backorder. The order is shipped in multiple shipments.

Process flow diagram Alternative Flow 2 - v1 2.jpg

Flow description:

Alternative Flow 3 – customer cancellation

The customer orders one or more products, but decides to cancel the order shortly after ordering.

Process flow diagram Alternative Flow 3 - v 1 3.jpg

Flow description:

Alternative Flow 4 – partial customer cancellation

The customer orders multiple products, but decides to cancel at least one of the orderlines but not all shortly after ordering.

Process flow diagram Alternative Flow 4- v1 2.jpg

Flow description:

Alternative Flow 5 – CB order reject

The customer orders one or more products, but the order is not accepted by CB due to unknown products.

Flow description:

Alternative Flow 6 – partial CB cancellation

The customer orders multiple products and stock is available for at least one product. Also stock is not available for at least one product and backlog is not allowed.

Flow description:

Alternative Flow 7 – order during service window

The customer orders one or more products during the service window. Stock is available for all products.

Flow description:

Alternative Flow 8 – cancel during service window

The customer orders one or more products, but decides to cancel the order during the service window.

Flow description: