Problem in Cumulative Update 19 for Microsoft Dynamics NAV 2013 R2

Because of an inconvenient change of data schema in the application, the application bits are excluded from Cumulative Update 19 for Microsoft Dynamics NAV 2013 R2. A new release of CU 19 without application bits was released today, May 28. For more information, see Cumulative Update 19 for Microsoft Dynamics NAV 2013 R2 has been released.      

If you downloaded the initial release of CU 19 (released May 11), and you still want to implement it despite the problem in the application code, please read the following information. 


Cumulative Update 19 for Microsoft Dynamics NAV 2013 R2 has a problematic change that will affect your implementation of the cumulative update.

The problem is in table 114, Sales Cr. Memo Header, where the number of field 1300, Canceled, is changed to 1301. A typical partner development license does not allow field changes, so you will run into the problem when you try to import CU 19.



There is no good resolution at the moment (we are working on it), so here are two different ways to work around the problem.

Workaround 1: Rename the old field and merge the new field. Write code to copy values from the old field to the new field, as follows:

  1. Open table 114 for editing and rename the Canceled field to "Canceled 2".
  2. Create a new object (for example a codeunit) in an allowed range.
  3. Create a variable named SalesCrMemoHeader with datatype Record and subtype Sales Cr.Memo Header.
  4. Copy/paste the following code:

    SalesCrMemoHeader.SETRANGE("Canceled 2",TRUE); SalesCrMemoHeader.MODIFYALL(Canceled,TRUE);

    SalesCrMemoHeader.MODIFYALL("Canceled 2",FALSE);

  5. Run the new object. All data will be transferred from the Canceled 2 field to the Canceled field.



You will not be able to remove the old field.

In table 112, Sales Invoice Header, field 1301, Canceled, is a FlowField that uses field 1301 in table 114 in its CalcFormula. Because table 112 is not part of CU 19, the CU will fail if you try to compile table 112 because it points to non-existing field 1300 in table 114.


Workaround 2: Import table 114 as a .fob file. (The partner development license does not allow deletion of an existing field if you import the table as a .txt file.)

  1. Save the data in custom fields.
  2. Import table 114 as a .fob file. (Note: This will remove the custom fields.)
  3. Re-apply any customizations that you may have lost.
  4. Move the data back.


Sorry for the inconvenience.

The Dynamics NAV team

Comments (5)

  1. Kenneth Fuglsang says:

    Speaking as a partner, you just hit the nail on one of our recurring issues – license restrictions on fields/objects.

    This has especially become an issue since the monthly CU's started appearing and the new PowerShell merge commandlets.

    The merge commandlets lets us merge new CU's into our customers' solutions very easily, but the merged text fields cannot be imported, and thus we did not really gain anything from it.

    If this was possible, it would also significantly decrease the time needed to implement ISV products.

    Consider this my wish for Christmas 😉

  2. I concur says:

    Yes, please consider reworking the license protection method of base objects.

    A NAV partner is a trusted, well.."Partner" of MS and the all the time spend on working around the license restricted benefits no one.

    I shall avoid CU 19 for the moment 🙂

  3. Arend-Jan Kauffmann says:

    Latest CU of NAV2015 does not have this change. Why would you change the field number in NAV2013R2 but leave it the same in NAV2015?

  4. Jens Glathe says:

    Thank you for the heads-up. A good resolution would be to revert this change and re-release CU 19.

    +1 regarding license restrictions, BTW. This is a major pain, and costs extra days (!) in upgrade projects. It is not unusual that you go from a NAV Classic Client version to NAV2015 directly, and current source control systems like mercurial and git allow a source code merge. This leaves you with text files which are (most of the time) well-formed, but you can't import them because of license restrictions:

    – Fields that are no longer used and need to be deleted

    – Fields that are new and need to be created

    We have to work around this by creating a "MergeMagic" .fob that can be merged with the merge actions of the Import Worksheet. These functions are really picky, most of the time you need "washed" (fields only, no C/AL) versions of the tables. Sometimes on both sides, source and target.

    The fun really starts when more than one AddOn with their own fields are in the mix. You can have situations where you can only leave some of the old fields disabled in the table, because you can't build a .fob version that has all desired fields and none of the obsolete ones. So… as a NAV partner, I would like to have a better way regarding text imports.

  5. einsTeIn.NET says:

    The issue regarding the Field ID also applies to T124 compared to T122.

Skip to main content