 | | |
| | |
|
Spaces home  Dynamics NAV SCM Support...ProfileFriendsBlogMore |  Tools   |
Dynamics NAV SCM Support Land ... in MadridBoooooost-ing your Productivity, Boosting your Supply Chain
|
||||||||||||||||||||||||||||||||||||||
|
May 09 Single UoM vs. Multiple UoMThis 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. April 20 Default Safety Lead Time: an overlooked planning parameterThis 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". March 04 Concurrent capacitiesConcurrent 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.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 methodsStarting 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.
If the transactions are posted in the above order, the result would be: January 20 SCM Business Processes vs. SCM Functionality within Dynamics NAVThis 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 StatusesI 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). January 19 Cost Application flag in table 339This 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.0Yeap, 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. December 27 Order promising (CTP) vs. Planning Engine (with Requisition or Planning Worksheets)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).
|
|||||||||||||||||||||||||||||||||||||
|
|
Invite as friend