Upload production schedule

Overview

A common task is to connect your scheduling system with TilliT, that way all orders that have been scheduled can be added to TilliT ready for execution. This article will run through an example of how you can easily transform a single work order to run across multiple assets with the context of order attributes, tolerances and components. Here are some things to think about before progressing.

Your scheduling datasource

There are many solutions for scheduling and depending on which one you have, it will change how the schedule is formatted and located. Ideally the schedule can be exported into a structured text file such as JSON, CSV or Excel. Once we have our schedule in this form, we can easily traverse and reliably script the mapping of data to the TilliT entity model.

What is required for a TilliT Work Order?

The work order is the largest data structure in TilliT, there are many fields such as attributes that may be required to add context to the order execution. Adding complexity to this is the particular 'route' the order may take across assets. A single order may be created for multiple assets. Following this guide, we will show how easy this is to accomplish.

What will trigger the script to be run?

It is recommended there is a reliable and predictable method for importing orders into TilliT, whether it is the start of every week, or on any scheduling update. This article will show you how we can also update existing orders as the schedule changes.

Using the Order Instance Upsert Endpoint

For loading orders into TilliT, we recommend using the POST:/core/order-instance/upsert endpoint. This has more functionality then just creating an order-instance. This endpoint will do the following

• A single request accepts an array of work orders.

• A single work order can be assigned multiple assets by supplying an array of asset names. All assets must already exists

• Material, UnitOfMeasures, Attributes, Components and Tolerances will be created if they do not already exist and updated if they do.

• Any existing order is updated (existing is defined as the same orderNumber, operation and asset). Any changes to the schedule can be sent to the upsert endpoint without creating duplicates.

You can find out what payload is expected by seeing the swagger doc here. To start, lets look at the bare-minimum needed to utilise this endpoint as you can see below.

[
  {
    "orderNumber": "string",
    "dueDate": "string",
    "quantityTarget": number,
    "asset": "string",
    "defaultRunRate": number,
    "orderDate": "string",
    "scheduledStart": "string",
    "scheduledEnd": "string",
    "status": "NEW",
    "name": "string",
    "material: {
      "externalId": "string",
      "name": "string"
  }
]

Fill out the above with some dummy data and send the post request to the TilliT API. A successful request will return the order you just created and will be viewable inside TilliT ready to be executed. Now lets start to expand the functionality of the upsert

Upsert a work order to multiple assets

Instead of using the asset field to define a single Asset for the order, use assets to define a list of asset names that the order will be created on. For example, assets: ['Depal 1', 'Filler 1', 'Pal 1'] will create the same order on each asset. Save these names locally or retrieve these names using the GET:/core/assets and filter the response body.

Alternatively, your master data may already define an order template (see here) which is the route(path of assets) a particular material needs to follow to be executed. If this is the case, then simply use a single asset that defines the start of the order template with the appropriate material. Again, the response will return all the orders created.

Include Order Attribtues

An order attribute adds more functionality within TilliT by giving context to the order. To include order attributes, simply use the attributes field to supply an array of objects such as below. Again, any attribute that does not already exists will be created. All attribute names must not start with a number or symbol.

"attributes": [
  {
    "attributeName": string,
    "value": string,
  }
]

Include Tolerances

Tolerances are used to define a range of acceptable values during order execution, defined by a target, lower and upper limit. Order tolerances allow us to change these values for each order. You can include them by adding the tolerances field like below. Any tolerance that does not previously exist will be created.

"tolerances": [
  {
    "processVariableName": "string",
    "lowerLimit": number,
    "upperLimit": number,
    "target": number,
  }
]

Include Order Components (see here)

Order Components is an inventory of items that are required to produce the material of the order. These can be added to the order by using the orderComponents field.

"orderComponents": [
  {
    "componentExternalId": "string",
    "componentGroup": "string",
    "componentName": "string",
    "target": number
  }
]

Ready to go!

You now know everything that TilliT can expect from your API request. It's time to move onto the next step, how to find all this information in your current scheduling systems. Keep reading below to see some examples of how we can use different types of software to extract and upsert the data into TilliT