# 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.