User Guide
1. Streamline Client
2.Streamline Server
3. Starting Up
4. Connecting data
5. Demand and Sales Forecasting
6. Inventory Planning
7. Reference
1. Streamline Client
2.Streamline Server
3. Starting Up
4. Connecting data
5. Demand and Sales Forecasting
6. Inventory Planning
7. Reference
Depending on what you are going to do – generate demand and procurement plans, perform revenue forecasting, or optimize your inventory, Streamline needs different data to be imported. In this article, we describe the data types required for each case.
Streamline imports a wide range of data types. All of them are logically divided into the following data pieces:
An ERP system operates and stores a vast variety of transactions. Streamline is interested only in those that relate to changes in your inventory. In other words, Streamline needs transactions that represent a sale or, generally, an inventory movement. A transaction is usually described by its origin, and what, where, when, and how much was sold (or changed the inventory level).
On the other hand, all transactions in the ERP system can be divided into closed and open. In terms of Streamline:
The main aim of this data piece is to import sales history and on-hand history into Streamline. Typically, sales history is represented by sales (sales order or invoice) and return (credit memo or customer return document) transactions. To import on-hand history you should provide all the transactions that affected on-hand in the past. Those could include:
Despite it is not easy, and sometimes not possible, to collect and provide all the inventory transactions, this is not obligatory for Streamline to work. To create forecasts and calculate procurement plans, it needs only sales history to be imported.
However, on-hand history allows Streamline to:
Below, we describe the required and optional data types which you should provide for:
The basic data types for demand planning are shown in the table below.
Streamline allows performing two-echelon planning.
If you have only one distribution center (DC), Streamline does not require you to provide any additional data, and you can set up all DC's options in the DC settings. In this case, however, there is no ability to account for the case when a location is supplied by the supplier directly (skipping the DC).
If you have several DCs, you can import and set up them using the Database connection. In this case:
You can import any number of DCs and set up which locations are supplied by a particular DC on an item basis. It means you should set up a triple (Location, DC name, Item code). For example, the triple (West, DC west, Dark chocolate) means that DC west supplies West location with Dark chocolate.
There are two limitations on the DC-location relation:
To set up the relations, the DC name data type should be returned with the Item info query (see table below). It indicates the name of the DC in the triple.
Data name | Description | Datatype |
---|---|---|
DC name | The name of the distribution center that supplies the Item code to the Location | String |
Now, we describe the data types that the Item info query should return in order to Streamline set the relations properly.
As we explained previously, to set up a triple, the Item info query should return the following data columns: Location, DC name, and Item code. The table below shows an example of records that should be returned by the query in order to set up a DC-location-item relation.
Location | DC name | Item code |
---|---|---|
A | DC1 | Item1 |
DC1 | NULL | Item1 |
As you see, we need two records to be returned for each DC-location-item relation. The first one links location A to DC1, meaning that Item1 will be supplied by DC1 to location A. The second one declares DC1 as a location that stores Item1.
To set up a situation when an item is supplied to a location by the supplier directly (no DC involved), the query should return the record shown in the table below. The table shows example data.
Location | DC name | Item code |
---|---|---|
B | NULL | Item1 |
Let's consider an example shown in the figure below.
In this case, the query should return the data shown in the table below.
Location | DC name | Item code |
---|---|---|
A | NULL | Item1 |
B | DC1 | Item2 |
C | DC1 | Item3 |
C | DC2 | Item4 |
DC1 | NULL | Item2 |
DC1 | NULL | Item3 |
DC2 | NULL | Item4 |
Streamline can generate suggestions on inventory transfers between your stores if there is an overstock at least at one of them. By default, Streamline spends this overstock to fulfill current orders going up from the smallest to the largest, maximizing the number of replenished stores.
Additionally, Streamline allows you to put constraints on this rule by introducing the regions where the transfers are allowed. This is done using a data type that should be set for each location belonging to a region (see table below).
Data name | Description | Datatype |
---|---|---|
Transfer region | The region the location belongs to | String |
Locations belonging to different regions can't have transfers. At the same time, transfers between locations of the same region are allowed.
These constraints are optional, thus, Transfer region data type can have gaps, meaning that the locations do not take part in any intersite transfers.
Streamline allows you to plan products having a limited shelf life. Product shelf life can be given in two units of measure (see table below).
Data name | Description | Given in | Datatype |
---|---|---|---|
Shelf life, periods | It is the desired time you want the product to be sold for. | Data aggregation periods | Float |
Shelf life, days | Days |
The Shelf life parameter is used as a constraint in the inventory optimization. It is the maximal limit on the current order quantity derived from the given shelf-life period and generated demand forecasts.
This information includes items that are on:
The data types, describing a line in these orders, are shown in the table below.
Data name | Description | Datatype |
---|---|---|
Item code | The item identifier, also known as SKU. | String |
Qty to receive | The quantity of the item to receive. | Integer |
Delivery date | (Optional if Sendout date is given) Expected delivery date of the item. | Date or DateTime |
Sendout date | (Optional if Delivery date is given) The date when the order was placed. Sendout date allows Streamline to calculate the Next order date once your data is imported. | |
Location | (Optional) The location the item is being delivered to. It should be given if locations are used. | String |
Lot cost | (Optional) The cost of the purchase order line. | Float |
Order number | (Optional) The number of the order this transaction belongs to. This information is used only for display purposes in the Planned orders preview dialog. | String |
Order type | (Optional) This data type is used to tell Streamline which order type the current transaction belongs to. There are three types of incoming orders that Streamline understands: purchase, transfer, and manufacturing. If the Delivery date is not given, Streamline determines it based on the Order type. | |
Source from | (Optional) Indicates the source the item is coming from. This can be a distribution center, supplier, or a location (store). Since this data type is only used for display purposes in the In transition details dialog, it's up to you how to define the source. However, we recommend using the:
This data type is usually linked to the Order type. For instance, transfer orders are typically sourced from a distribution center or a store. |
The table below describes how Streamline determines the expected Delivery date for an order line depending on the Order type.
Order type | Location | Condition | Delivery date |
---|---|---|---|
Purchase | Store/DC | Sendout date + supplier Lead time | |
Transfer | Store | The store is linked to a DC | Sendout date + Lead time from DC to store |
The store is not linked to a DC | Sendout date + 1 day | ||
Manufacturing | Store/DC | Sendout date + 0 days |
As you see from the table:
To calculate future on-hand inventory more accurately, Streamline can account for information on orders to be shipped to the customers. It describes the items that are on open sales orders or back-orders.
The data types, describing a line in these orders, are shown in the table below.
Data name | Description | Datatype |
---|---|---|
Item code | The item identifier, also known as SKU. | String |
Qty to ship | The item amount that should be shipped to the customer. | Integer |
Shipment date | The date when the item should be shipped to a customer. In the case of backorders, this can be some promised date. | Date or DateTime |
Location | (Optional). The location where the shipment has been done (or will be done) from. It should be given if you use locations. | String |
The bill of materials information describes the components of finished products. Components can be considered as sub-assemblies (at the intermediate levels of the production process) or as raw materials (at the lowest level of the process). You can import an unlimited number of assembly levels.
Streamline also supports material requirements planning for batches. I.e. when a BOM describes ingredients that are used to produce several finished products.
To get a material requirements plan, you should provide Streamline with the data types shown in the table below.
Data name | Description | Datatype |
---|---|---|
Finished good's code | The code of a finished product or a sub-assembled item. | String |
Material's code | The material's or component's code. | |
Material qty/batch | (Optional) The quantity of a material or component that is required to produce the batch of the Finished good's code. If it is not given, it equals 1 by default. | Integer |
Batch rounding | (Optional) The batch size multiple, an integer that defines the quantity to which the quantity to manufacture is rounded up. The modified quantity is then divisible by the Batch rounding. For example, if Streamline determines to manufacture 120 units of a finished good, and Batch rounding is 50, the final quantity to manufacture will be 150. If Batch rounding is not given, it is 1 by default. | |
Manufacturing lead time | (Optional) The time required to manufacture the Finished good's code of the quantity determined using the Batch rounding parameter. It should be given in days. If it is not given, it equals 0 days by default, and the manufacturing process is instantaneous. | |
Min batch | (Optional) The minimal quantity of the Finished good's code to manufacture. For example, if Streamline determines quantity to manufacture as 5 and Min batch is 10, then the final quantity to order will be 10. If it is not given or equal to 0, this constraint is not applied. |
Streamline allows you to account for given promotions for a product automatically when it generates the forecasting model. To do this, you should provide the data types shown in the table below.
Data name | Description | Datatype |
---|---|---|
Item code | The item identifier, also known as SKU. | String |
Location | (Optional) The location where your promotion is carried out. | |
Channel | (Optional) The channel by which the promoted item is distributed or sold. | |
Start date | The date the promotion starts. | Date or DateTime |
End date | The date the promotion ends. | |
Discount | The promotion discount for the item. It should be given as a fractional number. For example, if a discount is 30%, you should provide 0.3. | Float |
To Streamline be able to account for the future promotional discounts for a product, you must also provide the history of the past promo discounts for this product in the same format as for the future discounts (see an example).
If you need to account for an item promotion that is carried out for all your locations at once, provide an empty string for the Location column.
If you have kitted items in your inventory but want to forecast and plan only by their components, Streamline can automatically disassemble them and take into account this information. In this case, you should provide the data types indicated in the table below.
Data name | Description | Datatype |
---|---|---|
Target code | The code of the item that is a component of the kitted item; the substitution item code. | String |
Item description | (optional) The description of the component item. | String |
Multiplier | (optional) The quantity of the component required for the kit. If it is not given, the default value is 1. | Double |
Item code | The code of the kitted item; the substituted item code. | String |
Substitution date | (optional) The starting date the substitution is being executed from. If the date is not given or it is less or equal to today's date, the substitution is executed immediately and on a continuing basis. | Date or DateTime |
Tracking product expiration date is crucial in some industries (for example, pharmaceutics). Streamline is able to produce a replenishment plan for such products based on the FEFO rule. Streamline also generates the projected write-offs report for the products that will expire before they can be sold, based on the forecasts. To enable this feature, you should provide Streamline with the data types shown in the table below.
Data name | Description | Datatype |
---|---|---|
Item code | The item identifier, also known as SKU | String |
Location | (Optional) The location where the item is sold | |
Batch code | The code of the batch the planning item belongs to | |
Expiration date | The date the batch expires | Date or DateTime |
On hand | The number of items in the batch that is currently on-hand | Integer |
In this case, Streamline tracks the saleability of each single planning item by the given Batch code and Expiration date.