payable and receivable

ones and zeros.

Maybe you could tell us how you think it works, and we can assist you from there

Gary

Or even better what the hell you are talking about.

i am talking about the database designs and relationships for the tables.

thanks,

pago

The accounts payable database, for example, have the following tables:

Purchase order: Purchase order number Order nbr Purchase order type Payable entity Customer id Vendor id Vendor location Buyer id Etcetra....

Payment: Payment method Pay_reference number Pay_date Vendor Id Vendor Name Vendor_Address Bank Account Pay amount Journal Id Etcetra....

Payment request line: Vendor ID Vendor Name Vendor Location Pay_Reference_Number Pay_date Purchase Order Detals Etcetra....

What i am really after is a schematic representation diagram and explanation for a typical accounts payable and receivable database design, showing how the tables relate to each other.

Thanks,

pago

he wants to reverse engineer the software.

my suggestion to him -- get the SDK

Heh, you have mistaken the nature of this newsgroup. The common denominator is that most have purchased and used the software.

While database analysis and theory made for an interesting course when I was in college some thirty years ago, I've found little practical use for it when using QB - other than some glimmer of an idea as to why certain proposed features might never be implemented.

QB does have a free SDK - software developers kit.

don't remember just how explicit the documentation was. There are also forums dedicated to the use of the SDK. could be that someone there has an inkling of the QB database table structures and relationships. It is also highly likely that a schematic diagram such as the one you desire is considered proprietary by Intuit, and might not be available.

This information would be highly useful if one wanted to develop any kind of reporting utilizing the qodbc data. It does not seem like a wild question at all. The table structures you see coming out of the qodbc is not readily usable, to say the least. No debits and credits, no "transaction list" as such and a whole lot of useful garbage. To be able to link payment with payment details and the affected invoices would be a minor first absolutely necessary step to developing an open invoice report for instance. A table relationship diagram would indeed be helpful. I'll be scouring the sdk site too.