To start with, QuickBooks is a software solution for financial management sold by Intuit (http://www.intuit.com/). Designed for small and mid-sized businesses it is one of the most widely used business applications in North America. It is not designed for companies with large volumes of transactions and has some noticeable limitations when used as such – nevertheless: many growing businesses get started using QuickBooks and as they transition and grow to include the national or regional Retail vertical (Requiring EDI) – they still find themselves using QuickBooks. Everyone currently or previously in this position will attest that the database engine is not optimized to handle large amounts of data (Either transferred or processed). One of the companies we talked to in writing this article stated simply: “If you try to export 900 PO’s and to import 900 Invoices, you will wait quite a bit.” There is help out there, read on.
For QuickBooks users and developers, EDI terms are not common. QuickBooks doesn’t know what an SDQ is and there is no 850 or 856 let alone anything like an 860, 855, etc. QuickBooks uses terms like Data Import-Export, QuickBooks Synchronization, QuickBooks Web site integration, QuickBooks Automation. As a QuickBooks user, you exchange data using the tools that QuickBooks provides or through a custom plug-in, developed specifically for that type of business by a QuickBooks developer (More on them further on). If we define EDI as: 'The transfer of structured data by agreed message standards, from one computer system to another without human intervention' (from Wikipedia). In QuickBooks, data is structured in a predefined way and because at its core QuickBooks is an accounting program, it needs human intervention. For example, if you need to import data in QuickBooks, data has to be in an excel file (CSV) or XML format with certain fields being mandatory. Most processes can be automated in QuickBooks, but at a certain point it requires human intervention (to validate data, to issue a PO or a check or an invoice, to validate data transfers, etc). Now, when we try to integrate EDI to QuickBooks, we must agree on the standards. EDI has its own standard as does QuickBooks. So, integration becomes a problem simply because the two use different, though well established standards.
Usually a plug-in or mini-application is used to push/pull data with QuickBooks. Through this plug-in, you can pull invoices, sales orders, transactions, customers, vendors and supplier’s data and export them in QuickBooks, basically any type of data QuickBooks accepts and is also useful for the user. It also works the other way around, from QuickBooks to the EDI tables, database, etc. exporting products from QuickBooks inventory lists, or descriptions, inventory, customer, vendor or employee data etc. The API used by developers, is QBFC (QuickBooks Foundation Classes) developed by Intuit to help companies communicate with QuickBooks. QBFC features enhancements and tools for enabling data integration between third party applications and the QuickBooks.
Several companies have developed tools specifically to help retail supplier using QuickBooks. On Intuit’s Marketplace there are 7 applications for EDI Integration (Intuit Marketplace - http://marketplace.intuit.com/v2/i-retail/f-edi-data-interchange/software-solutions.aspx).
All of them designed for the desktop versions of QuickBooks (None for QuickBooks online and actually only 4 of them truly ‘integrate’ EDI to QuickBooks). QuickBooks has its own data base engine, its own system to integrate and use data. EDI has its own standards and conventions integrators - so developers must find a common target to bridge the integration requirements of both (EDI and QuickBooks). Data in EDI standards must be converted to QuickBooks standards and vice versa. Companies offering a QuickBooks EDI integration tool go through third party testing and are scrutinized by Intuit for the kind of customer service they offer. While I can’t attest to the thoroughness of the testing or certification that Intuit requires (Couldn’t get access…) I can say all the companies listed have been around for quite a while servicing this need.
Many people say QuickBooks is not suitable for a retailer-supplier relationship involving large amounts of data to be transferred and processed because of the way QuickBooks was developed. Others (Probably a much smaller number) would say “We have made it work”. I personally know companies doing in excess of $30 million annually (All with major retailers) that have used QuickBooks since they opened their doors. Obviously, the product being sold, the replenishment methods and retail relationship required dictate how well QuickBooks will perform for a given company. The trick with managing business applications in many cases is determining when or “IF” a switch should be made from one application to another - that should be the subject of another article.
Jim Cantrell can be reached at This e-mail address is being protected from spambots. You need JavaScript enabled to view it
We owe some thanks to several companies who helped us get background on the content for this article. Special callouts need to go to Claudiu Preda @ Soft Cookies (http://www.statusokay.com/) as well as Intuit (http://www.intuit.com/).
Also try us on Twitter (http://twitter.com/RetailEDI) or on Linkedin (RetailEDI).
| < Prev | Next > |
|---|