Order process

Swagger-UI: order-v1 | OpenAPI file: order-v1.yml

Table of contents

Overview

To actually order a connection on a location, one should first check whether a location actually has an orderable package. Use the Line availability API to determine that this is the case.

Once it is determined that the package and corresponding you want to order is available, your application should construct the JSON message for the order and submit it to the API endpoint. See the Order OpenAPI specification for the message format.

When the order has been submitted, an order ID will be returned which you need to register in your own system. This is important to query the order status and such during the run time of the order. See also Querying orders.

During the run time of the order, you’ll probably want to know the order status and plan date of an order. Currently, there is no system in place to call your system if any order events occur. At a later stage a webhook system will be introduced to inform your system about any changes in the order. Until then, you should periodically query running orders to retrieve status updates or use the portal.

Delivery of an order

After the order has been submitted, the system will handle the order process with the supplier of the connection. During the delivery of an order, the status of an order can change into one of the following statuses:

  • NEW: the order has been registered in the A2B system.
  • ACCEPTED: the order has been sent into the A2B backend system for further processing.
  • PLANNED: the telco has given a plan date (or execution date in case of a line migration) on which the new connection will be delivered.
  • COMPLETED: the connection has been delivered. This is a final order status.
  • ON_HOLD: a problem occurred during the delivery of the connection. This may or may not result in a rejection, depending on the situation.
  • REJECTED: the order has been rejected by the telco. The rejection reason can be retrieved by querying the order.
  • FAILED: the order could not be submitted to the backend system. This might happen when invalid order parameters were specified, or if mandatory order parameters were missing
  • CANCELLED: the order has been cancelled. Cancelling orders can happen on your own request.

Cancelling an order

In the unfortunate case that an end user declines the order after placing it, it might still be possible to cancel the running order. Whether an order can still be cancelled, depends on the following situations:

  • The plan date is at least 3 working days in the future.
  • The order has a running order status (NEW, ACCEPTED, PLANNED, ON_HOLD)

Cancelling an order may imply that you’ll be charged with a cancellation fee.

An order cancellation can be requested by sending a DELETE request to the API endpoint. See the Order OpenAPI specification for detailed information.

Replanning an order

In the order request, you have requested a wish date for a new connection. New connections can only be replanned by cancelling the running order and submitting a new order. Migration orders on the other hand can be replanned in the following situations:

  • The execution date (aka plan date) has not been reached.
  • For lines delivered via Reggefiber: the execution date is at least one working day in the future.
  • For lines delivered via KPN: the execution date is at least 3 working days in the future.
  • The migration order has a running order status.

The regular business rules apply for choosing a new execution date. This means that the new execution date will need to be at least 10 working days in the future for Reggefiber and KPN connections.

Replanning an order can be done by sending a PATCH request to the API endpoint. See the Order OpenAPI specification for detailed information.

Order rejection at intake

It may be possible that an order gets rejected immediately. This will happen in the following occasions:

  • An invalid package or product code has been specified.
  • An invalid combination of products has been specified. For example, the product code of an EVC was specified as a SLA product code.
  • An invalid format of the entered data.
  • Missing fields.

When such errors occur, the API will return an HTTP 400 status code along with a list of the validation errors and the fields they occurred in.