Information Systems:Period demand - Revision history

Norwinu: /* Effect of future orders on period demand */

2019-02-02T00:29:03Z

Effect of future orders on period demand

Norwinu: /* Effect of future orders on period demand */

2019-02-02T00:28:13Z

Effect of future orders on period demand

Norwinu: /* Effect of future orders on period demand */

2019-02-02T00:27:30Z

Effect of future orders on period demand

Norwinu: /* Effect of future orders on period demand */

2019-02-02T00:26:51Z

Effect of future orders on period demand

Norwinu at 00:26, 2 February 2019

2019-02-02T00:26:14Z

Norwinu at 00:24, 2 February 2019

2019-02-02T00:24:48Z

Norwinu: Created page with " The following are a few technical notes regarding forecasts and demand planning after looking into an issue regarding period demand. These are just a few notes; purchasing de..."

2019-02-02T00:23:04Z

Created page with " The following are a few technical notes regarding forecasts and demand planning after looking into an issue regarding period demand. These are just a few notes; purchasing de..."

New page

The following are a few technical notes regarding forecasts and demand planning after looking into an issue regarding period demand. These are just a few notes; purchasing dept. would be a better source of information about the actual topics of demand planning and IC calc. -[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|talk]]) 16:22, 1 February 2019 (PST)

* The forecast file is SROFFI.
* Forecast periods (FFYFPE) use the calendar year, not fiscal year.
* Period demand (FFPDMD) for an item is simply the amount sold the previous month/period. This can be reconciled with the item transaction file (SROITR) and the sales order lines file (SROORSPL).
* Movement (FFNMOV) is a tally of the number of location touches (?) for an item in a given period. (This needs to be verified.)

==Effect of future orders on period demand==
When a sales order is created, the period demand is updated. Future orders present a special case.

The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are not in stock a.k.a future order lines. ETA dates that fall in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -16:22, 1 February 2019 (PST)).

[[Category: Demand Planning]]

@@ Line 9: / Line 9: @@
 When a sales order is created, the period demand is updated. Future orders present a special case.
-The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that are set in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|talk]])).
+The updating of an item's period demand during a sales order appears to use the promised date on the sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that are set in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|talk]])).
 [[Category: Demand Planning]]

@@ Line 9: / Line 9: @@
 When a sales order is created, the period demand is updated. Future orders present a special case.
-The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that are set in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -16:22, 1 February 2019 (PST)).
+The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that are set in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|talk]])).
 [[Category: Demand Planning]]

@@ Line 9: / Line 9: @@
 When a sales order is created, the period demand is updated. Future orders present a special case.
-The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that fall in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -16:22, 1 February 2019 (PST)).
+The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that are set in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -16:22, 1 February 2019 (PST)).
 [[Category: Demand Planning]]

@@ Line 9: / Line 9: @@
 When a sales order is created, the period demand is updated. Future orders present a special case.
-The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. ETA dates that fall in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -16:22, 1 February 2019 (PST)).
+The updating of the period demand appears to use the promised date on a sales order line, which is a field that defaults to the request date (i.e. date when the sales order is received into the system) but can be overridden by the buyer to indicate a future ETA for items that are on P.O. and not yet in stock a.k.a future order lines. Promise dates that fall in the next period will therefore update the demand for that period instead of the current one. If a PO comes early i.e. the item is received in and dispatched (i.e. picked/invoiced) before the promised date, the demand is not retroactively updated. This causes anomalies in the period demand month-to-month, as the dispatched quantity will not necessarily correlate with period demand for a given period. (In fact, I would go as far as to say the first future order for an item that has a promised date in the next period will throw out the correlation of dispatched and period demand quantity permanently -16:22, 1 February 2019 (PST)).
 [[Category: Demand Planning]]

@@ Line 3: / Line 3: @@
 * The forecast file is SROFFI.
 * Forecast periods (FFYFPE) use the calendar year, not fiscal year.
-* Period demand (FFPDMD) for an item is simply the amount sold the previous month/period. This can be reconciled with the item transaction file (SROITR) and the sales order lines file (SROORSPL).
+* Period demand (FFPDMD) for an item is simply the amount sold the previous month/period. This can be reconciled (most of the time, see section below) with the item transaction file (SROITR) and the sales order lines file (SROORSPL).
 * Movement (FFNMOV) is a tally of the number of location touches (?) for an item in a given period. (This needs to be verified.)