The Kong Company (stylized as KONG) is a global organization based in Golden, Colorado, and was established in 1976 after founder Joe Markham began experimenting with various dog toy designs. He has since grown the company into the worldwide powerhouse it is, with KONG continuing to evolve and deliver on its commitment to manufacture quality toys and treats for both canines and felines.

Challenge

The software tools and processes that worked well for KONG at one time were being challenged as KONG experienced growth. When it came to KONG’s warehouse and distribution centers, being able to maintain an accurate count of inventory was becoming increasingly difficult. Using its old system, KONG would perform very few cycle counts due to the time involved in counting. This would result in inaccurate inventory records.

KONG has grown as a company that encompasses worldwide distribution centers, and as such has outgrown its previous system consisting of QuickBooks accounting software, Microsoft Excel spreadsheets and paper-based processes. While KONG’s head operations in Colorado would normally manage the inventory levels at all their remote locations, a lack of visibility into the company’s global distribution centers made it difficult to know the exact status of each remote location. Distribution centers, for example, would end up carrying more stock than necessary because there was little visibility into real-time inventory levels; KONG’s head office would offset this lack of data by overstocking to eradicate any fears of not being able to fulfill some orders.

Additionally, warehouse and inventory management was time intensive where inventory counts would often take an entire year to complete, with reconciling and resolving count errors becoming a daunting manual process. The staff would count 1/12 of their bins a month, which would take approximately 16 hours, and this further reinforced the growth challenges the company faced with regard to inaccurate inventory.

The task of receiving stock also exhibited inefficiencies as distribution centers received container-loads of goods; an entire container needed to be received and put-away before picks could be done, and this process resulted in the delay of order shipments.

What’s more, KONG’s current internal processes made onboarding of new staff time-consuming and complicated, often taking up to two weeks of training in order for staff to perform inventory counts.

Put succinctly, while KONG’s current software and processes worked well at one time, they are unable to keep pace with the growth of the company.

Solution

KONG integrated Insight Works’ Warehouse Insight and Advanced Inventory Count add-ons for NAV, replacing its homegrown ERP system with Microsoft Dynamics NAV. NAV coupled with the Insight Works’ add-ons ended up being the perfect fit, yielding all the warehouse management system functionality KONG needed and wanted.

To complement the integration, Insight Works procured Datalogic Falcon X3+ handheld mobile computers, providing KONG with a tailored solution for demanding environments requiring real-time transaction visibility. These mobile computers ran Insight Works’ Warehouse Insight and Advanced Inventory Count modules helping connect NAV to KONG’s warehouse floor for inventory counts, picks, put-aways and more.

Warehouse Insight brings mobile device integration to a warehouse setting, while Advanced Inventory Count simplifies inventory and cycle counts with comprehensive data entry, reconciliation, posting and analysis tools.

Because KONG products are pre-packaged for retailers, everything already had barcodes – the Insight Works NAV add-ons made it simple to add scanning capabilities to the new NAV ERP environment. Barcode-enabled pick lists and the ability to create barcode labels for bins rounded out the process, with KONG’s remote operations now being able to access Microsoft Dynamics NAV via Citrix desktop virtualization.

The new ERP solution was initially rolled out at KONG’s Australian distribution center located in Dandernong South, Victoria. The test phase proved successful and plans are underway to roll out the solution globally to KONG’s entire operation network. Stuart Robertson, KONG’s Warehouse Manager in Australia, was tasked with testing and using Microsoft Dynamics NAV within a live environment.

Results

Primary Benefits: Overall Time Savings When Counting Inventory

Counting 900 bins using KONG’s previous system required 144 person-hours (18 work days); using the add-ons from Insight Works, the same number of bins were counted in 12 person-hours (1.5 work days), saving 132 -person hours and reducing count time by over 90-percent.

Because cycle-counts could be performed quickly, KONG was now able to institute weekly cycle counts resulting in maintaining accurate inventory levels.

The Insight Works solution enabled KONG to increase inventory management efficiencies. Significant labor cost-savings were realized, staff time was re-allocated to more productive tasks, customer satisfaction increased and capital resources were used more efficiently.

Secondary Benefits at a Glance

Insight Works’ add-ons delivered a myriad of general benefits to the KONG operations, including:

• Ability to efficiently perform weekly cycle counts.
• Ability for multiple people to simultaneously perform inventory.
• Data recorded in real-time.
• Significantly reduced counting errors using handheld mobile computers.
• Count error details corrected quickly with real-time dashboard reporting.
• Reduction of “orders shipped” delays.
• Reduction of inventory levels due to head office visibility into real-time metrics.
• More accurate and timely shipments.
• Quick staff onboarding via the user-friendliness of the Insight Works’ add-ons.

Learn more about switching to barcode scanning in the warehouse, download the white paper Keeping the Physical World and the Virtual World in Sync.

One of the goals of Microsoft is to turn all their many localized versions into Extensions. They are taking their own medicine so to say.

Just as many customers find that upgrades are a pain when they have a lot of customization's, so does Microsoft. Every time there is a new release, they also have to go through the same pains when upgrading their 17 localization's from W1. Something they do for all their cumulative updates for NAV 2015, 2016, 2017 and now NAV 2018, every month. Even with a lot of automation, both of the merging process and testing, then this is a time-consuming task. Even for Microsoft.

Coming from Denmark, I will be one of the first to meet this in live action. As the first county, most of the Danish localization's have been turned into extensions.

The only change not already an extension is our national OIOUBL e-Invoicing, which is required by anyone invoicing our government on any level. It counts most of the total changes in the DK version. But all our other smaller specialties are turned into extensions.

We have three Danish localization Extensions. A Payment and Reconciliation Formats (FIK), Tax File Formats and a Payroll Data Import Definitions extension. The first support our national FIK banking payment standards.

How did they do it?

The interesting here is not really the functionality, but how did they do it? How did they turn their customization into an extension? We can know, because they have also shipped the source code for these extensions. A partner or customer could make their own extended versions of this functionality. Possible with some work arounds, as they still use functions not available for the rest of us.

If you like me have embraced the new Docker container images, then you will have to go to aka.ms/navgetready to download the DVD from there. In the DVD of the Danish file we have FIK, ImportDKPayroll, VATReportsDK, each with the compiled *.APP file ready to publish (already published in a demo database) and a source folder containing “the source code”.

Payment and Reconciliation Formats (DK) Extension

FIK is more interesting. It has a little of each, fields, pages import/export formats. So let’s look at that one first.

I created a new project in VSCode, copied the content from the source folder in my new AL project folder. Then I copied in the launch.json for my server. I have tried some of the other “example” extensions on the DVD before, so I didn’t get disappointed too much when I found out that this is still the case. It does not compile. A lot of “The type of Method ‘x’ cannot be used for ‘Extension’ development” errors. So, for now it will just serve as an example.

The extension as one table 13624 FIKExtension, with a two fields. Code and IsUpgraded. No pages for this table, as it is only used by the setup codeunit. Same codeunit I was really interested in. How did they move the data from the old database fields into the extension?

I had expected a subtype install codeunit with the a OnInstallAppPerDatabase or OnInstallAppPerCompany. But neither are found.

I had also expected that they had been using the “Obsolete Fields” functions, which allows you too remove custom fields over several releases, by first marking them Obsolete and the reason, for then moving them later.

That’s not how its done here. What they did do was to remove the custom fields in the Upgrade toolkit fob. Here for example the fields are moved from the Vendor table to an UPG Vendor table.

The app in it’s codeunit 13655 “FIK Demodata”, has an event subscriber for Codeunit 1 OnInstallAppPerCompany.  This subscriber call the DataMigration codeunit, where the function move country fields in the 13650 range of the upgrade tables, to the same 13650 range in the apps extension table.

    local procedure MigrateVendorFields();
    var
        Obj: Record AllObj;
        Vendor: Record Vendor;
        UPGVendor: RecordRef;
    begin;
        if Obj.Get(obj."Object Type"::Table,104038) then begin
            UPGVendor.Open(104038);
            if UPGVendor.FindSet then repeat
                if Vendor.Get(UPGVendor.field(1)) then begin
                    Vendor.Validate(GiroAccNo,UPGVendor.field(13650).Value);
                    vendor.Modify(true);
                end;
            until UPGVendor.Next = 0;
        end;
    end;

A rather simple process. One could easily do it the same way with any other custom change, where you’ve added new fields to an existing table. The example above is changed a little, as it did use the Object table. But that’s not available for Extension development. Instead here we can just as well use the AllObj table. It is worse with some of the other codeunits, who uses a lot of functions not available for Extensions!

The FIK extension handles special Danish FIK payment reference codes. It’s a payment standard with roots in the Giro payment code. A short for common payment card, which was a standardized OCR readable payment slip, which was commonly “pre-printed” on invoices. Today the cards as such are mostly gone, only remaining requirement is the payment reference. It could for example be +71 <000007545022202 +12120108< - a combination of payment type, a reference with checksum and the vendor’s Giro number.

There are no reports in the extension, so the next question was how NAV prints the reference on the invoices? Using events of course. In the sales invoice header table, we have two event publishers: OnGetPaymentReference and OnGetPaymentReferenceLbl.

A major part of the extension are the Danish bank import and export formats. These were introduced together with the Data Exchange framework and NAV 2013 R2, as a feature focused on their Dynamics C5 customers. Here C5 2014 was Microsoft’s first (second if you count Navision Entrepreneur) attempt to create functionally downgraded and simplified version of Navision. And no integrated online banking would be a major point of failure for most customer in the look for a low end SMB product.

In the Extension, these XML format definition files are inserted from text labels.

These labels are inserted into TempBlob and imported as XML. An ok solution for a once off, but personally I wouldn’t like to debug format errors in the code.

Danish Tax Report Formats Extension

This Extension does not contain any fields or tables. It does contain a number of page extensions which strangely removes the visibility some of the fields required for EU Intrastat reporting. I do know that the same fields have always been hidden in the DK version, just never knew why.

It setup a number of EC Sales List/Intrastat VAT report configurations.

Again, this Extension can also only server as an example, it cannot be build into your own app. It’s main functionality is to export the special versions of the EC Sales/Intrastat reports. Old fashioned fixed length flat files. Which of course are exported to FILES. Something we are prevented from doing from VSCode today. But my guess that Microsoft’s internal license does not come with the same limitations as my normal NAV developer license.

Danish Payroll Formats Extension

The last extension is again much simpler. No fields, no tables, two pages, a codeunit and an XMLport. Plus a test codeunit.  Data exchange formats are not defined using locked labels, but by directly “hard-writing” the definitions into the stream, line by line. I’m very happy to see that problems with our Danish special characters ÆØÅ, no longer have any issues. Our Ø (oe) used to give codepage issues.

Still a lot of localization's in the DK version

The Danish version of NAV, despite these three Extension, is still loaded with localization's. Still 187 localized objects, compared to 245 in NAV 2017.

Microsoft also have to turn the OIOUBL e-Invoicing functionality into an extension. Personally, my hope was that they would build something around the PEPPOL functionality. Both are OIOUBL based, but with the big difference that PEPPOL allows for both exporting AND importing documents. The Danish OIOUBL functionality only allows you to export documents. And with it’s currently over 180 changed objects, then it’s current functionality is very “invasive”. Even if it’s changed into an Extension, then it would still have fields and functionality all over the place.

I hope that reason this is not released as an extension by now, is that Microsoft are refactoring this functionality before releasing it.

Conclussion

Personally, I'm thrilled about these new extensions. Not so much because they are special or fantastic. But because they allow me easily to remove them again, or simply not install them.

Most of my Danish NAV clients would never use NAV's own banking functionality. Instead they use the add-on which more or less have been the Danish NAV standard since the DOS version, where it was called NaviBanking, now Payment Management from Continia. Only reason I have had not to recommend PM to anyone was that it was very invasive (touched a lot of standard objects). But soon (I have heard) they will also have PM as an extension. So really no need to have the FIK extension, PM does the job much better and more automated.

Same with the still to be released OIOUBL Extension. While this is truly a most have for companies doing business with the government, then a lot of companies do not. And it have plastered pages like sales orders and invoices etc. with fields.

But hhe future direction is clear. Some years down the road, then we will only have the World-Wide version. Localization's are "just" Extensions, either coming from Microsoft or ISV's.

From someone who have worked a lot with international NAV projects this is sweet music in my ears. Where dealing with global core databases, localization's and translation's used to be something which both required long country by country analysis and development, then going forward that's not really going to be that important. We would be able to have one global database based on W1. And with country based tenants we would be able to load the local extensions we needed.

Right now this is only the DK version, but by the time we get into the spring of 2018 and the next release, then a lot more country localization's will have been turned into Extension.

PS: Different development teams?

When looking at the three Danish extensions, then it’s obvious that Microsoft so far have not adopted any internal standards for neither object or file naming, nor have spent much time on the code.

It really looks like it has been three different companies or teams who have created each of them.

Most actual code is just copied from the previous country into the new app. No refactoring or code clean up. Not even spelling errors have been fixed. These becomes very visual in VSCode, if you have a code spell checker extension installed.

NAV 2018 SERVICE OPTIONS RECAP

In NAV 2018 there are many new options related to the NAV Service; some of them have already been introduced with the latest build \ cumulative updates for NAV 2016 and NAV 2017 and only updated \ modified; others are new and introduced by this release.

NEW POWERSHELL CMDLETS

There are also new powershell commands related to restarting and managing services.

CHANGE NAV SERVICE VALUES WITHOUT RESTARTING

The most interesting thing is as written in the “What’s New” it is now possible to modify the parameters of the service without restarting the instance. Great especially for multi-tenants environments. The product is therefore constantly evolving, under a brief RECAP of the most interesting service options to date.

SOME SERVICE OPTIONS

DATABASE CREDENTIALS

Database Credentials

Like old NAV releases… Windows or SQL Login for Database Authentication mode.

CREDENTIAL TYPE

Credential Type
Specifies the authentication mechanism for Microsoft Dynamics NAV users of this Microsoft Dynamics NAV Server instance.

BUILD RESTRICTIONS

Build Restriction
Specifies if Microsoft Dynamics NAV Server must allow, warn or prevent a connection from a client that is built with a different build number.

DEFAULT SERVICE AND CLIENT LANGUAGE

Default Client Language
Specifies which of the installed Dynamics NAV languages on the server instance will be used as the default language in the clients. Set the value to a valid language culture name, such en-US or da-DK.

Services Language
Specifies the global language version to use for text strings with SOAP and OData web services.
The value must be valid culture name for a language that is available for the Microsoft Dynamics NAV solution, such as en-US and da-DK.

DEVELOPMENT PORT & EXTENSIONS TARGET LEVEL

Development Port
The listening HTTP port for Microsoft Dynamics NAV Developer web services.

Extensions 2.0 – Target Level

“In Extensions 2.0, we have added a concept of ‘levels’ of extensions that are used to determine different classifications and capabilities of an extension package.
In VSCode development, this is something you can specify in the app.json file using the “target” property. This places a restriction on what is ‘allowed’ within the extension.

On the server side, you are given the ability to set the ‘level’ of 2.0 extensions that you want to allow to be publishable/installable. This gives admins control over what kinds of extension they want to have on their systems.”

In order the ‘level’ progress as follows:

1. Personalization
   • Lowest current level, only allows for inclusion of UI objects like Profiles/PageCustomizations
2. Extension
   • Default level, allows for all of the capabilities you would currently expect from an extension
3. Solution
   • Unused at the moment, this (or something very like it) will be used to encompass the capabilities of ‘Embed’ apps in the future.
4. Internal
   • Highest level, currently only for internal use à  NO EXTENSIONS, USE C/AL

SQL COMMANDS TIMEOUT (AND QUERY)

SQL Command Timeout
The contextual timeout for a SQL command.

SQL Connection Idle Timeout
Specifies the time that a SQL connection can remain idle before being closed. The value has the format HH:MM:SS.

SQL Query Logging Threshold
Specifies the amount of time (in milliseconds) that an SQL query can run before a warning event is recorded in the application log for the server instance.
If this threshold is exceeded, the following event is logged: Action completed successfully, but it took longer than the given threshold.

ODATA V4.0 ENDPOINT

Enable V4 Endpoint
Specifies whether the ODataV4 service endpoint will be enabled.

AZURE KEY VAULT ENCRYPTION

Client Certificate Store Location
Specifies the certificate store location for the Key Vault client certificate.

Stay tuned for next post !

#NAV 2018 #DYNAMICS

There's no doubt that "days to close the books" is a metric that every controller and CFO would improve if they could. Shorter closes mean understanding last month's financial performance in time to make well informed decisions and better allocation of resources.

Despite this eagerness to settle their prior month adjustments and postings, we encounter clients that take far too long to close their month (or worse, they never perform a month-end).

We've made it a New Year's Resolution to promote better hygiene in the month-end process. We've gone on the road to talk about it and even published...

read more