PawCom Application Note 108: Troubleshooting a PawCom Application
=================================================================

When you develop a custom application that uses PawCom you need to be sure
the transactions you create are correct:  PawCom does not do any validity
checking on records that you write to Peachtree, so you can create
transactions that Peachtree does not find acceptable.  Also if you upgrade
to a new version of Peachtree, you should not expect your custom application
to work without modification - you will most likely need to make some
adjustments to support the new version of Peachtree in addition to upgrading
to the latest version of PawCom.

If you are just getting started with your application or are having a
problem, the MS Access front end to PawCom is a good place to look for examples.
It contains a lot of code that you can examine to see how to correctly perform
certain operations.  For example, the Demonstration Functions module contains
sample code for creating journal transactions of every type for the sample
Bellwether Garden Supply company.  Not only will this code indicate what you
need to do to generate each kind of journal entry, it will show you how to
adjust what you write for different versions of Peachtree.

It is important to realize that with each new version of Peachtree the
structure of the records tends to change a bit.  For example, in version 10
(2003) a universally unique GUID field was added to the journal header records
and in version 11 (2004) a GUID field was added to the journal detail (row)
records. These GUID fields must be unique for every record.  What this means
is that if you tried to use code that was developed for version 9, before the
inclusion of the required GUID fields, the first record you created would be
written with an empty GUID, which would be accepted, but you would not be able
to write the next record because an empty GUID would already have been used.
Thus, you would need to modify your application to include the GUID fields if
you wanted it to work with version 10 or 11.

Since version 7 Peachtree has made changes in their record structure for each
new version, so you should expect that older versions of PawCom will not work
with newer versions of Peachtree.  If you are going to convert to the latest
version of Peachtree you also need to convert to the latest version of PawCom.
Even then your application will probably not work correctly as is because of
the changes that Peachtree has made to its record structure. You should examine
the code in the Access front end for the latest version, looking for any
conditional code that applies to the new version, then include that code in your
own application.

If you are just getting started, you need to determine what correct transactions
should look like.  The easiest way to do this is to create transactions in
Peachtree like the ones you are intending to create from your application.
Then you can refresh the data in the MS Access front end to PawCom and
examine what shows up in the records.  What you see will act as a template
that you can use for creating your own transactions.

During development you should check to see if Peachtree is happy with the
transactions you create. A simple test for journal entries is to open the
transaction in Peachtree, examine it for correctness, then close the form.
If Peachtree displays a message at this point saying something like  "the
transaction has been changed, do you want to save it?" that means the
transaction is inconsistent with what it is expecting.  If you say to save
it, Peachtree will modify the record to its liking.  If you did not create the
transaction correctly you may also see problems in other places, such as
footing errors in the General Ledger or the inability to change periods.

If you are creating incorrect transactions, the MS Access front end is a
powerful tool for helping you determine what is wrong.  Since you are able
to snapshot the actual data into the Access tables, you can examine both
the records you created and the ones Peachtree has created or modified.
Here is a simple procedure you can use:

Create a transaction from your application.  Then create a second essentially
identical transaction from your application.  Go to Peachtree, pull up the
first transaction you created and, when you close the form and Peachtree
asks you whether you want to save it, say Yes.  Go to the PawCom Access
front end and refresh the kind of data you are working with.  The last
two transactions created are the ones you want to look at.  If you are working
with a journal entry they will be the ones with the largest NRecord value.
The first transaction is one that Peachtree has modified to make it
acceptable and the second is one that is unmodified.  Compare the two
transactions field by field looking for any differences.  That should
allow you to quickly determine what you are doing wrong.

An alternative to creating two transactions and letting Peachtree modify one
of them is to manually create a second transaction in Peachtree that is just
like the one you created from your application.  You can again examine the
two transactions in PawCom, looking for differences.