As I have mentioned on my previous post, I have discovered an interesting bug while exporting a fixed width file using DMF within Dynamics 365 Finance and Operations. The bug occurs when you specify the row delimiter as {CR}{LF} or even {CR} on your fixed width file settings. In either instance, the file gets exported without a carriage return ({CR}) thus ignoring the row delimiter setting for the fixed width file. The exported file therefore wouldn’t be formatted as you would want, potentially causing readability issues for some text editors or applications that depend on the {CR}{LF} combination. In this post, I’ll take a deeper look into this and how I solved it by integrating a fix within the Logic Apps process required for exporting the data.
Fixed width a.k.a. fixed-character file is a file that is not delimited. That is, a file which contains rows and columns where the columns are not delimited by any special characters like commas (comma separated files .csv) or tabs (tab delimited files) but the columns are broken down based on the character length of each field/column.
I have been working on a requirement recently that involves importing a fixed width character file in D365 F&O via DMF by way of Logic Apps. There had been a couple on challenges on this one and I have Googled / Binged about it and found forums where people have had to find alternative solutions, thinking that it’s impossible (for example, this question from the Microsoft Dynamics Community Forum).
I’ve also read many similar blog posts where some people say that they have asked the customer to change the file format. Like this one from before.
We did complained to Microsoft about one year ago because we had the same issue, and as I see it stills hasn’t been fixed, so I wouldn’t believe it will be at least solved in a short time. Sorry to not bring to you a solution, in our case we had to change the file format.
But I’ve been wondering why the customer has to change the file format? Can the developer not create a solution?
Some projects have a lot of labels and when working with a team of developers, merging label files can be a nightmare provide some challenges. Microsoft Dynamics AX doesn’t like duplicate labels and, unfortunately, identifying all instances of duplicates isn’t a straightforward process. I’ve therefore put a PowerShell script together that identifies duplicate labels.