Orders vs payments

This page explains what orders are and how they are different from payments

This page explains how Orders work and has the following sections:

Orders vs payments

On the Accounts page we saw that payments are linked to Orders. In this page we will explain what Orders are.

Expenses, supplier payments, subscriptions and disbursements are all Orders in Yordex. Orders can have more than one payment. For example, subscriptions or orders with partial payments have more than one payment.

In addition to payment details, orders also contain other information. For example they contain a link to the supplier (trader), approvals, receipts, categorisations and, if provided, line item details

The table below summarises the difference between Orders and payments in Yordex.

Orders

payments

APIs

POST /orders
GET /orders
PUT /orders/:id

GET /reports/yordexpay

Represents

Expenses, subscriptions, supplier payments, disbursements and any other payment type you need

Card payment, bank transfer or card top up

Contains

Payments, supplier, approvals, payment terms, invoices/receipts, line item details, categorisation and different statuses

Payment details

As you can see from the table, it is not possible to create a payment directly. All payments are either created by cards or orders. To pay out to someone you can either

  • Give them a card and top up the card
  • Create an order linked to a card and the order will top up the card
  • Create an order that will trigger a bank transfer (same tutorial)

Order lifecycle

An Order has one or multiple Events. Every event represents a payment. The difference between an Event and a payment are:

  • Events are created before the payment is made allowing the payment to be pre-approved
  • Invoices or receipts are linked to Events, not to payments

Event approval is separate from Order approval. Typically an Order approval indicates that the purchase can be made while the Event approval indicates that the goods or services were delivered so the payment can be made.

Orders and Events therefore each have their own statuses that are separate but linked:

  • An Order is only COMPLETED when all Events are COMPLETED
  • Only one Event can be 'active' at a time: an event will remain NOT_STARTED until the event before it is COMPLETED
  • The Order has to be APPROVED before the first event becomes active. It is however possible to amend an order (temporarily move it back to NOT_APPROVED for editing) when Events are still active

An order lifecycle can be summarised like this:

To illustrate this process, here is a workflow an Order with two Events could go through:

At the start, the statuses will be as follows:

  • Order: NOT_APPROVED
  • Event 1: NOT_STARTED
  • Event 2: NOT_STARTED

Once the order is approved and the first event is for confirmation, the statuses will be as follows:

  • Order: APPROVED
  • Event 1: FOR_CONFIRMATION
  • Event 2: NOT_STARTED

Once the first event is completed and the second event is for confirmation, the statuses will be as follows:

  • Order: APPROVED
  • Event 1: COMPLETED
  • Event 2: FOR_CONFIRMATION

If you amend an order that was already in progress, the statuses will be as follows:

  • Order: NOT_APPROVED
  • Event 1: COMPLETED
  • Event 2: FOR_CONFIRMATION

The order state goes back to NOT_APPROVED and the order has to be approved again, but the event states do not change throughout this process.

Once all events are completed, the statuses will be as follows:

  • Order: COMPLETED
  • Event 1: COMPLETED
  • Event 2: COMPLETED