Today we have released update rollup 7 for Microsoft Dynamics NAV 2013 (Build 35488).
Update rollup 7 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 7
You can download update rollup 7 from KB 2892427 - Update Rollup 7 for Microsoft Dynamics NAV 2013 (Build 35488).
The hotfixes that have been released since update rollup 6 are listed in KB 2892427. 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.
The formats of files for exchange of bank or payroll data with ERP systems vary depending on the supplier of the file and on the country/region. The generic version of Microsoft Dynamics NAV does not support local bank or payroll file formats out-of-the-box. Microsoft Dynamics NAV therefore includes a data exchange framework that makes it easy for partners to enable users to import or export bank and payroll files in any format. For more information, see “Microsoft Dynamics NAV 2013 R2 Data Exchange Framework - Design Insights” on Microsoft Dynamics PartnerSource.
In the Posting Exchange Definition and the Posting Exchange Mapping windows, you describe the formatting of a bank or payroll file and which columns in the file map to which fields in Microsoft Dynamics NAV. When such a data exchange setup is created and activated in the framework, users can choose the related file format to start import or export of the bank files in question.
Note: This blog post is accompanied by the Data Exchange Framework Files.zip, which contains the page objects that make up the UI to the Data Exchange Framework. The page objects will be generally available, in a different number range, in Microsoft Dynamics NAV 2013 R2 Feature Pack 1.
This topic includes the following procedures:
Posting Exchange Definitions
ENU=Posting Exchange Definitions
You can now find the Posting Exchange Definitions page with the Search function.
Because no bank or payroll file formats are supported out-of-the-box, the actions and setup fields for the import functionality are hidden by default. As a first step, you must make the Import Bank Statement, Import Payroll Transaction, and Bank Statement Details actions visible in the General Journal window and you must make the Import Bank Statement and Bank Statement Details actions visible in the Bank Acc. Reconciliation window. In addition, you must make the Bank Statement Import Format field visible in the Bank Account Card window, and you must make the Payroll Data Import Format field visible in the General Ledger Setup window. This is described in the following procedure.
Note: You can also perform the work described above by using the Customize This Page function in the UI to add the actions and field to the pages.
If no data exchange setup exists to enable import or export of a specific bank or payroll file, either in Microsoft Dynamics NAV or as an external XML file, then you must manually create the setup. In the Posting Exchange Definition window, you must specify the setup and describe the line and column formatting of the file. In the Posting Exchange Mapping window, you must map columns in the file to fields in Microsoft Dynamics NAV. This is described in two following procedures.
Note: If the bank or payroll file is in xml format, then the term column in the following procedure should be interpreted as an xml element that contains data.
Enter a code to identify the data exchange setup.
Enter a name for the data exchange setup.
Specify what type of exchange the data exchange setup is used for.
You can select between three types:
Bank Statement Import
Specify what type of file that the data exchange setup is used for. You can select between three file types:
Processing XMLPort ID
Specify through which XMLport the data in the file will be exchanged.
Specify how many header lines exist in the file. This ensures that the header data is not imported.
Note: This field is only relevant for import.
If a header line exists in several places in the file, enter the text of the first column on the header line.
This ensures that the header data is not imported.
Note: This field is only relevant for import.
If a footer line exists in several places in the file, enter the text of the first column on the footer line.
This ensures that the footer data is not imported.
Specify how columns in the file are separated, if the file is of type Variable Text.
Specify the encoding of the file.
Enter a code to identify the line in the file.
Enter a name that describes the line in the file.
Specify how many columns the line in the bank statement file has.
Repeat step 4 to create a line for every payment type that you need to export.
Specify the number that reflects the column’s position on the line in the file.
For XML files, specify the number that reflects the element’s type in the file.
Specify the name of the column.
For XML files, specify the markup that marks the data to be exchanged.
Specify if the data to be exchanged is of type Text, Date, or decimal.
Specify the format of the data, if any. For example, MM-dd-yyyy if the data type is Date.
Note: For export, specify the data format according to Microsoft Dynamics NAV. For more information, see Identifiers, Data Types, and Data Formats.
Note: For import, specify the data format according to .Net. For more information, see Standard Date and Time Format Strings.
Data Formatting Culture
Specify the culture of the data format, if any. For example, en-US if the data type is Decimal to ensure that comma is used as the .000 separator, according to the US format. For more information, see Standard Date and Time Format Strings.
Note: This field is only relevant for import.
Enter a description of the column, for informational purposes.
Specify any type of data that you want to export in this column, such as extra information about the payment type.
Note: This field is only relevant for export.
Specify the table that holds the fields to or from which data is exchanged according to the mapping.
Enter a name for the mapping setup.
Processing Codeunit ID
Specify the codeunit that is used to transfer the data in or out of Microsoft Dynamics NAV.
Specify which column in the file you want to define a map for.
You can only select columns that are represented by lines on the Posting Column Definitions FastTab in the Posting Exchange Definition window.
Specify which field the column in the Column No. field maps to.
You can only select from fields that exist in the table that you specified in the Table ID field on the General FastTab.
Specify that the map will be skipped if the field is empty.
Note: If you do not select this check box, then an export error will occur if the field is empty.
When you have created the data exchange setup for a specific bank statement or payroll transaction file, you can export the data exchange setup as an XML file that can be used to quickly enable import of the file in question. This is described in the following procedure.
If a data exchange setup has already been created, then all you have to do is to import the XML file into the Data Exchange Framework. This is described in the following procedure.
Note: For instructional purposes, this procedure includes steps to create the xml file from sample content. Alternatively, use the sample xml file that is published on the NAV Team Blog.
The resulting data exchange setup enables import of a bank statement file with the following sample content.
<?xml version="1.0" encoding="UTF-16" standalone="no"?> <root> <PostExchDef Code="MYCSV" Name="My CSV Bank Statement" Type="0" CustomXMLPort="1220" ColumnSeparator="2" FileType="1"> <PostExchLineDef Code="" Name="" ColumnCount="0"> <PostExchColumnDef ColumnNo="1" Name="Transaction date" Show="true" DataType="1" DataFormat="dd-MM-yyyy" DataFormattingCulture="da-DK" /> <PostExchColumnDef ColumnNo="2" Name="Text" Show="true" DataType="0" /> <PostExchColumnDef ColumnNo="3" Name="Amount" Show="true" DataType="2" DataFormattingCulture="da-DK" /> <PostExchColumnDef ColumnNo="4" Name="Balance" Show="true" DataType="2" DataFormattingCulture="da-DK" /> <PostExchColumnDef ColumnNo="5" Name="Value date" Show="true" DataType="1" DataFormat="dd-MM-yyyy" DataFormattingCulture="da-DK" /> <PostExchMapping TableId="81" Name=" My CSV to General Journal Mapping" PostExchNoFieldId="1220" PostExchLineFieldId="1223"> <PostExchFieldMapping ColumnNo="1" FieldId="5" /> <PostExchFieldMapping ColumnNo="2" FieldId="8" /> <PostExchFieldMapping ColumnNo="3" FieldId="13" /> </PostExchMapping> <PostExchMapping TableId="274" Name=" My CSV to Bank Rec. Lines" PostExchNoFieldId="17" PostExchLineFieldId="18"> <PostExchFieldMapping ColumnNo="1" FieldId="5" /> <PostExchFieldMapping ColumnNo="2" FieldId="6" /> <PostExchFieldMapping ColumnNo="3" FieldId="7" /> <PostExchFieldMapping ColumnNo="5" FieldId="12" /> </PostExchMapping> </PostExchLineDef> </PostExchDef> </root>
The data exchange setup for a payroll file is now ready for use. The data exchange setup for bank files is now available to be selected in the Bank Export/Import Setup window to activate the setup. For export of bank payment files, you must connect the setup code that you specified for one or more payment types to the related payment method. This is described in the two following procedures.
Posting Exch. Def. Code
Select the code that represents the data XML file with a data exchange setup that you have imported. For more information, see the “To import an XML file with a data exchange setup” section.
Specify a code to identify for the setup.
This is the code that users will select in the Bank Statement Import Format field in the Bank Account Card window.
Specify a name for the setup.
Select Export or Import, to specify if this setup will be used to import a bank file or to export a bank file.
Select the codeunit that will import the bank statement data.
Select the XMLport through which the bank statement data is imported.
Users can start to import or export a bank file by selecting the related setup code in the Bank Statement Import Format or Payment Export Format fields. For more information, see the “How to: Import Bank Statements” or “How to: Export Payments to a Bank File” topics in the Application Help.
To start importing a payroll file that has been set up as a data exchange setup, users simply select the setup in the Payroll Trans. Import Format field. For more information, see the “How to: Import Payroll Transactions” topic in the Application Help.
The NAV Application team
We are proud to announce that we have shipped Microsoft Dynamics NAV 2013 R2 and that it is now available for download. Yesterday, the announcement was made to the more than 500 partners at the sold-out Directions US event in Nashville, Tennessee. Microsoft Dynamics NAV 2013 R2 adds great new capabilities to the product such as single sign-on with Office 365 and SharePoint Online, a new UI for the Microsoft Dynamics NAV Web client and the Windows client, a new foundation for cash management, a new Help Server, and powerful provisioning and administration tools. Read the announcement on The Edge.
The NAV R&D team
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:
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
A team of people interested in NAV application design has come together to work on naming and surfacing design solutions to common NAV business needs. When those solutions are generic enough to be applied in various places of the NAV application, with slight variations on implementation but mainly respecting the same base concepts, we can describe them as NAV design patterns.
Some benefits as we saw them:
Note: it is not our goal to create generic, product and language-independent software development design patterns, as described by the Gang of Four and other authors over the time. Although the idea of a NAV design pattern remains closely related to the generic concept, our hope is to give a name and show to the world only the NAV specific patterns, which are particular to the C/AL language and to the NAV business models and scenarios.
Some of the patterns describe what is old and already used several places in the NAV application code. Some other patterns will be future oriented trying to push the NAV development style towards new and better practices.
So far, the core of this team is half-community (special thanks to the Partner-Ready Software team) and half-Microsoft software engineers.
Brummel Dynamics Services, PRS
What to expect next?
So far we've been meeting to work on identifying and documenting new design patterns - as well as trying to better define the concept of a design pattern in a NAV context. As we go on, we will come closer to understanding what is the correct way to go. Until then, we're focusing on making new patterns available to the NAV developers (on our blogs, at conferences like 2013 Directions US and EMEA and NAVTechDays). The team is open - if you want to add your patterns to the collection, to receive our review or contribute, contact us. Your ideas, especially on what can be improved as well as your expectations are very valued - let us know (either by replying to the blog post, or by writing to us.
Our latest workshop on August 26th and 27th at Microsoft Development Center Copenhagen:
Note: we plan to publish patterns on a "best effort" basis - meaning that there will be no pre-established cadence, but we will focus on keeping the continuity and adding new patterns. To reflect this, we'll drop the "pattern of the week" title.
The NAV Patterns Team
It’s true! The coming release of Microsoft Dynamics NAV 2013 R2 delivers new exciting features to support cash management business processes for our SMB customers and prospects.
Why Cash Management?
Cash management is a critical part of any business operation. Business managers need to manage their cash flow, payments and debt collections quickly and efficiently to ensure the company’s financial stability, solvency and ultimately profitability.
Our SMB customers need more support for basic cash management processes; therefore, we are increasing our focus on cash management in the coming releases of Microsoft Dynamics NAV – beginning with Microsoft Dynamics NAV 2013 R2.
What’s new in the coming release?
Microsoft Dynamics NAV 2013 R2 will deliver new functionality to support bank integration with two core scenarios:
What about SEPA support?
SEPA, or the Single Euro Payments Area (SEPA) is an EU payment-integration initiative of the European Union. Its purpose is to simplify today’s fragmented national payment systems with a single set of standards. It enables organizations and individuals to make payments or bank transfers in euro to anyone within the area through their existing bank account using standardized payment instruments. SEPA will give companies the possibility to connect with more banks and help to shorten payment transfer times. As of March 2012, SEPA consists of the 28 EU member states, the four members of the EFTA (Iceland, Liechtenstein, Norway and Switzerland), and Monaco.
Microsoft Dynamics NAV 2013 R2 will provide support for SEPA in the following ways:
More information about Cash Management in Microsoft Dynamics NAV is coming soon on the NAV Team Blog, Yammer, MSDN, Directions and more. Stay tuned!
Your Cash Management Team
Today we have released update rollup 5 for Microsoft Dynamics NAV 2013 (Build 35201).
Update rollup 5 includes all application and platform hotfixes and regulatory features that have been released for Microsoft Dynamics NAV 2013. Local hotfixes for Australia and New Zealand have been added to update rollup 5 and the update rollups now include hotfixes that apply to all countries and hotfixes specific to the following local versions:
Where to find update rollup 5
You can download update rollup 5 from KB 2872273 - Update Rollup 5 for Microsoft Dynamics NAV 2013 (Build 35201).
The hotfixes that have been released since update rollup 4 are listed in KB 2872273. For a full list of all hotfixes included in update rollups, see the following CustomerSource and PartnerSource pages:
The Reusable Dynamics NAV Patterns is a joint initiative between the NAV team and NAV partners. This is an open initiative to anyone who has documented design patterns which are specific to NAV, please reach back to us either by leaving a comment here, or by writing to us. The NAV Pattern of the week will be taking a summer break during the rest of August, but we’ll be back with new patterns in September.
This pattern is about silently handing file transfers between NAV Service Tier and the NAV client. By "silently" we mean: without showing a dialog box at upload or download time.
As a terminology clarification , note that both “upload” and “download” are named as seen from the client's point of view:
Sometimes, files must be transferred to or from known locations without triggering file-save or file-load dialogs.
In the following, both the historical and the recommended ways of silently transferring files are described. Since we keep both implementations possible for the sake of backward compatibility, we strongly recommend that you use the file-transfer API provided that is provided with the File Management codeunit (419).
The legacy API for file transfers :
[Ok :=] UPLOAD(DialogTitle, FromFolder, FromFilter, FromFile, ToFile)
[Ok :=] DOWNLOAD(FromFile, DialogTitle, ToFolder, ToFilter, ToFile)
As you can see, this historical API leaves no place for turning off the functionality for showing a dialog. Historically, NAV offered a remedy to this, namely by using the "Magicpath" string, which is the constant '<TEMP>'. Under this condition, the way to invoke silent file upload or download becomes:
[Ok :=] UPLOAD(DialogTitle, Magicpath, FromFilter, FromFile, ToFile)
[Ok :=] DOWNLOAD(FromFile, DialogTitle, Magicpath, ToFilter, ToFile)
This remedy introduced an issue: If we use "Magicpath" instead of FromFolder and ToFolder specifications, then where do we upload from and where do we download to? The answer is that they are uploaded to and downloaded from the NAV server's temporary folder. The path to the temporary file can be obtained when this file is created, by using the following function in File Management: <tempFileName> := ServerTempFileName(<fileExtension>).
The new API for file transfers in the File Management codeunit:
[Text :=] UploadFileSilent(ClientFilePath)
[Text :=] DownloadTempFile(ServerFileName)
Using the API in the File Management codeunit instead of the historical API is recommended for all file transferring and file management in NAV implementations.
The following describes a scenario for the silent file upload/download pattern, both from the user’s point of view and from the NAV developer’s point of view.
The production manager at CRONUS needs an XML file in a specific format containing his latest product list with description, prices, and quantities. He wants to import the list into his web shop to keep product information updated with data in NAV.
The production manager wants to have the file in a predefined location on his hard drive. The location has been defined in a NAV setup table.
The NAV developer has written a module to query the CRONUS database and to export the product list in the pre-described XML format required by the web shop. He saves the data in a temporary server file created with this code:
ServerFileName := FileManagement.ServerTempFileName('xml');
When the file has been populated with the latest product data, the NAV developer uses the following call to download the file from the temporary location on the server to the predefined location on the client:
The call to DownloadToFile is part of the File Management codeunit, and it embeds the silent download offered by DownloadTempFile:
PROCEDUREDownloadToFile@13(ServerFileName@1002 : Text;ClientFileName@1000 : Text);
VARTempClientFileName@1001 : Text;
BEGINValidateFileNames(ServerFileName,ClientFileName);TempClientFileName := DownloadTempFile(ServerFileName);MoveFile(TempClientFileName,ClientFileName);
The NAV Patterns team