Most of us that’s been programming in Dynamics NAV for a while are aware of the Excel Buffer table. It is a super useful table that can be used to create and read Excel files from C/AL code. This table have been around as far as I remember, and now it has some siblings, the XML Buffer and CSV Buffer tables.
The concept is the same, a table with functions to create or read files, this time XML/CSV files instead of Excel files. Just like with the Excel Buffer table, the XML buffer and CSV buffer table should be used as temporary tables.
This blog post describes how those tables can be used. With some examples where the task is to export/import items through XML/CSV files.
First the XML export; to do this I create a function in a codeunit that has the XML Buffer (table 1235) as a temporary variable. As a first step I use the ‘AddGroupElement’ function to add an ‘Items’ group element. Then to that element I add an attribute using the ‘AddAttribute’ function, the attribute contains the company name from which the data is exported. Below that I add the code to loop through the item records where I use the same functions to add an ‘Item’ group element with the item number as an attribute. To add child elements for the fields in the item table I use the ‘AddElement’ function and when I am done adding all the fields I use the ‘GetParent’ function to go back up one level in order to add the next item. Simple, right? If not, look at the code below and the screenshot of the file and it probably makes sense.
After the items have been looped through the ‘Save’ function will export the data and create an XML file with the given name and path (note that the XML Buffer table also have some functions to handle the upload and download of the file and to add namespace information, etc. I have skipped all that to keep it simple).
The file created then looks like below.
As easy as it gets to create an XML file with data from NAV. Almost too easy!
So, how does the import work using the XML Buffer table? It is as easy as the export. You create the table as a temporary variable and just use the function called ‘Load’ to load the XML file into the XML Buffer table. The records in this temporary table can then be processed as any other records. There are some predefined functions in the table to find the child notes, attributes, etc. but when I did this I found it easier just to go through the records in the table, something like below (which might not be the best written code but at least an example).
So that was quite easy as well.
For the CSV export I basically just create a new function that’s very similar to the one for the XML export; but instead of the XML Buffer as a temporary table variable I use the CSV Buffer table (table 1234, cool table number btw ). The syntax is slightly different, you use the ‘InsertEntry’ function to add data by specifying the line number, field number and value. And then the ‘SaveData’ function to create the file. The ‘SaveData’ function is called with a file name and field separator, in the below example I use a comma as a field separator, I think something like a TAB is much better, but it seems like you will have to modify the CSV buffer table itself to get that.
Importing data from a CSV file using the CSV buffer table is also very easy. You use the ‘LoadData’ function to import the data from the file into the temporary table. Note that in addition to the file name you also specify the field separator. Once the data is in the table you can process it, the table only have three fields; Line No., Field No., and Value. The code to import the data and then process it could look something like below.
Also nice and simple.
So, the question now is when to use those two tables instead to creating an XML Port. To me if it is a simple structure of the data that should be exported or imported and the amount of data is fairly low then I would probably use the buffer tables, as you can see above they are very easy to work with. If the export or import are more of a complicated nature I would probably use an XML Port, you just have some more configurable option with that. An XML Port will most likely also have better performance if you are handling large amount of data, this since the buffer tables created one record per field in a temporary table which is not a very sufficient way of doing it.
An XML Port also have the advantage of being able to be passed through a codeunit that’s exposed as a web service. So if that’s the requirement, the an XML Port would be the obvious choice.
Personally I think I will use the two buffer tables quite frequently and I think it is a nice addition to Dynamics NAV.
Feel free to share this post if you like it. Cheers!
Olof Simren - Freelance Microsoft Dynamics NAV Expert
Naviona - Microsoft Dynamics NAV Partner
Microsoft Dynamics NAV 2017 was released last week. I have installed it and poked around in the new functionality a bit and there are some awesome improvements and new features. Through this blog post I share some of my thoughts on some of the new functionality.
The look and feel when first launching the windows client is more or less the same as with version 2016, and I was happy that it could co-exists with all my older installations of NAV (always interesting when installing a new version).
Below are some of the new functionality that I have looked into, starting with the parts that I think I will use the most when implementing Dynamics NAV.
The item attributes are for me probably the most useful feature that has been added to Dynamics NAV 2017. The attributes let you define and add different types of attribute to the items in NAV (things like length, width, diameter, voltage, torque, color, etc.., whatever you want basically). Those attributes could then be used when searching for items or on printouts. I don’t have a single customer that would not want to use this, that’s how useful I think this is. I have in the past done many different modifications and worked with several add-ons that offers this widely requested feature, so I am very happy that this is standard functionality now.
You basically setup your attributes that you want to use by specifying a name, type and unit of measure (the type controls what values you can enter).
For the attributes where the type is option you specify the valid item attribute values (which then becomes a drop-down list when adding attributes to items).
Note that attributes that are the option type does not have a unit of measure (for some reason the developer though that was not needed, not sure I completely agree).
Both the attributes and attribute values could be translated into different languages in a typical NAV fashion.
You then add the attributes to the items (and there is a fact box that can display them as well).
Finding items based on attributes are then done using the filter by attribute feature.
This is simple and super useful. I do think it is a bit funny how Microsoft have developed this though, normally you have a code and a description, where the code is the primary key. With the item attributes they have moved away from this concept and the attributes have an ID field that’s an AutoIncrement integer field that’s the primary key (and not displayed on any pages). And code have been added to the tables to check if the description have been used already when entering new attributes (otherwise you could end up with multiple attributes with the same name with this design). The attribute values then have two integer fields as the primary key, one being the attribute ID and the other being an AutoIncrement field. It might make sense, but for someone like me that’s been working with NAV for 15 years it looks a bit strange. But I am sure we will see more of this in the future (parts of the workflow, the events for example, that came with NAV 2016 also have some of this design that’s not using primary key fields that are displayed on pages).
The item category table have been made multilevel so you can define a hierarchy in the list of item categories. This kind of eliminates the need for using the product groups codes that’s previously was subgroups to the item category codes. Note that the default costing method and posting groups have been removed from the item category table (with the templates to creates items those might be redundant now).
This is a great addition as well, but what is even better is that you can for each of the item categories define what item attributes that applies. So, when a new item is created and the item category is selected then NAV populates the list of attributes that the item should have so that the user knows what attributes to enter.
This way you get a consistent set of attributes on similar items and it speed up the process of creating new items. On the topic of creating new items; there is still no ‘copy item’ feature, so for the millions of NAV users that are waiting for this, they just need to be patient. But, the item template feature that was introduces on the simplified UX pages for the small business roles in 2015 are now on all the pages, and that’s reducing the need for a copy function a bit.
General ledger accounts can now be categorized. To do this there are two new fields on the general ledger account card; Account Category and Account Subcategory.
A fairly small addition, but very useful. Now you can group accounts that are used for similar postings, something like revenue accounts can be grouped into types product, service, shipping revenue accounts and this can then be used as filters when running reports.
You also have the option to view the total amounts by the different categories.
This is probably one of the coolest additions that’s been added. It allows for sending notifications that will be displayed in a notification area on the page that the user is currently on. My brain is already thinking of how many great features that can be programmed to utilize this way of notifying users.
Below is an example of how a notification looks like in the windows client (there are some standard notifications displayed based on the data in NAV).
I will do a separate blog post about this soon, I think it deserves it and I want to explore the capabilities of this a bit more and learn how to use it in C/AL.
List can now be viewed as bricks by changing it from a list to bricks using the below button, this is only for the web client.
What’s displayed in the bricks are defined in the Field Groups on the table (same place where you define what fields that are displayed in drop downs), so you would need to change the table object to select what should be displayed. Would have been nice if it was part of the personalization instead actually.
I see these brick views more for touch screen devices, but let’s see, maybe it is something regular computer users will like as well. Time will tell…
A cancel function has been added to the posted sales and purchase credit memos. With this you can reverse credit memos that’s been created to reverse invoices (such as the ones that are created when you cancel a posted invoice). So to reverse something that’s been reversed.
Doing this will un-apply the posted credit memo from the invoice (if it was applied to an invoice) and create a new posted invoice that it gets applied to.
The incoming documents feature that works together with a Lexmark service to interpret documents such as invoices have been improved. It is mostly related to how the interpretation take place and a how to correct errors so that the service learns. Inside NAV there is now a new filter function on the list of incoming documents where the user can choose to see only documents that’s not been processed instead of the entire list each time.
I have not implemented this part myself anyplace yet, but I saw a demo at the Lexmark booth in the end of 2015 at Convergence in Barcelona and it looked like a good feature. Now that it’s been approved it is probably mature enough to implement.
A couple of minor improvements have been done to the payment reconciliation functionality in 2017. One of them is that it now shows the total amount in the payment reconciliation journal and you can drill into this amount and see transactions that’s have not been applied or reconciled.
The 2017 job module has received a facelift (its always been a bit behind to be honest). There is now a project manager field on the job card and the project manage role center have been altered to show information specific to the jobs the user is managing. This should get the project managers going on the jobs that are not doing that well.
In addition a job cost fact box have been added to the job card.
Some additional convenient features have been added to the fixed assets in Dynamics NAV 2017. There is a standard setup for creating new fixed assets. There are also some new journal features that allows you to post fixed assets purchase transactions. I have not looked into this that much so maybe there will be more details later. Fixed assets are not really my favorite part of the application.
A bunch of changes have been done to the contact management part for the 2017 version. Microsoft is promising a newly created integration to Dynamics CRM online that can be setup with a guide inside NAV. So, if you are using the contact management part of Dynamics NAV and would like to take advantage of the more advanced features that the Dynamics CRM on-line is offering then this should now be easier than ever and you should have a seamless coupling of the records in Dynamics CRM with Dynamics NAV. Even looks like you can view the Dynamics CRM data inside NAV.
In addition to the improved Dynamics CRM integration some of the functionality inside NAV have also changed. The most noticeable is that the wizard pages that existed have now been replaced by card pages, I never like those wizard pages anyway so I think this is great. One example of this is when creating an opportunity, it now looks like below.
Microsoft’s main reason for replacing the wizard pages with cards is that it now also can run in the web client (I guess it did not work that well before, never tried it before myself).
The mail merge feature that’s been around for years that allows you to create email templates in word and use it for mass emailing things like campaign information to contacts have been redesigned to use word reporting. For a daily use this might not be a big difference, but for a developer this introduces a whole new world of opportunities. The mail merge was very limited in its functionality (basically only enabled you to place some selected fields on a page), with the word reporting you can now write code that executes when the e-mails are created. A very nice addition in my mind.
Also the e-mail logging has received a rework. In the past the e-mail logging was always a bit tricky to setup but once running it provided some great visibility for the users into the sales channels since everybody with proper access could see emails between customers and employees. Now there is a wizard to go through to setup the logging and it is supposed to be a lot easier to get it running.
Partially built using the Notifications in the UI (which I will be describing more in a separate blog) the smart notifications gives you advice when you use the application. As an example; if you create a new sales invoice for a customer that have an overdue balance you will see the below notification.
Another example is when you close a sales order you receive a message saying that the order has not been posted (I am a bit skeptical to this one since in my world posting a sales order is not done by the same person that’s entering it).
Luckily this is configurable and each user can turn the features off and on through the My Notifications setup where conditions also can be applied.
I think this is a cool concept and I see a potential to create custom notifications to support how the business wants to operate and to reduce common user mistakes.
It looks like Microsoft have put a fair amount of effort to more tightly integrate Dynamics NAV with Office 365, probably part of the work for Dynamics 365 that’s also been released recently. The integrations with Office 365 includes an Outlook add-in that enables you to synchronize master data between Dynamics NAV and Outlook (so contacts in NAV shows up as contacts in Outlook etc. is what I am guessing) and some features that allows you to create invoices and from Bookings in Office. This is all great additions but what’s probably the best of all here is the Excel Add-in that allows you to both view and edit the NAV data in Excel (through an ODATA web service I believe), this I think is super useful. There was previously an un-official tool to do this that utilized the NAV web services, but now it is a standard feature.
Install the add-in and then you open Excel and connect to the NAV service through the Dynamics NAV Data Connector. You can the edit the records and have the connector update the data in NAV.
Dynamics NAV 2017 comes with several extensions that can be deployed, I will not go into the details but there is a bank feed extension that allows you to setup a feed from your bank, some kind of PayPal integration, a QuickBooks data migration and a sales and inventory forecast solution (using Cortana intelligence I believe).
All cool extensions, but what I would like to see is the localizations provided by extensions. That I think would be a huge leap forward. Everybody will then be on a W1 database and by using different extension you get the local functionality for your counties. And if there is a feature to turn on and off extensions by company then you can have a database for multiple countries. Maybe it’s just me that dreams about this.
I have added the Product Overview and Capability Guide and the Whats New in Microsoft Dynamics NAV 2017 to my white papers page, it has some useful information and links to additional material related to the new functionality in Dynamics NAV 2017. Those are basically the documents that I have used to research the new functionality. In addition to what I have found in those documents I have also bumped into some other changes (some which are quite interesting actually), I have described those below.
A lot of the pages have been simplified, mostly by setting a lot of the fields to be additional and also by removing and regrouping some of the fields.
Below is an item card for example, on this page a lot of the field have been set to be additional (so they only show up when you select show more fields) and more tabs have been added to group the fields (the Inventory and Price & Posting tabs below are new for example).
Another example is the ship-to and bill-to information a sales document. Instead of always showing all the field you now have options to select if the ship-to or bill-to address should be different from the sell-to address and only in those cases will the rest of the fields be displayed.
The package tracking number and shipping agent code have been added to the posted sales invoices. Noting big, but kind of useful.
There is a new function that allow you to create a purchase invoice based on a sales order. You select this and choose what items it should include through the below dialog, then you select a vendor and NAV will create the purchase invoice for you.
The user personalization has been extended with a time zone field (not 100% sure where this apples and where the regional setting on you computer can’t be used to be honest).
The ToolTip property that came with the previous version have now been populated on a lot of the fields (what a job that must have been ).
This then shows up when you hover over the field or action item.
There is a new property in the development environment that can be used to define an application area for a page field, page part, page action, or MenuSuite item.
This then works together with the application area setup which can be defined for a company, profile or user. It is not something that is mandatory to use, if you leave the setup blank then everything will be displayed.
As with the new ToolTip property this is not something you can define on the table object, which I think is strange.
You can have the quantity defaulted to 1 on sales documents when the no. field is entered. This is something that can be activated in the sales & receivables setup.
There is a new feature that can create an item for you automatically using the item templates when you enter a description in the no. field on a sales document that does not exists in the item list. Sounds nice and dangerous at the same time, doesn’t it?
You select Item as the Type, then you enter a description that does not exists in the item list in the no. field and tab out.
NAV will then display a dialog like below where you can select to have a new item being created using an item template, this will create the item and display the item card. When closing the item card that item number will be added to the sales line. So now the sale person can sell anything he/she likes!
This feature can be activated/deactivated in the sale & receivables setup.
Some pages have fields with multiple lines where you can copy/paste descriptions into the field. One example of this is the Work Description field on the sales invoices. The data for this field gets saved in a BLOB field, so I guess it is nothing new other than I have not seen this from Microsoft before like this.
This blog post became a lot longer than I initially thought, the more I dug into the functionality the more stuff I found and the longer the post became. I am sure there are new great things that I missed when writing this and some of the above also needs some more details around it, but I needed to draw the line somewhere otherwise this post would have been 5 time as long that’s how many changes NAV 2017 brings.
Going forward my blog posts will be done using Dynamics NAV 2017. Let me know if you want to upgrade to NAV 2017 we are always happy to help!
Have a great day!
Production orders in Dynamics NAV allows you to consume both less and more than what’s defined on the components and to output both less and more than what’s defined on the operations in the routing. There is no check when you post, which is nice (sometime I which it was like that on sales and purchase orders as well, but that’s a topic for another post). But when you post more than you wanted you need to be able to reverse it. Luckily reversing production output and consumption is easy if you know how to do it (if the production order has not been finished that is). This blog post describes how to reverse output and consumption on production orders, with and without item tracking.
There are two common scenarios for this (other than someone mistakenly posted more that they should); first one is if you have a process where you issue material against a production order and then return some of it to stock (could be a forward flushing of components for example) and the second one is if you output something that does not meet the expectations (e.g. quality rejects it and it needs to be scrapped). In both those cases you want to do the reversal transactions against the production order to get a correct costing, instead of just doing separate journal entries.
Let’s start with how to reverse consumption.
The trick to reversing consumption is to simply post a consumption with a negative quantity, this will bring the component(s) back into inventory. It can be done in either the consumption or production journal, in the case below we are using the consumption journal where the Order No., Order Line No. and Prod. Order Comp. Line No. are first selected, this brings in the item number and description. After this you enter a negative quantity for what you want to bring back into inventory and make sure the location and bin code are where you want it to end up.
Note the Applies-from Entry, this field can be used to make sure that what goes back into inventory have the same cost as what went out. Not a difference if the component(s) are using the standard costing method, but important if they are using the FIFO or average costing method. What you are selecting in this field is the initial consumption transaction you want to reverse, NAV then links the two transactions and makes sure that if the cost of the initial consumption is changed the corresponding reversal is also changed accordingly.
Posting a negative consumption creates item ledger entries like below. The type is still Consumption, but the quantity is positive and the ledger entry is open.
On a side note; if you have posted multiple consumption and no output and you want to reverse all the consumption then you can use the Calc. Consumption function in the consumption journal and change the Calculation Base On to Actual Output.
NAV will then generate a journal line for each component that’s been consumed with the corresponding quantities being negative (since it is looking at the output which is 0 and suggested what to adjust for the consumption to match this output).
The next one is to reverse consumption for components that are tracked, in this example we are using a lot tracked component. Entering the journal is done the same as before except that the Applies-from Entry field is not selected.
Then as normal with tracked items you need to go to the item tracking lines to enter the lot number(s). Note that since this is an inbound transaction the lot number needs to be entered manually, then the Applies-from Entry is selected (same way as for the component without item tracking but this time in the item tracking lines page).
Posting the above then creates item ledger entries as below.
Output can be reversed the same way as consumption; by doing a transaction with a negative quantity. The difference here is that you also have the capacity costs to potentially reverse. Reversing the output can be done in both the production and output journal, in the below case we are using the output journal where the Order No., Item No. and Operation No. are first entered. Then the output quantity is entered as a negative quantity and if you also want to reverse some of the capacity then you can also enter the setup and/or run time as negative numbers.
Note the Applies-to Entry that’s in this case mandatory and it defines what output item ledger entry to reverse. If you are reversing the output for an operation that is not the last one in the routing then you don’t need to enter this value.
If you have the case that some of the output is rejected by quality, then the reversal could be done by entering a negative quantity in the output quantity field and a positive quantity in the scrap quantity field. This way some of the previously posted output is turned into scrap and if you backflush any componants then this is important since you probably want the backflush of the components to be based on the total output including the scrap.
The item ledger entries created when posting the above output journal are as below.
And reversing an output also create capacity ledger entries, the quantity here refers to the time (minutes in this case).
Note that if you want to the setup and run time to default when you enter the output quantity and scrap then this blog post could give you some inspiration; Posting of Actual vs. Expected Production Time.
If the item that’s being produced is lot or serial number tracked, then you obviously also need to enter the lot or serial number that’s being reversed. The other difference compared to reversing the output for not tracked items is that you enter the Applies-to Entry in the item tracking pages instead of in the journal. As before this is only required if you are reversing the last operation.
This involves doing a purchase credit memo for the vendor, it is a commonly asked questions and I will save this for a separate blog post. Which will be a part 6 in my subcontracting series (the other parts are here if you are interested in subcontracting; Part 1, Part 2, Part 3, Part 4, Part 5).
This is normally a hot topic, and there is no perfect way of doing it. If a production order has been changed to finished, then you cannot post any more transactions against it. NAV considers it done and have calculated the actual costs and reversed whatever there was in WIP and finalized it from a costing perspective (see production order posting into general ledger for more information). So it is highly recommended that the transactions against a production order are reviewed before finishing it, using the statistics page could help with this.
So, reversing a finished production order typically involves doing journal entries and from a cost and item tracing point of view it will never be perfect (since the costing and traceability in NAV is per production order line and doing something besides this will not affect it). What I have done in the past is a function in the item journal by which a user can select a finished production order and the journal will populate with lines that are as good as you can get from a costing and traceability point of view. This itself deserves a separate post, so stay tuned.
Remember to share this post if you find it useful.
This blog post is about the return merchandise (or material) authorization process in Microsoft Dynamics NAV, this is another topic that is more or less always discussed during Dynamics NAV implementations.
The typical scenario is that a customer calls and wants to return a product that they have purchased to get a refund, replacement product or to get it repaired. For this they need an authorization, an RMA.
So, how is this done in Dynamics NAV? The short answer is by using a sales return order, which is similar to a sales order but it goes the ‘other way’ and is received instead of shipped and creates a credit instead of a debit on the customer. That sounds easy! Well, it is a bit more involved than that, because you have to take care of the product once it is received back and make a decision about what to do with it. In a lot of cases this involves several of the departments within the organization (customer service, quality, manufacturing, purchase, accounts receivables, etc.).
The below illustration is something that could be used during implementations to explain the scope of the process.
Each of steps are described below with some tips that I hope will be useful for you.
It starts with a customer that initiates a return by requesting an authorization to send the product back, this could be a phone call (either friendly or angry ) or an e-mail. In Dynamics NAV you then create a new sales return order which will give you the RMA number that should be used by the customer to return the product. To make it clear I normally recommend to setup the number series for sales return orders to ‘RMA-00001’ (or something similar) since the term RMA is more known than the sales return order term (I love prefix on number series by the way). On the printout of the sales return order that is sent to the customer; call it Return Authorization instead of Sales Return Order (less confusing for the customer this way).
When entering the line(s) there are two thing to consider; (1) what location code it should be returned to and (2) the return reason code.
The location code should be a separate dedicated return location, this way you are not mixing returned products with your regular inventory and if you run any type of planning or MRP then the product being returned are not considered supply that nets the demand. If your regular location is called ‘BLUE’ then create a return location called ‘BLUE-RET’ (as an example). This location can also be refereed to as quarantine, quality control, on hold, etc. and could also be used for setting aside products that you don’t want to show up as available in the availability logic.
The other effect of having separate return location is that you can setup a separate inventory account where the value of returned products are posted to in the balance sheet.
Note that bringing the inventory back into a separate location does not work that well with the exact cost reversing feature that Dynamics NAV has since it want you to get the product back into inventory with the same cost as it was shipped by linking the two transactions (the original shipment and the return) and this requires them to be on the same location. My preference is to have this feature turned off and train the users to be good enough to understand when to select the apply-from entry no. (e.g. when making corrections to postings) and when it is not needed (and how the costing works on return orders).
The return reason code should indicate the reason why the customer wants to return it, which is not always the reason the sale failed. This is a mandatory field and you can setup as many codes as you want. Note that there are some additional options that you can configure for each of the codes, one of the options being if the returned product should have zero inventory value, you should know that this option does not work with standard cost items.
It is good to know that this list of return reason codes are shared between the sales return orders and the purchase return orders (just something to think about when you define the list).
For the amount you should enter what you expect to credit the customer, this value can be changed later (if you for example reserve the rights to inspect the returned product before you decide what to credit the customer or if the freight should be deducted, etc.).
Once the sales return order is entered it gets released and the printout is send to the customer for them to include it with the products being returned (I normally add text like ‘return a copy of this page with the product’ on the printout, this makes it easy when it comes to receiving and finding the right order to receive).
The receiving process when the product shows up is the same as for other types of orders that are received (purchase & transfer orders). Note that the different options for receiving are configured by location, so having a separate receiving location also allows you to have a different receiving process if required. If you are using warehouse receipts (my favorite configuration) then the just receiver need to choose between the two locations depending on if it is a return or a regular purchase that is received.
When the product have been received there is typically an inspection taking place and based upon that a decision about what to do with the product is made (I refer to this as a return decision). It can either (a) be subject for rework, (c) be returned to regular stock, (c) send back to the customer again (popular for the customer ), (d) be scrapped or (e) be returned to the vendor.
Note that Dynamics NAV does not natively have a quality control module, but there are a handful to choose from (Naviona sells one as well) that could be used to capture the result of an inspection and the determined fault reason. The other option is to use a separate quality control software (or a good old Excel spreadsheet).
Depending on what decision that is made the next steps in Dynamics NAV are obviously different (see flow chart above).
If the returned product needs rework (e.g. need to be fixed) then a rework production order should be created. The best way of doing this is to create a production order manually for the returned product on the return location and then go to the components and exchange them against the returned item and add any components that are needed for the rework. The components needed should then come from the regular inventory. In the below example a bicycle have been returned by the customer and the rework involves replacing the lamp, so the returned bicycle becomes a component that is consumed from the return location and the lamp becomes another component that is consumed from the regular location. The output of the production order is a bicycle as well that goes into the return location.
Also the routing needs to be altered to reflect how it is going to be reworked/fixed. To simplify this you could have a separate generic rework routing created (that includes something like a rework work center with some costs attached, which all can be changed on an order by order basis). What you do then is just to replace the routing no. on the line and refresh the production order and only calculate the routing.
In a FIFO environment the finished product of a production order like above will have the cost of the returned product plus the additional components plus any of the rework operations capacity costs. In a standard cost environment the finished product will have the same cost as the original finished product and any additional components or rework costs will be a variance posted into the P&L (note that the cost of the bicycle component will be considered material cost even though there is a labor and overhead portion in it).
Once done you release the production order and it is completed like you complete your regular production orders. The output of the finished product will go into the return location from where it can be shipped back to the customer.
Note that if you are handling a make to order or configure to order type of product then the sales order is maybe needed to be created before the production order (if it requires a configuration on the sales order or a link between the sales order and production order).
If the product that is returned from the customer is a good product then it could potentially be returned to the regular stock. This can be done with an entry in the reclassification journal to move it from the return location to the regular location. If you are using directed-put-aways and picks (also known as advanced warehousing) then this process becomes slightly more difficult and needs transfer orders.
If you are using bins then you obviously need to enter those as well.
If something is going to be sent back to the customer (which is common) then you need to create a sales order process it. One way of doing this is to use the feature called Create Return Related Documents that you have on the sales return order, this will create a sales order for the same customer with the same item(s) etc..
The other option would be to use the Copy Documents function and from the sales order page copy the sales return order.
In both cases you need to be aware of the location code on the lines, if you are returning something that have been reworked (using the rework process described above) or if you are simply returning the product as it was received then you want to return it from the return location. If you are sending a replacement item or a completely different item it should be sent from the regular inventory location.
If the item returned from the customer should be scrapped then you can just do a negative adjustment in the item journal. I always recommend using the reason code when doing those types of transactions, but the fact that the adjustment is made on the return location gives you a hint on why it was done when you two years later are looking through the transaction details and wondering why you made the adjustment.
You can also use a separate general business posting group if you want the cost of the product to be posted against a specific general ledger account (and/or a use a dimension to separate different types of adjustments from each other).
If the item returned from the customer is a purchased part then it should potentially be returned to the vendor. The Create Return Related Documents feature at the sales return order page can also be used to create the purchase return order to send the product back to the vendor.
As you can see from the screenshot above, it can also create a new purchase order in addition to the purchase return order, the purpose of this is obviously if you want the vendor to send you a replacement. Kind of nice that that documents can all be created at the same time like this.
The shipping process for the purchase return order and the new sales order is the same as any other shipping process that you have in Dynamics NAV. And the invoicing process is also the same. One thing to be aware of when invoicing is that the invoice is applied to the credit memo.
That’s all for the RMAs, comments below are always welcome as well as sharing this post on social media using the share button below to the right.
Do you know that you can create sales quotes without having a customer created in Microsoft Dynamics NAV? It’s been like that as long as I can remember but surprisingly many users and also consultants don’t know this and I have seen lots to workarounds with generic ‘quote customers’, etc.
This is a quick blog post describing how you can create sales quotes in Dynamics NAV without having a customer record. This is especially useful for companies that are doing a lot of quotes to prospects that might not turn into customers. With this method you then don’t ‘muddy’ the customer list with companies that are not customers.
The overall concept is that you create a sales quote for a contact instead (leaving the customer no. empty on the quote) and a customer record will be automatically created using a customer template once the sales quote is turned into a sales order. Sounds great, right?
As a start you need to have whoever you are quoting to as a contact in Dynamics NAV, so I start with creating a basic contact record like below (more or less just a name and the address).
Now that you have a contact there are two ways to create a sales quote; (1) select sales quotes from the contact card and then click new (which will automatically add the contact to the sales quote) or (2) go to the list of sales quotes from the main menu, select new and add the contact in the sell-to contact no. field. With both methods you end up with a sales quote where the sell-to customer no. is empty (like below).
I know it is a bit confusing that the sell-to customer no. field have a red asterisk in it (those are supposed to be for mandatory fields), I think that’s something Microsoft should fix.
The next step is then to select the sell-to customer template code on the sale quote, this code is something that defines the posting groups, tax setup, payment terms, price groups, dimensions, etc. which are normally the things you find on a customer card. You can setup as many customer template codes as you need to cover the combination of those fields that you need to quote to new contacts (which normally is not that many). In my case I have a US-DEFAULT one that I use for all US contacts that I quote to. When this is selected you can see that the sell-to customer no. field become non-editable and payment terms, etc. are populated on the quote.
A customer template card have the below options (note the dimensions and invoice discounts in the ribbon).
It is also worth knowing that there is a bill-to customer template code on the invoicing tab, this corresponds to the concept of having one entity that you are selling to and one that gets the invoice (see bill-to vs. sell-to customer). So theoretically you can have a contact that you are quoting to and another contact that is the billing entity, but I will keep it simple and leave then the same for this example.
Now we have a sales quote with a complete header and we can enter the lines that we are quoting. In my case I am quoting some bicycles to my contact Mikes Bikes.
Now the sales quote can be printed and sent to the contact, completely without having to create a customer record. Nice!
If the contact now comes back and wants to purchase what you have quoted, you convert the quote into a sales order using the make order function in the ribbon of the sales quote.
During the process of converting the sales quote to a sales order Dynamics NAV recognizes that there is no customer and displays a messages asking if you want to create a customer at the same time.
If you select yes on the above message the system will automatically create a new customer based on the default customer number series and the information on the contact card (and link the two), apply the customer template you selected on the sales quote, add the customer to the sales quote and convert the sales quote to a sales order. Wow!
The final sale order then looks like below (with a customer record).
It is worth knowing that if you have multiple sales quotes for the same contact and one of them is converted to a sales order, then Dynamics NAV is smart enough to also update the other sales quotes with the newly created customer number. in addition there is also an action item in the ribbon of the sales quote to create the customer if it is needed to create a customer separately from them function that converts the quote to an order.
So, if you do a lot of quotes to companies that are not yet customers and not all of the quotes turns in to orders then this method could potentially be used to keep the customer list free from ‘non-customers’ and to simplify the quote process (since there is less to setup on a contact compared to on a customer).
That’s all for this post, see you next time! Remember to share.