Backflushing in Dynamics NAV

Just got a very interesting question from an user, related with backflushing.

Let's begin with the definition of Backflush (setting available in the Item Card). This is the automatic deduction (consumption) of the components used in manufacturing triggered by the completion of the production order (status change to finished). Backflushing could lead to inaccurate inventory records. Consequently, it is only recommended when:
- component has a short or inmediate replenish lead lime
- component is not critical from a stock availability perspective
- manufactured item in the production order is also very short

The three above pre-conditions to use backflush lead to a minimize the consequences of having a inaccurate stock data from the time where components where actually consumed (mostly when releasing the production) to the moment where consumption was actually posted (when finishing the production order).

To emphasize the above is just APICS ... it is not Dynamics NAV interpretation.

So, user came with a question why backflushing is trigered when finishing the production order and not when posting the output. As described:
- component stock is not critical ... so it should not matter since there would be enough stock
- component has a very short or minimal lead time ... again, it should not matter when we record the consumption since replenishment will be done almost inmediately
- or, lead time of the manufactured item is short ... so, again, the moment when we record this should not matter since it should not take significant time from the released of the production order to when it is finished

Binding flag in table 337

When using "Order" replenishment policy in item card, Binding flag in table 337 will be populated to "Order-to-Order". This how Dynamics NAV solves the implementation of the pegging concept.

When executing planning routine from any Worksheet, it is important to know what is the value of this flag to better understand the actions suggested. In some cases, Navision will propose to cancel a supply (ie. Purchase order) when it is also suggesting to create a new supply on the same date with same quantity. In other words, it seems to propose cancelling a supply when it needs the exact same supply profile (date and quantity).

Even though this does not seem correct (which sounds like to be understable), this might be working as intended in some cases. As an example of what could be the reason for this odd behaviour is:
- it proposes to cancel the supply since it is not pegged to any demand (in other words, binding column does not have any value).
- secondly, it proposes to create another supply which would be pegged to the demand. This means a new reservation entry will be created with Binding column set to Order-to-Order.

Again, this is not to say current design in Dynamics NAV is optimal. This is just to describe what is the design in the back.