The business part of Mission Control'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 [API REF] which represents
the business transaction. The goods that are ordered are represented within an
LineItems [AP REF].
A line item can simply be a free text description and some pricing information
or it can reference to a Mission Control
Additionally an order holds information about the
PaymentTerms [AP REF], such
as time frame for payment, payment means hint, and addresses.
# Object graph
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ ┌─────────────┐ │ │ Orders │ │ └─────────────┘ │ │ │ │ ┌─────────────┐ │ ├───▶│ Address │ │ │ └─────────────┘ │ │ ┌─────────────┐ │ │ │ Billing │ │ ├───▶│ Address │ │ │ └─────────────┘ │ │ ┌─────────────┐ │ ├───▶│ Line Items │◀────┐ │ │ └─────────────┘ │ │ │ ┌─────────────┐ │ │ ├───▶│Payment Terms│ │ │ │ └─────────────┘ │ │ ┌─────────────┐ │ ┌─────────────┐ └──────│ Jobs │ │ ├───▶│ Customer │ │ └─────────────┘ │ └─────────────┘ ┌─────────────┐ │ │ ┌─────────────┐ ┌─┼────│ Contact │ └───▶│ Contacts │◀────┘ └─────────────┘ │ └─────────────┘ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
# Customers and responsible people
Every order has a single customer. This can either be a Zaikio
Person or a
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
# 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
billing_address you might omit it.
The shipping address or addresses of an order are handled in the Logistics part of Mission Control and are - like products - 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
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
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, Mission Control intentionally makes orders immutable as soon as
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 Mission Control 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 products
In Mission Control the
LineItems of an
Order might refer to a specific
We intentionally made this coupling as loose as possible. We see 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
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
LineItems bring their own
quantity attribute, you can split the
production run of a product and put them onto several orders at once. Given the
loose coupling mentioned above, we do not correlate the
number of copies of a
product and the
quantity of a line item, so you must ensure that those numbers