Manufacturing re-work ... this is a critical area.
Assume this scenario:
Mmmm ... I see some issues on this business process:
If you would like to minimize your re-work activities, better to analyze why those happen by having a separate entity (separate production order maybe). If you would like to understand how much it cost to produce the item better to have also a separate entity.
This is not NAV, not even ERP ... this is just planning.
If you have a reorder item, you would like to plan stock level. Here, you asume a replenishment should be triggered when stock goes below that certain stock level (reorder point). If you have a proper calculation of this reorder point, you have some set of certainty that remaining stock (whatever is below reorder point) is enough to address incoming demands until the (just created) replenishment will come.
Under this assumption, why bothering with reservations? Why reserving stock for a given demand? Don't you have certainty that stock would be enough? Planning will know nothing about this. If you have a stock reserved and incoming demands are coming, plan won't do anything. You user should do.
Thus, if you ever need to reserve stock with reorder point items, you should keep in mind this might impact your planning since stock is there but cannot be used for incoming demands.
NOTE: if your reorder point does not provide accuracy here, you should use "Safety Stock". Here, I would suggest you to read the entry just posted yesterday. In any case, this reorder point is based on the average demand within the lead time to replenishment. In other words, as an average, you should have enough stock here to cover incoming demands within time it takes to replenish.
Shipment date in NAV shows the planned shipment date. This date is not when it will actually be shipped but when it is planned to be shipped. Thus, NAV is using this when planning, creating a production order from a given demand ... This shows when sales should be shipped for not being late to customer's needs.
Due date is when production, purchase, transfer, service needs to be done. This due date requires other entity (a demand) which drives due date. As an example, if a demand should be shipped in 2 days from today and we need to manufacture the ítem, the production should be done by tomorrow (1 day earlier if safety lead time is 1D). This is the production order due date.
Posting date is when order is actually posted. This will flow through inventory (as Posting Date column in Ítem Ledger Entries) and will also result in changes on the stock and inventory valuation.
Sometimes we tend to confuse when dealing with the above three dates. To keep it short:
- Due date is calculated from other date (ie. production due date or purchase expected receipt is calculated from its demand requirement/shipment date
- Due date and shipment date are consistent through date conflict functionality in NAV (ie. if a production is specifically required for a demand through an order-to-order binding, the productiondue date cannot be later than demand shipment date)
- Posting dates should also be consistent. Here, NAV offers the "negative inventory" functionality where it allows posting in negative stock. Thus, NAV does not check all scenarios where posting dates are in conflict
The above is interesting when thinking about how date refresh should behave. As an example, what if ...
- Item with lot-for-lot
- We have a demand for Sept 1st
- We do not have capacity in Aug
- Should the production due date be Aug 31st or Aug 1st?
The above is a relevant question since setting one due date or the other might mean not being able to group other demands within same replenishment. Thus, even this sounds a dummy topic (these are just dates, uh?), it is important to understand the differences and consequences on setting one or the other while it is also good to avoid the very frequence confussion with (planned) shipment date (versus what was the actual shipment date).
Update rollup 6 for Microsoft Dynamics NAV 2013 (Build 35345) has been released.
Update rollup 6 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2013 and includes hotfixes that apply to all countries and hotfixes specific to the following local versions:
Where to find update rollup 6
You can download update rollup 6 from KB 2881294 - Update Rollup 6 for Microsoft Dynamics NAV 2013 (Build 35345).
The hotfixes that have been released since update rollup 5 are listed in KB 2881294. For a full list of all hotfixes included in the update rollup, see the following CustomerSource and PartnerSource pages:
For more information about update rollups for Microsoft Dynamics NAV 2013, see Announcement of new hotfix process for Microsoft Dynamics NAV 2013.
Reorder cycle in NAV was an old planning parameter we had before NAV 2013 was released. However, it is not that we are loosing the functionality in back but that NAV split this old Reorder Cycle into different fields. Main reason for this: usability. Better to Split different concepts behind Reorder Cycle to better manage each. But, what where the different concepts we had with Reorder Cycle?
- Lot Accumulation Period. This is a pure Lot-for-Lot parameter where different demands within a certain period could be grouped into one single parameter. These demands are grouped if the respective due date is within the same Lot Accumulation Period. Thus, first parameter introduced in NAV
- Reschedule Period. Now, we have our replenishment (supply) profile created. What happens if any demand is rescheduled? Will the existing supply be reschedule? Well, that depends if the new demand due date is within the Reschedule Period compare to the old date. If so, no new to create a new replenishment, the existing can be rescheduled.
So, what is the benefit here? Me, as planning user, can setup different values on each of these fields if my business requires so. Earlier versions, with just Reorder Cycle, we had just one value for different meanings.
Exceptions happens ... but should happen exceptionally. That's the rule!
Under this assumption, if we run into a situation where our customer is getting too many exceptions when planning, it might be time to re-calculate planning parameters or to re-confirm if current policy is still recommended. What is NAV design around this? When stock goes below safety stock, we have an exception. This situation (stock drops below safety) should not happen on a regular basis. Safety stock is calculated to mitigate exceptions on demand or supply profiles (ie. uncertainty of respecting lead times). Thus,safety is built to handle exceptions. If this is not the case, it is time to re-calculate this. Opposite to this safety stock are other planning parameters as Reorder point where dropping below this is not an exception but regular business. Thus, there is a conceptual difference on these two which should answer what is the parameter which should allow us handling exceptions.
For those who are interested, there are many good planning websites which provide info on how "Safety Stock" should be calculated. This safety stock calculation is not a NAV functionality but a business planning standard.
SkyDrive continues to be a growing leader in securely storing and sharing documents across the internet. Integrating sharing of documents on SkyDrive with Microsoft Dynamics NAV is much simpler and let’s have a look how.
*There are no additional add-ins or code required for integration.
Step 1: Create a new document on SkyDrive (Word, Excel, PowerPoint):
Step 2: Select the document and click Sharing:
Step 3: Choose the relevant sharing permissions for the document:
Step 4: Open a page in the Microsoft Dynamics NAV 2013 Windows client, and then choose Links:
Step 5: Create new Link from Actions and paste your SkyDrive shared link. Click Save.
Step 6: Any user accessing the order can open Links and access the document saved on SkyDrive:
These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.
Mohamad VajidMicrosoft Dynamics NAV
You read it here first! Microsoft Dynamics NAV R2 will deliver exciting new features to support cash management for our customers and prospects.
What it really means for customers
The bottom line is increased productivity – for all our customers – in almost any segment! The new Cash Management features in Microsoft Dynamics NAV R2 will automate and improve the cash management processes that are vital for all our customers regardless of the business they’re in.
What features are introduced to enable this?
SEPA CREDIT TRANSFER
A new feature is introduced that enables the user to export payment data to an electronic bank file in SEPA compliant format. This gives the user the possibility to integrate electronically with any bank in the Single European Payment Area and get higher efficiency in the payment process end-to-end.
Also, when payment instructions to the bank are managed directly in the system the user gets better control over the payment process and the ability toenhance cash flow due to SEPA rules about dates.
SEPA DIRECT DEBIT
A new feature called SEPA Direct Debit Collections, which provides an efficient way to handle customer’s payment collections through your preferred bank in the Single European Payment Area (SEPA) with less manual entry of data and effective mandate handling.
The feature allows users to collect money from their customers in a seamless connected way with the invoicing process, minimizing the order to cash lead time and increasing their cash management efficiency.
A new tool that enables partners to import SEPA compliant schemas (ISO 20022) into Microsoft Dynamics NAV and export the desired xml tags in an xmlport ready format. This gives the partner an excellent starting point for building up new xmlport to handle SEPA format variations for its customers.
Also, when handling the xml schema, relevant information about each tag is displayed enabling filtering mandatory tags and attributes.
How and when you can learn more on MSDN
We are working on a number of knowledge articles right now and plan to have these ready for you soon on MSDN
Hear more first-hand at DIRECTIONS!
Don’t miss the upcoming Direction events. Join us to hear how Microsoft Dynamics NAV 2013 R2 offers new cash management features in a harmonized way across country versions. We will demonstrate the new features and you will learn how you can take it to your markets - enabling you to go for volume by having more application features to offer as standard.
Stay tuned for more info on the NAV team blog space, Yammer, MSDN, Directions and more.
Your Cash Management team