# Business

# Introduction

The business part of Zaikio's data model covers everything required to model the relationship between a buyer of printed products and the seller of these products.

In this overview about the business data model you will learn about:

  • Business data model object graph
  • Customers and responsible people
  • Addressing orders
  • Lifecycle of an order
  • Modifying confirmed orders
  • Relationship between orders and jobs

At the core of the data model lies the Order object which represents the business transaction. The goods that are ordered are represented within an order as LineItems.

A line item can simply be a free text description and some pricing information or it can reference a Zaikio Job.

Additionally, an order holds information about the PaymentTerms, such as time frame for payment, payment means hint, and addresses.

# Object graph

# Customers and responsible people

Every order has a single customer. This can either be a Zaikio Person or a Zaikio Organization. If a customer does not have a Zaikio account, you can fill out the customer_description attribute of the order in lieu of the customer relationship.

# Order addressing

When creating an Order you must assign an Address. This address is considered to be address an offer, order and order confirmation is made out to. This is not the billing nor the shipping address. You might supply an billing_address right when creating an order, and that address might very well be the same as the order's address, but doesn't need to be. If you don't know the billing_address you might omit it.

The shipping address or addresses of an order are handled in the Logistics part of Zaikio and are - like Jobs - only loosely coupled to an Order.

# The lifecycle of an order

An order moves through several states during its existence.

Whenever a new order is created, the draft state is assigned. While remaining in this state, the order can be modified as required. As soon as the order is accepted, the confirmed state must be assigned. After this, the order can no longer be modified (see Modifying confirmed orders). When the production and shipping of an order are complete, the order must be set to the fulfilled state, which indicates that the order has been completed. At any time during an order's lifecycle it can be set to the canceled state, which causes the order to be archived and becoming immutable.

# Modifying confirmed orders

As stated above, Zaikio intentionally makes orders immutable as soon as the draft state is left. We do this, because we believe immutability is making it much easier for connected software to keep track of what is going on.

We understand however, that there are real-world scenarios where orders need to be modified. Although we recommend to avoid such situations whenever possible and change real-world processes to not allow this, we have build facilities to allow an order to be changed in a way that doesn't break the immutability rule we defined above.

If your process requires changing a confirmed order, you must cancel the confirmed order in Zaikio and create a new one in it's place. Via the API you can link to two, so all connected apps understand that the second one is a successor to the first. Since you can also copy over all your references, this change can be transparent for the customer.

# Relationship between order line items and Jobs

In Zaikio the LineItems of an Order might refer to a specific Job. We intentionally made this coupling as loose as possible. We see the Order and the Product as separate, independent entities. That means you can add products to orders long after production as been started and the product is no longer in a draft state. You can even add products to orders after production has been completed. On the flip side, this means that we do not automatically correlate order and product state. So whenever product states advance you must make sure that the state of the corresponding order is matched as well. This gives you the liberty to decide for yourself when to advance order state in scenarios where many products are involved.

Since order LineItems bring their own quantity attribute, you can split the production run of a Job and put them onto several orders at once. Given the loose coupling mentioned above, we do not correlate the number of copies of a job and the quantity of a line item, so you must ensure that those numbers are plausible.