Dynamics NAV SCM Support Land ... in Madrid

Single UoM vs. Multiple UoM

Fri, 09 May 2008 11:57:54 GMT

This time, this would be a short entry in this blog: if you are using multiple UoM, you should be using at least Bin Mandatory. Moreover, most of the customers would need to use WMS as well.

As always, a bit of business background here. Asume you have multiple UoM, how will your warehouse look like? I would say you wouldn't mix the different UoMs in the same warehouse space (or Bins, in Dynamics NAV terminology). At least, this should not the business scenario in your company if you are looking to boost your productivity. Thus, you should be organizing your warehouse in the sense different UoM are located in different warehouse spaces (different bins). Reader should already got my point here: multiple UoMs means "Bin Mandatory" in Dynamics NAV must be enabled.

What would happen if you are not truly using "Bin Mandatory" when different UoM are defined? Your stock in the warehouse will have different quantities for each UoM (ie. there are 10 pcs, and aso 5 Boxes, and ... whatever). In the other hand, a sales order is coming for 1 BOX. How will Dynamics NAV reduce the available stock? Will it reduce from the available stock in Boxes? Or, will it reduce from the pcs available? The answer is in the cost method. Cost method defines the application logic (ie. if FIFO application will follow a First In First Out rule). Thus, there is no guarantee the stock will be reduced from those quantities available which have same UoM as your sales order does. Thus, best thing is to use Bin and define in the Sales order from which Bin you want the stock to be taken (BOX or Pcs in our case).

In the other hand, why do we need WMS? If you are using Change UoM functionality from a pick document and you would like to use this functionality, you must be using WMS since this "Change UoM" is not working in all scenarios of a basic warehouse.

Default Safety Lead Time: an overlooked planning parameter

Sun, 20 Apr 2008 18:03:09 GMT

This time, lets talk about "Default Safety Lead Time" parameter which is available in the Manufacturing Setup and Planning tab in Item Card.

First, what is this setting for? Well, the name is very representative: this defines the default time which will be added to the lead time (purchasing or manufacturing) of a given item. In other words, this setting is an added time to guarantee items will be on time. In some circunstances (not so many since planning needs to be accurate), there is a need to add some time by default to the lead time to ensure deliverables are timely. As an example, there could be manufacturing lead time of 10 days. But, planners also would like to add a buffer period in case of delays, thus they will be using Default Safety Lead Time to define this buffer period which will be added to the lead time.

As readers can note, I believe this is a constantly overlooked parameter in Manufacturing as well as Planning setup. Why? Many times, we define an Item with Make-to-Stock policy. Thus, item will be planned against stock with no regards of what are the current demands (unless, demand means item will go below safety stock level). Now, we combine this with the "Default Safety Lead Time". If we define this, assume setting is set to 1D for instance, it means that replenishment to avoid sotckout will be planned one day before than when this will happen, it will be planned at the end of the ealier working day of the stockout. Following this case, some times users feel their item lead time are accurate and good enough for not defining a "Default Safety Lead Time" in Manufacturing nor Item Card. What does this setting mean in this case? Well, this mean the stockout replenishment will be planned at the very same when it is plan to happen. Is this correct. I would say no. That is just my opinion. I am saying this based on two reasons:

A. ERP is a planning system which cannot be taken as an scheduler. This means, the planning proposals cannot be taken or considered with hours and seconds. No. Time proposals from an ERP should be bucketized in days and the capacity (start and end of a production) should be only considered within a given day not within a given day and time.

B. If users are planning against stock, the replenishment of the stockout cannot use hours are seconds, or will you consider a make-to-stock reordering policy is feasible if it considers at the very moment when stockout will be done? Having in mind APICS, stockouts need to be replenish the day before they are planned to happen since it will be difficult to guarantee that stockout will actually happen on a given day, hour, minute and second. An ERP cannot guarantee this.

Thus, if Make-to-Stock is defined, the "Default Safety Lead Time" is mandatory. In other case, I believe users need to plan one replenishment after the other, one production/purchase order after the production which originates this demand, users need to plan with no buffer lead time=with no safety leadime. If this is the case, I might say users does not plan with "Make-to-Stock", they are planning with "Make-to-Order".

Concurrent capacities

Tue, 04 Mar 2008 15:55:44 GMT

Concurrent capacities is a setting available in the routing card. With this setting, customers could define how many resources (machine) could work simultaneously in a given operation. In this case (resources working simultaneously), the operation time will be reduce due to the fact that concurrently working hours are being used for this operation.

What is the premise to have this working? It must be available capacity to be working simultaneously. In other words:

- if this is a workcenter with consolidated calendar, there must be enough machines with enough capacity linked to this operation to work concurrently.

- if workcenter is not consolidated with machines calendar, the capacity in workcenter card must be greater than 1.

To summarize, concurrent capacities:

- produces that operation time is being reduced due to the fact concurrent machines are working on the operation

- capacity consumed is the same as if there is no concurrent capacity defined

- this need to be consistent with the capacity available (consolidated machines capacity, or workcenter capacity).

Lot / SN Specific Tracking.

Tue, 04 Mar 2008 15:40:19 GMT

Lot/SN Specific Tracking defines if lot tracking data needs to be verified when outbound (sales) entry is applied to an inbound entry (purchase).

What does it means?

If "Lot/SN Specific Tracking" is not checked, it means that lot number will not be checked when applying this to the purchase item ledger entry and therefore it considers FIFO. In other words, the first item ledger entry will be applied to the outbound entry.
If "Lot/SN Specific Tracking" is checked, it will ensure item tracking data for both outbound and inbound entries are the same. In this case, it will be a fixed application.

As a side note, item tracking data defines itself two things:
- how inbound entries are applied against outboud entries
- what costing method will be used (FIFO or fix applied)

Perpetual (or Moving) vs. Periodic (or Weighted) average costing methods

Tue, 04 Mar 2008 15:28:20 GMT

Starting in 3.X versions, NAV changed from a Periodic to a Perpetual average cost calculation type. These two define how the average can be calculated.

In some cases, Perpetual can be referred as Moving average while Periodic can be referred as Weighted Average.

The calculation of a Moving average is using a transaction flow for average cost. When you have an inbound entry, the Average Cost changes based on a calculation of total cost / total quantity at that very moment in time after you add beginning cost to the additional cost and beginning quantity to the additional quantity. Any outbound entry will receive the existing average cost at that moment in time. If you are familiar with the 2.60 and prior Navision versions, this is the way average cost was calculated.

In 3.X and all later versions, NAV does a periodic weighted average for Average Costing. Prior to 5.00, this was always a daily weighted average. In 5.00, you can now do a daily, weekly, monthly, or period average based on the Inventory Setup option.

The difference can be seen in the following simple example:
a. buy 1 at 1.00 on 1/1/2008
b. sell 1 on 1/1/2008
c. buy 1 at 2.00 on 1/1/2008

If the transactions are posted in the above order, the result would be:
- A moving average (perpetual) would cost the sale at 1.00 because of the transaction flow. You would have an Average Cost of inventory of 2.00 because the last purchase inventory was at 2.00.
- A weighted average (periodic average) would cost the sale at 1.50 because the periodic weighted average takes into account all inbound entries to calculate the “period average”. Then, all sales go out at the newly computed weighted average. You would have an Average cost of inventory of 1.50 in this example.

SCM Business Processes vs. SCM Functionality within Dynamics NAV

Sun, 20 Jan 2008 10:03:53 GMT

This time lets not talk from a funcional level but from a business process level.

When implementing an SCM software, three levels of every company strategy needs to be considered: Strategy, Tactical and Operational.

From an Strategic Plan perspective, this is the S&OP process where high management levels commit to a production plan for a long/medium horizon. The result, the production plan, need to be defined as well in Dynamics NAV as forecast so enterprise resources can have a complete view of the strategy our company is following (remember, ERP is enterprise resource planning). In the case, the plan is usually defined at item group levels (not for specific products) and time periods (months). In order to be accurate, this production plan need to be matched against CRP and MPS (using the critical constrained resources).

Next step would the Tactical Plan, sometimes called the Master Schedule or the Advanced Planning (APS). In this case, The production plan as well as the current demands should be merge to have visibility of what is the need of the company. Usually, this plan will derive from the groups or time periods of the production plan into a plan for specific items in weeks. This will be then considered and ran an MRP and CRP routing considering all resources (not only the critical ones). The result of this would be to understand how much feasible is this medium-term plan.

Lastly is coming the short-term plan, the Operational Plan which is usually called Advanced Order Management (AOM). In this case, daily processes could be use some of the SCM tools available on Dynamics NAV to match requirements coming daily against current plan (which is the result from the MRP and CRP). These tools are, among others, ATP and CTP. ATP (Available to Promise) is when (for instance) there is a new requirement from the customer and the sales representative checks if there is something available, something in inventory or in-process, which can use to be commited against this new requirement. In the other hand, CTP (Capacity to Promise) is checking existing capacity to start a new production or to create new purchase or if there is no inventory available.

Production Forecast are available in the Manufacturing module.

From an MRP perspective, there are different tools in Dynamics which can be used: Requisition Worksheet, Planning Worksheet, Subcontracting Worksheet, etc.

From a CRP perspective, Order Planning or Production Order Planning/Replan can be used.

Finally, ATP and CTP are both available from the Sales Order, Order button and Planning.

Having an accurate business process definition against these very specific tools could provide you the right path to Boost your company's productivity. A critical step here would be to find a common agreement within all parties of your company on how to work with these.

Production Order Statuses

Sun, 20 Jan 2008 09:43:53 GMT

I know, I know, talking about Production Order statuses is something which all people know about. But, every once a while is good to review the concepts to ensure we wll have the same common understanding of how this should be treated from a business process perspective.

Planned Production Order. This means is a planned supply which can be removed with next run of planning routine if there is no need for this supply anymore (if there is no demand which requires having this planned production order). To remark, planning routing can remove these (indeed, it will remove all these and then recreate them).

Firm Planned Production Order. This is also a planned supply but the difference is that planning routing cannot remove them, they are firm supplies. What this means is that it will propose necessary changes (to cancel, to reschedule, to change quantity) based on the demand profile. These changes will appear as action messages from the Planning routine.

Released Production Order. These are firm supplies also but they were also sent to the shop floor to start its manufacturing. These are the ones which can be posted consumption or output against. Also, if these released production order were already started (ie. consumption or output was posted), planning will not consider changes with it.

Finished Production Order. It has a descriptive name, right? No more comment about these type of supplies. Well, one very important. A Finished Production Order can be then Adjusted (costs) and it will be considered as fully invoiced again (there are some changes here depending on the release but this is valid for the latest ones, from Dynamics NAV 4.0 SP1).

Cost Application flag in table 339

Sat, 19 Jan 2008 19:46:50 GMT

This is a critical flag to get the right costing data from Dynamics NAV.

This flag is available in table 339. As reader might know, table 339 defines applications from outbound entries into inbound entries. In some cases, this application might not correspond to a cost application. In other words, the cost of an outbound entry is not coming directly from the applied inbound entry. This is valid for average cost item where the cost is the average of a set of inbound entries (not coming from the applied inbound only).

When working with average cost, this flag should be not be checked unless this is a fix application entry where cost it is coming from the fix applied entry.

In case, reader would like to go further in the analysis of this flag, the following in true for outbound entries when calculating their costs:

- if "Applied-to entry" column in Item Ledger Entry table is populated (in this case, this is a fixed application), the Cost Application flag for this application must be checked. Also, the "Average Cost" column in Value Entry must be unchecked (average cost will not be calculated since cost is coming from the fix applied entry).

- in the other case, "Applied-to entry" column is not populated (in this case, this is not a fixed application), the Cost Application flag must be unchecked as well as the "Average Cost" column in Value Entry must be checked (average cost must be calculated for this outbounf entry).

Good things which were released with NAV 5.0

Sat, 19 Jan 2008 19:34:06 GMT

Yeap, lets talk this time about some good functional changes coming with Dynamics NAV 5.0.

There are two very good things which are coming in Dynamics NAV 5.0: Application Worksheet and G/L Posting groups setup check when creating a purchase order.

Application Worksheet: this is a visual representation of tabla 339. As a background, table 339 defines the applications from outbound entries to inbound entries. This applications defines costs, item tracking availability among other things. Before Dynamics NAV 5.0, there was some cases where applications need to be changed. A good example of this was when posting a purchase order and then a sales order which was applied to the prior purchase. In this case, if for some reason the purchase need to be undo'ed (lets say, customer data was not correct and you need to redo it), Dynamics NAV does not allow to undo the purchase order. Reason in this design was that the purchase order was already applied to an outbound entry. What were you able to do before Dynamics NAV 5.0? Nothing but going to table 339 and manually changed this applications to a new purchase order with the right data (in other words, something which users must not do it ... manual and direct changes into NAV tables). What are you able to do now with Dynamics NAV 5.0? Use Application Worksheet. In this case, users will be able to open Application Worksheet form and do the changes there (removed the application to the old purchase order and applied the sales outbound to the new purchase order with the right data). However, if anyone will be using this, keep in mind this form should be accessible only for a super-user since the type of changes and impact (costing, inventory availability) are critical. So, not all users should be accessing this form.

Posting groups check: I believe this is a change on the direction of improving the usability of Dynamics NAV. In this case, previous versions of Dynamics NAV were not checking the posting group setup with posting or creating a purchase/sales order. What that this mean? As an example, one of the needed posting groups in NAV is the Inventory account where purchase order posting creates a debit onto this account to cater for the money company has in inventory. However, earlier versions of Dynamics were not checking this account was defined and this was producing an error when posting the inventory costs into G/L due to the inexistence of this account in the G/L setup. With Dynamics G/L, there is a more extensive check to ensure needed accounts were setup in G/L.

Hopefully, you also think about this being good changes coming in with Dynamics NAV 5.0.

Order promising (CTP) vs. Planning Engine (with Requisition or Planning Worksheets)

Thu, 27 Dec 2007 14:39:37 GMT

Mmm, this is a tricky one. Most of the users thinks that when promising an order through the CTP engine makes unnecessary to run the planning engine (with Requisition or Planning Worksheet). This is a common missunderstanding.

The CTP engine in Dynamics NAV is the functionality called Order Promising (available through the Order button in Sales Order). Think about this functionality like when you are scheduling your free time with new activities as soon as they come or as soon as you realized about them. At the end of the day, you might rethink about the schedule for the next day since it would be better to reorganize them based on priorities, preferences, ... Moreover, you might want to think about what do you need to have ready before starting any activity (in other words, what materials do you need). Therefore, you would like to replan to make a complete schedule taking into account your company's goal (ie. priorities).

And, to remark, when rerunning the planning, due dates or what you commit to your customers (or friends if this is about your free time), need to be respected. So, this does not mean it would change the overall planning, no. It would adjust the current schedule to better satisfy your needs increasing customer satisfaction (replan using due dates, priorities, ...) and to reduce inventory (replan also using planning parameters and to create material requirements).

ERP vs. MRP II

Thu, 27 Dec 2007 11:08:42 GMT

Just got a very interesting question, does Dynamics NAV provide MRP II tools?

I am not sure how much the reader is familiar with this terminology but just in case ...

ERP: Enterprise Resource Planning. As its name describes, ERP's are intented to provide visibility of all resources in a company and provide planning tools for them (CRP as well asMRP planning). From this perspective, the whole enterprise is taken into account.

MRP II: Manufacturing Resource Planning. These are similar to ERP's except MRP II focuses on manufacturing. With this in mind, the tools provided by an MRP II are more powerful from a manufacturing perspective however they loose perspective on the overall enterprise (ie. business priorities, strategic planning, etc.)

Dynamics NAV, which is an ERP, does not provide a full MRP II suite of tools ... but it is not intended to provide them. Dynamics NAV provide the following capabilities which a MRP II does not provide:

- Integrates Planning and Control departments in a company

- Provides visibility on the Strategic Business Planning (ie. forecast or production plans)

-Supports plans and activities of marketing, finance and production to create plans to achieve the overall goals of the company (ie. demand planner)

- Provides Execution to the Purchasing and Sales (ie. Order management)

- ...

Therefore, Dynamics NAV is an ERP and not an MRP II but ... who knows in the near/mid-term future. I personally believe ERPs will be adding MRP II tools to their own functionality.

Dimension error when running Adjust Cost

Thu, 27 Dec 2007 09:56:42 GMT

Having dimensions set to "Code Mandatory" or "Same Code" could lead to the following error message when running the Adjust Cost: "Select a Dimension Value Code for the Dimension Code xxx for Item yyy".

This occurs because the item card and the existing Item Ledger Entries being adjusted do not have same dimension value codes. Therefore, when Adjust Cost tries to create a new Value Entry (of type Adjustment), it refers to the dimensions from the existing Item Ledger Entry. However, when trying to post this entry, it will provide an error since it checks consistency with the dimension setup in the item card.

To work around this problem, remove the contents of the Value Posting in the dimension setup. To do this, follow these steps:

A. Click Sales & Marketing, click Inventory & Pricing, and then click Items

B. In the Item Card dialog box, press F5 to open the Item List dialog box. Select the item on which you want to run the Adjust Cost-Item Entries operation, and then click OK

C. In the Item Card dialog box, click Item, and then click Dimensions

D. In the Default Dimensions dialog box, remove the contents of the Value Posting box

As a remark, when there are no more open item ledger entries against the item, you can reset the Value Posting to Code Mandatory or to Same Code. Then, run the Adjust Cost-Item Entries operation without a problem.

Open Shop Floor Bin Code

Thu, 27 Dec 2007 09:43:54 GMT

The Open Shop Floor Bin Code is defined in the Location Card, Bins tab and it is activated when location is defined as WMS Location (Directed Put-away and Picking enabled).

It is use to integrate WMS and Manufacturing when automatic flushing (backward or forward) is also defined. In this situation, the component quantity being automatically posted as consumed would need to be stored in the bin number provided as the Open Shop Floor Bin in order for the automatic flushing of inventory components to occur. In other words, the Open Shop Floor Bin is used for flushing.

Keep in mind, you must have the items that will be flushed set up on the item card for pick+forward or pick+backward in order for this to work as well as you must also have sufficient stock of those items in the open shop floor bin. Then, using the normal logic for when items are flushed, the system will consume items out of that bin.

Changing item tracking code is not allowed

Thu, 27 Dec 2007 09:26:22 GMT

Item Tracking Code cannot be changed, when item already has Item Ledger Entries. The main reason behind is costing. To better understand this design, it would be good to differentiate between cost application and item application:

- Item Ledger Entry Application: Defines what ILE to use when applying an outbound entry to an inbound.

- Cost Application: Defines where to take the cost from (ie. which ILE's) for a give outbound entry.

Having this in mind, item tracking code impacts in both ILE and Cost Application. Therefore, changing this is a critical change which need to be thought carefully before applying it.

If we assume this change is allowed, what would happen to those ILE that could later be reopened (ie. an item charge to a purchase, undo receipt/shipment, etc) which have now a different cost or item ledger entry application? If these are reopened ILEs, how should NAV apply costs to these ILE's? Or, what would happen with costs if lot tracking is changed to a serial tracking?

Saying this, I must agree there could be different solutions to address these scenarios (ie. split the lot costs into serial costs, ...). However, I also believe it would be very difficult to find an acceptable solution within the Dynamics NAV community since each of them has a different business process and understanding. I assume, Microsoft development considered the best design option was not to allowed doing this and forcing users to create a new item,

In case this is considered, a workaround would be:
- Not to leave any ILE opened for this item
- To remove all quantities from stock
- Rename the item
- Create a new item (with old item name) and with the correct item tracking code
- To post positive adjustment for the stock against this new item

Backflushing in Dynamics NAV

Sun, 23 Dec 2007 12:05:06 GMT

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 replenishment 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

Sun, 23 Dec 2007 12:03:16 GMT

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.

Clarifying "Planning Flexibility" flag: firming vs. fixing supplies

Sun, 23 Dec 2007 11:56:38 GMT

Planning Flexibility flag... This flag is something which is not very clear on what is the functionality behind.Very frequently, users expect this flag as a tool to firm supplies. However, the right way to define what is this flag for is as a tool to Fix supplies but not to firm supplies. How is this flag used in the planning engine?

Just to start with, Planning routine in Dynamics NAV actually performs two actions:
- checks inventory availability
- then, based on the inventory availability, it suggests action messages with proposed changes on the inventory profile.

In the other hand, Planning Flexibility is a flag, which is available on production and purchase orders, with two permissible values: Unlimited and None.

When Planning Flexibility is set to Unlimited means supply (purchase, production) will be use during the planning routine in both inventory availability calculation and the action message proposals. Therefore, planning could request a quantity or due date change of this supply with flag set to Unlimited.

However, if Planning Flexibility is set to None, change proposals (action messages from second step in planning) will ignore any supply (purchase, production) with this flag set to None. This means, supply will be used to calculate inventory availability but will not be considered to propose changes (date, quantity changes) since it is considered as a fixed supply.

Introducing the blog, introducing myself

Sun, 23 Dec 2007 11:52:42 GMT

Welcome to the Dynamics NAV SCM blog in Madrid !

I am Sigfredo Beerman, Dynamics NAV Support Specialist involved in those questions related with companies' Supply Chain Management (SCM): bugs, design questions on how is Dynamics NAV intended to work... But, besides dealing with Dynamics NAV, I am an SCM evangelist, dreamer, believer ... For the last 10 years, I have been working with different SCM tools from both perspectives: ERP applications and MRP II software.

Having this in mind, the main goal I have is to add content to the blogsphere on how to better use Dynamics NAV to boost the productivity of companies using this. Another secondary goal is to compile and share all those nice questions, tips, tricks or functional comments I take from the final users and use this blog as a reference.

Just to ensure we all readers of this blog have common understanding, SCM is considered from a APICS definition to be all those tools which enables to increase customer satisfaction while minimizing inventory and reducing costs. From a Dynamics NAV perspective, granules which relate to SCM are those which map the following business processes:
- Sales & Purchase Profit (sales and purchase order management)
- Inventory Optimization (planning, inventory management)
- Warehouse Management
- Cost Reduction (Cost method and application)
- Service Management

From a personal side, people usually call me Sigui or Ziggy. Feel free to post any comment/question related with this blog and I will be happy to try to address those.

Blog list: Blog list

Fri, 09 May 2008 12:19:26 GMT

Book List: Book List

Thu, 03 Jan 2008 18:59:25 GMT