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
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.
OK. I figured that out and did that.
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.
What's the client interested in??? :)
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.
How does this SDK work? I didn't see a download link, do I need to
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.
Yow! I had no idea.
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.
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!
> Good luck...
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
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.