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:

• Closed transaction is a transaction that has already changed the inventory level. For example, a sales order that was shipped from your warehouse to the customer or fulfilled. Typically, a paid invoice also indicates about fulfilled or closed sales order in the ERP system.

• Open transaction is a transaction that has not changed the inventory level yet but is about to change it. This could be open sales or purchase order that is registered in the ERP but not yet fulfilled/received.

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:

• invoice/sale order;
• customer return;
• supplier return;
• purchase order;
• transfer order;
• write-off;
• inventory adjustment;
• inventory stock-take;
• manufacturing/work/build order;
• others.

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:

• calculate the inventory turnover;
• compute the stockout days;
• determine whether lost sales are caused by a stock-out or zero demand automatically; this disposes you of the difficulty to set Zeros are lost sales option manually.

Below, we describe the required and optional data types which you should provide for:

• demand planning;
• revenue forecasting;
• inventory KPIs.

The required data types for this data piece and for demand planning in particular are shown in the table below.

If you need to plan your demand by location (store, warehouse, or region) and by channel, additionally provide the data types represented in the table below.

An empty string for Location or Channel means that there is no location or channel set for this transaction.

Besides the automatic determination of outliers, there is an ability to mark a period as an outlier when providing transactional data. To do this, provide the data type shown in the table below.

After importing the data, the marked periods will have checked checkboxes in the Ignore actual sales row of the table on the Demand tab.

To forecast revenue, the required data types should be extended with one of the types shown in the table below.

This information is also used to perform revenue-based ABC analysis and calculate selling price-dependent KPIs such as annual revenue, revenue next year, gross margin, and turn-earn index.

As we mentioned above, providing on-hand history to Streamline allows for calculating several KPIs, such as inventory turnover and stockout days. There are two data types that can be used to import on-hand history into Streamline. You can choose one of them. They are shown in the table below.

You can provide Streamline with the profit obtained from each transaction by importing the data type shown in the table below. This allows Streamline to calculate the total gross profit for each aggregation period and also over the last 12 months.

Next: Item Information

Download PDF