I'm a web developer with a client who uses Quick Books. He'd like to import the web sales.
It looks to me that QB has two main files for this, one for transactions and one for items.
What I don't understand is how to import shipping costs (which are calculated on the website), all I see in the transaction IIF is a single field for "AMOUNT". I don't see this (shipping cost) in any of the other possible IIF files. Can someone shed some light om how QB handles shipping costs, and for that matter actual taxes, which we also calculate online.
QB handles shipping charges as an "other charge" item on invoices, etc.
As for IIF importing, see my response a week or so ago to a thread on importing csv data -- there are some definite limitations to the IIF format noted there as well as some links to the QB web site. If you're really talking of making this a production-type environment, you'll probably want to use the QB SDK instead or perhaps find a ready-built addon that has the required functionality.
I missed that, but had read the rest of the thread. Thanks.
there are some definite limitations to the IIF
I'm mostly interested in a one off so I can move on. I'm on the *nix side and it looks to me that the SDK is not and I'm guessing requires some client side code.
The SDK is definitely Windows, true; the question will probably be whether the IIF facilities will handle what is needed well enough to run a business with. Volume of number of transactions may be a key there.
That portion of the enterprise may not be your contractual responsibility of course...
Being the developer, I'm downstream a bit. I could call him, but he would have someone else get back to me because he wouldn't know! Sometimes I wonder how any business runs.
I would guess in the low double digits/day for transactions.
I hope!
How does this SDK work? I didn't see a download link, do I need to sign up?
Depending on just how much is in each transaction, perhaps...
The biggest problem w/ IIF is that it has _NO_ error checking and will happily trash the entire database irrecoverably -- that, needless to say, is not in the category of good things...
Secondarily are the limitations to what can be imported via iif and the internal links that aren't built that may be w/ interactive or SDK updates that may either require manual intervention or leave w/ some reports on transactions not finding all because of the missing links.
Whether this is an issue is for the user/owner, obviously.
There is a signup and then a download -- I thought I had the link in the previous posting. If I didn't, it's in the developer support section on the Intuit site.
I've not actually used it -- as I noted previously, I retired from active consulting before I got one of those round tuits so never did build the add-on I intended.
I did look at the API set some; it seemed fairly straightforward altho that was very shortly after it was initially introduced.
The one thing I'll stress is to be _absolutely_sure_ whoever does your your development testing on actually trying to make the imports into QB is using a backup copy of the database as it's virtually guaranteed you'll trash it several times before you get the details of the headers and transactions worked out to work correctly even though the concept is essentially trivial -- because as noted, the iif import engine has no safety net and the documentation isn't all that great.
What kind of errors cause such a terrible thing? It would seem to me that I should be able mitigate that while making the IIF files.
more below...
Thanks for that.
Since most of the IIF files are import only it's not possible to see what the file should look like.
I, of course, just found the IIF docs and thought, this shouldn't be hard!
I do have the IIF script set up as a hash (associative array) of header to instructions, so it'll be easy to tweak, or at least it would be if I knew what was wrong!
Most anything that isn't right in a transaction that isn't perfect and thus leaves a corrupt record has the potential as the QB database isn't all that robust to begin with.
That's the rub...there really is no way to tell a priori nor is there any symptom or informative message generated during the import--all you get is either success or failure when done and a failure might be the database is no longer readable.
It's just a very delicate process.
If the import file is correct, odds are good; if there's any error at all there's no telling what the result may be.
...
Yes, and yes... :) (or :( maybe more appropriately).
That's the right approach -- again, conceptually they're simple, the rub is ensuring that they are, in fact, letter perfect before importing.
That they're going to be computer-generated will ease that as opposed to trying to edit them from spreadsheet manually which is a way many try to do it that is extremely error prone.
Once you do get the rules generated and tested it should be as reliable as iif gets.
Also note that while testing there's no way to tell about duplicate imports of the same transaction--another reason to only use copies of a database for testing.
I have helped several clients set up QuickBooks to import transactions via IIF files. While it is true that IIF files do no error checking, if kept simple they function adequately. Please feel free to email me at garye55 @ gmail .com for further info
Have you checked out Baystate Consulting's tools for importing transactions? Per their home page
formatting link
Don't trust your critical accounting data to risky IIF import tools!
Using IIF transaction import tools can corrupt your QuickBooks data file. Intuit will not support any issues created by using IIF transaction imports. All our tools use the Intuit approved method which is the QuickBooks SDK (software development kit).
Their tools use the SDK methodolgy. If you going to do this type of work frequently this might be a good investment for under $200.
BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.