Exported IIF Format does not match the Intuit published Header files

From time to time, company has modified its IIF platform. For most of our case in clients, we won't rely on IIF import kit anymore. Consider using a 3rd party IIF converter instead. Another option, consider an importer tool for common format (i.e CSV, XLS).

https://transactionpro.grsm.io/qbd

https://partners.saasant.com/affiliate/idevaffiliate.php?id=5051_2

Just my 2 cents. 

Thanks but I am not interested in purchasing a third party app.  Generating an IIF is simple enough given the proper specs.  Third party apps would need updated specifications just like I do.  If they have the updated specs then they should be easily accessible somewhere here on the site.  

I would like that file.  However, in all the searching I have done, the file does not appear to exist which prompted my original post. 

Thanks for the detailed information BillOM,

Right now, these fields aren't available in the kit. I can send a feedback request to our engineers. They can consider these fields added in the future update.

You might also want to check our page about inventory and projects for future reference.

The Community is always here if you have other concerns. Keep safe.

@BillOM 

RE: A complete and accurate set of specifications including but not limited to field names, allowed values, character lengths etc. are a must!

Well, you won't be getting that from Intuit. The kit was never complete.  Also, though it is designed to show you want you can use for importing, not what appears when exporting.  They're not exactly the same.  For example, the DELCOUNT value is ignored if you do include it.

As far as fields specs, they are in most all cases the same as the limitations within the QB user interface.

Thanks.  I realize the field lengths and valid data would be the same as Quickbooks, but then that would require one to try to enter values in each field to determine the maximum length and then test for valid data. 

This really needs to be the responsibility of the folks at Intuit.  They really need to stop this nonsense of holding secret things that should be public.  Source code -> secret, Import Specs -> public!

I don't disagree, but Intuit has managed to not update the kit for over a decade.  They are unlikely to do it now. 

Just so you know, there are also more than a few errors in the doc that does exist. I'd not trust it without testing.

Hello there, brconsultingid2.

We do appreciate your thoughts about updating the kit. 

Most product enhancements are based on your feedback. I'll make sure to personally give this suggestion to our developers so they can consider adding this in feature in any future updates.

You can also visit our QuickBooks Online blog regularly. From there, you'll be updated with the features and enhancements that our developers are currently working on.

If you need anything else, you can click the Reply button. We're always here to help.

@GlinetteC 

RE: Most product enhancements are based on your feedback. I'll make sure to personally give this suggestion to our developers so they can consider adding this in feature in any future updates.

Customers have been asking for such an update for more than a decade. I don't really think PD is going to update it.  I seem to remember that support created the kit in the first place, not PD, and then touted it long ago online.

@BigRedConsulting

I wouldn't dream of not testing.  No way no how.  If there is one mistake in the kit then there must be others - that's kind of also a given.  I appreciate all your posts I have read over the past few days trying to determine if there was a newer kit somewhere and I truly appreciate your thoughts and input here.  

@GlinetteC 

Why would Intuit ignore the demands/request of its customers?  If this particular issue has been an issue for decades, then your statement, "Most product enhancements are based on your feedback" is likely only partially correct. 

I would think that Intuit would want to make importing as simple as possible. Heck, I can't even import an IIF file that I exported directly from Quickbooks - it fails! Now THAT is a crying shame - no valid excuse exists for that!

@BillOM 

Thanks for the compliments.

RE: I would think that Intuit would want to make importing as simple as possible. Heck, I can't even import an IIF file that I exported directly from Quickbooks - it fails! Now THAT is a crying shame - no valid excuse exists for that!

This can happen if there are conflicts between the IIF file and the file you're importing into.  More recently it can also happen because of changes in QB 2019 - 2020, which are problematic.  The idea was to make import more reliable, but the exact opposite has happened, unless you bypass the new code. See BRC QuickBooks 2019 & 2020 IIF Import Changes and Recommendations for steps to do that.

In this particular case, an address line in our Quickbooks database contains 43 characters and only 41 are allowed to import.  I exported our vendor list and attempted to import in a new company file and it failed with the address because it exceeded 41 characters.

This type of bug is so simple to test and eradicate if only they cared about importing.  Obviously you are allowed to enter more than 41 characters per address line in 2019 and later versions but you can't import more than 41 characters.

This shows that they do not test exporting and importing.  What else don't they test????

@BillOM 

RE: In this particular case, an address line in our Quickbooks database contains 43 characters and only 41 are allowed to import. I exported our vendor list and attempted to import in a new company file and it failed with the address because it exceeded 41 characters.

That's strange.  When I try this, I can only enter 41 characters into QB on a vendor address line.  So, not sure how you got more. If you check that vendor, is the address line actually 43 characters in QB?

In any case, what you're describing sounds like the new supposedly-better import that is the default in QB 2019 and QB 2020. It has created more problems than is solves (I don't think it solves any problems, actually.)  You can avoid it. See BRC QuickBooks 2019 & 2020 IIF Import Changes and Recommendations 

I did see and read that page several days ago - very informative and helpful.

I have not looked at the vendor within QuickBooks proper.  What I found was that the address was malformed and had both the street and city state zip on the same line.  I split it up into separate fields in the exported file and then the import worked.

I should be back at the office tomorrow when I plan to look at the record to see whats there.  It was exported from Enterprise 2019 and imported into Enterprise 2020.

I know this is late, but I wanted to provide reference info.

Custom Fields are limited by where they are In Use. 7 for Names (Customer, Vendor) and 5 for Items. That's why the total you can define in the Dictionary are not available when, for instance, you Add Vendor. Vendor gets a max of 7. You can see the Dictionary and the Use by exporting an entire file as .iif. Here:

"Each customer field has a data row labeled with Index 0-nn.  For Customers/vendors CUSTNAMEDICT and for items CUSTITEMDICT.  The Index corresponds to the CUSTFLDnn value in the Data section column definitions.  Please note that index 0 = CUSTFLD1."

There are almost no changes to .iif, because it is deprecated and unsupported, from around the time the company data file was converted from flat files to relational. That also means the other improvements are not incorporated. That includes Contacts. The Alt Contact (seen in the Cust .iif reference as CONT2) has all been completely translated into the Contacts function that now is a tab in the Customer/Vendor Centers, with maintenance of multiple contacts now possible. But sometimes, you see these fields when you want to Add Fields to a Template, such as adding Contacts to a statement or invoice template, will reveal old code.

For the email, it helps to notice how you can now select from a rotating set of labels for info related to customer or vendor names, but only the field that holds the email address and is the email field is a function (not just for display notation, but makes something happen). Then there are things you learn only by testing, such as Other Names have a "print as" but it's not a field; it's from the first billing line.

"While all this information has been helpful, it is not complete nor is it accurate."

Yes, it is about 15 years out of date, and no one is maintaining it. You are supposed to be using the SDK to do programming, now. But a lot of us have .iif experience and it works fine for its limited needs. Start making your own notes about things you discover and need to refer to, later.