Ones per day the KPI will log to the total sum of all offers that are not accepted, declined or cancelled. If a offer is overdue it will be counted. The values of the offers will be converted to base currency.   

Will include all offer rows that are set to either accepted or declined/cancelled during the last 30 days.

The KPI divides the value of accepted rows with the value of rejected/cancelled.     

A ratio of number of offers that was accepted compared to decline during the period. will be expressed in % calculated by the number of accepted offers compared to the number of declined offers.

Will include all offer that are set to either accepted or declined/cancelled during the last 30 days.

The KPI divides the number of accepted offers with the number of rejected/cancelled.     

An average number of days from create date to decision date for offers during the last 30 days. Decision date is the date where the offer either was accepted, declined.

Includes all offers that has either got status of accepted or declined for the period. Will count the total number of days from created to “decision date” and divide that with the number of offers.  

A running 30 days ratio of invoiced value compared with budget value. Budget is noticed in base currency and the sales are converted to base currency in this KPI.

Will sum all invoiced values the last 30 days and dived with the sum of prognosed values for the same period.
The invoiced value will be converted to base currency. prognosed values are always in base currency 

The result will be logged as a %, no decimals

A running 7 days ratio of invoiced value compared with budget value. Budget is noticed in base currency and the sales are converted to base currency in this KPI.

Will sum all invoiced values the last 7 days and dived with the sum of prognosed values for the same period.
The invoiced value will be converted to base currency. prognosed values are always in base currency 

The result will be logged as a %, no decimals

A total value of orders that are not delivered. All orders will be converted to base currency if they are made in other currency.

Will sum the value of all rows that are not picked at warehouse or delivered from supplier.

The value will be converted to base currency 

A value without decimals

Back Orders value. A sum of the value of all backorders. Expressed as a total value in your base currency. (backorders in other currencies will in this calculation be converted to base currency)

Will sum the value of all rows that are typed as backorder.

The value will be converted to base currency 

Will only be applied on warehouse delivered products. (not direct delivery’s, services or other supply mode typed products) 

A value without decimals

An 30 days running average of the gross margin on orders. Will be expressed in %

Will calculate an average ratio between gross margin and revenue for the last 30 days orders.

Will use the order and order date as filter, so adjustments / change of orders price/cost in the invoice will not be covered by this KPI

A % without decimals

A 30 days running average of the order size. Orders in different currencies will be converted to base currency.

Calculate the average size of the orders for the last 30 days. Will use the order and order date as filter, so adjustments / change of orders price/cost in the invoice will not be covered by this KPI

A value without decimals

A sum of cancelled, annulled or deleted order rows the last 30 days. This is a value of orders that we got from customers, but for some reason didn't manage to deliver. All values will be converted to base currency

We sum the value of all order rows that are cancelled. annulled or deleted the last 30 days. The values will be converted to base currency.   

A value without decimals

A total inventory value

Will include all products stored at a warehouse.

If the KPI is set up to handle all warehouses, the KPI will only include warehouses where the owner type is equal to Client. (not warehouses owned by customers or suppliers

If KPI is set up to handle a specific warehouse it could handle any warehouse.

A value without decimals

Inventory turn over value. The result will be expressed as how many times the inventory will be consumed on a yearly basis. The calculation will be done on cost of sold gods and average inventory value the last 30 days.

The cost of goods sold for the period will be divided with the average inventory value for the period. 

The values will be calculated for the latest 30 days and then multiplied with 12 to get a yearly value.

(COGS 30 days/Average Inventory 30 days ) x 12 = Inventory turn over

A value with 2 decimals

An average number of days between the order date and the ship date

We will look at all orders that has been delivered during the last 30 days. we will sum the days from order to shipment day for all orders and dived that with the number of orders.

A value with 2 decimals

A 30 days running average number of days between the first promised date and the actual date the customer got the delivery.

This will measure how accurate the first order confirmations are.

When a order is placed in XTND Backend a expected delivery date is calculated and send to customer in a order confirmation. This date is calculated based on known balances, purchases and leadtimes.

This KPI will log the difference between what we promised the customer in the order confirmation and the real delivery time.

The result will be value with 2 decimals

For the whole company or for a specific warehouse. direct delivery is also a grouping possibility.

A higher value is handled as positive

A 30 days average of hours between time when order was released to warehouse for picking, and the when the confirmation of picking was done. 

Counting of hours between when the order was released to warehouse for picking, and when the warehouse confirmed the picking. The hours are summed for the last 30 days and divided with the number of orders. The purpose is to get a trend line/ kpi about how the warehouse is performing.

Could be used on direct delivery also, then the calculation are between when the purchase is made and delivery confirmed by supplier

The result will be value with 2 decimals 

For the whole company or for a specific warehouse. direct delivery is also a grouping possibility.

A Lower value is handled as positive

A average of days from order date to invoice date. Will be calculated as an running average for the last 30 days invoices.

Count the average days from order date to invoice date for the last 30 days

Will use the invoice date as filter in the query. 

The result will be logged as a value without decimals

Could be handled on the whole company or by salesmen

A lower value is handled as positive

A value of all customer invoices (accounts receivable) not paid. Invoices in other currencies will be converted to base currency.

We will sum the value of all unpaid invoices. The values are converted to base currency

We will sum this every night and we will not adjust a value if the pay date is entered as a date in the past.

The result will be logged as a number value with 2 decimals 

For the whole company and by salesmen

A lower value is handled as positive

A 30 days running average ratio of the value of credit invoice vs total invoice value.

We will sum all credit invoices created last 30 days. Divide this with total value of all invoices same period

The values converted to base currency  

The result will be logged as a % value with  0 decimals 

For the whole company and by salesmen

A lower value is handled as positive

A 30 days running average of number of days from invoice date to full payment. 

We will calculate the average days for all fully paid invoices. We include all invoices where fully paid status has occurred the last 30 days.  

The result will be logged as a number value with  2 decimals 

For the whole company and by salesmen

A lower value is handled as positive

A value of all customer invoices (accounts receivable) where the pay date has past. Invoices will be converted to base currency in this KPI

We will sum all unpaid invoices where pay date has past with more than 24hours.  

The values are converted to base currency. We will sum this every night and we will not adjust a value if the pay date is entered as a date in the past.

The result will be logged as a number value with  2 decimals

For the whole company and by salesmen

A lower value is handled as positive

A 30 days running ratio of how many orders delivered on time and in full.

See the knowledge base for more details about how this is calculated.

The result will be expressed in %

At order registration a internal picking time are defined on each row. This is calculated based on order stop time and picking lead time. (your service levels that you communicate with your customers)

This date is handled as a timestamp when the warehouse must have confirmed the order as picked. If we don´t meet this date we handle that order as NOT in Time.
We also check if there are any products on the order wasn´t delivered, If there are, we log that as NOT IN FULL. 

We will compare number of rows that are NOT on time and in full, with the total numbers of rows picked during the period.

We will aggregate rows to order level, the value will be on order level.

We will log all rows that are NOT warehouse handled as  delivered on time.

The result will be logged as a %, 2 decimals  

For the whole company or by warehouse.

A higher value is handled as positive

A 30 days running ratio of how many orders delivered on time.

See the knowledge base for more details about how this is calculated.

The result will be expressed in %

At order registration a internal picking time are defined on each row. This is calculated based on order stop time and picking lead time. This date is handled as a timestamp as when the warehouse must have confirmed the order as picked. If we don´t meet this date we handle that as NOT in Time.

We will compare number of rows that are NOT on time and in full, with the total numbers of rows picked during the period.

 We will aggregate rows to order level, the value will be on order level.

 We will log all rows that are NOT warehouse handled as  delivered on time.

The result will be logged as a %, 2 decimals

For the whole company or by warehouse.

A higher value is handled as positive

A 30 days running ratio of how many orders delivered in full.

See the knowledge base for more details about how this is calculated.

The result will be expressed in %

When a row are confirmed as picked we log if there where any deviation in picked quantity  compared with asked quantity.

We will compare number of rows that are NOT in full  with the total numbers of rows picked during the period.

We will log all rows that are NOT warehouse handled as  delivered in full. 

The result will be logged as a %, 2 decimals 

For the whole company or by warehouse.

A higher value is handled as positive

A 30 days running ratio of how many order rows delivered on time and in full.

See the knowledge base for more details about how this is calculated.

The result will be expressed in %

Count rows with status of both in full and on time, divide that with total number of rows for the period  

The result will be logged as a 2 decimal % value 

For the whole company or by warehouse.

A higher value is handled as positive

A 30 days running ratio of how many order rows delivered on time.

See the knowledge base for more details about how this is calculated.

The result will be expressed in %

Count rows with status of on time, divide that with total number of rows for the period 

The result will be logged as a %, 2 decimals 

For the whole company or by warehouse.

A higher value is handled as positive

A 30 days running ratio of how many order rows delivered in full.

See the knowledge base for more details about how this is calculated.

The result will be expressed in %

Count rows with status of in full, divide that with total number of rows for the period 

The result will be logged as a %, 2 decimals 

For the whole company or by warehouse.

A higher value is handled as positive