CRYSTAL REPORTS Forum - Would you like a dedicated forum for Crystal - please vote

[Marka]

I believe there would be interest from our forum to have a dedicated forum for Crystal Report use with Peachtree.

I have used Crystal for years but with other software. There are some people that purchased Crystal Report writer from Peachtree thinking the task of extracting data would be much easier than it is. I myself having experience in Crystal still finds challenges in pulling data properly from the Peachtree database. Unfortunately when we bought Crystal we were unaware of the fact that our support contracts would not cover the use of Crystal. I have some database background and even with that I find it to be difficult at times. Even the few times that I have convinced Peachtree to aid me in the logic behind their database it was difficult for them to answer my questions regarding the construction of their own database (which really surprised me and worried me).

Although creating Crystal Reports even knowing the database can still be quite difficult (depending on the report) I would think that our tasks would be easier if we did in fact have a dedicated forum to help us share ideas/logic with one another and to post specific questions.

Please vote here and let us know if you would be interested in having this dedicated forum for the use of Crystal Reports.

Thank you for your time.

Mark

[Robert Walraven]

Peachtree has done a very poor job of documenting their internal database, so using Crystal Reports for Peachtree (CRP) can be very confusing. However, there is some documentation you may not be aware of that can give a better understanding of their JrnlHdr and JrnlRow data - the PawCom User's Guide. You can download it free from the Multiware web site. (Click the banner ad above.)

Chapter 4 discusses the Peachtree database in general and the sections on JrnlHdr and JrnlRow describe all the fields in these two kinds of records. (The names of the fields will differ a bit from what you see in CRP because we didn't know what the internal names they used were when we designed PawCom.)

One thing you will notice is that Peachtree has only exposed a subset of the data in their database with their DDF files. This means that there is some information you simply cannot use with CRP.

[Marka]

Robert,

Thanks for the info on PawCom users guide. I figured Peachtree did not include some of their .dat files in their .ddf structure. Now what sense this makes I can not tell you. Not only is purchasing Crystal reports misleading due to fact that their support contract does not cover Crystal but they only make some of thier .dat files available in the ddf listings.

I used to use Macola Software and I will tell you that their database structure was so good and easy to pull data from compared to Peachtree. Macola set aside a data file for almost every operation. Order Entry would have it's own OEHDR.dat and then the corresponding OELINE.dat file, Purchase orders would have POHDR.dat and then it corresponding POLINE.dat files. The fields were defined and explained throroughly and clearly stated. Very little guess work at what you needed to pull from each data file and the fields you needed to use in order to create Crystal reports. Peachtree is so confusing. You have to interpret each and every line of the two major files Jrnlhdr and Jrnrow and then you must interegate each row to be sure you will end up with the proper results. It is downright scary sometimes. I have been able to produce some nice reports using Crystal but I will tell you that I have invested far more time creating them then I should have due to their database structure. When I create reports I have a good understanding of the logic which tells me what data I need but to find the proper data is the real challenge.

Robert, I have while writing this reply downloaded the users guide as you suggested. I see after reading a portion of it that I am SCREWED - meaning I can not access a lot of the data simply because Peachtree won't let me. I was very interested in the area of the guide which discusses the data file INVCOST.dat. Here is a file I could have used many times by now. I have spent countless hours trying to caculate the inventory on hand for many of my reports since Peachtree does not store the quantity on hand value for each item but instead causes you to have to calculate it each time. I have been successful in using the Jrnlrow data file in pulling the beg bal, transactions (purchases sales) etc and arriving at a calcuated inventory on hand quantity. The one thing that does cause the calculation to be off is the inventory adjustments entries. I have yet to determine my best line of attack for this entry.

This is my feeling of misleading us. Peachtree only made certain data files available in their ddf's. now what sense does that make especially one line INVCOST.dat - I would think that this is a very important data file that many would want to use.

Thanks for your help with the users guide and I will continue to read it.

Mark

[Robert Walraven]

The major problem with using DDFs to interface to Peachtree's data, as you have discovered, is that their internal Btrieve data structure is just not suited to this kind of interpretation. The basic structure was designed many years ago and was intended to be efficient, not understandable.

I was hoping that CRP for V9 would have more reports in it than for V8, and was suprised that it had just the same 6 original reports. I am pretty sure Peachtree has someone working full time developing more functionality for CRP, but we probably won't see anything further until V10.

As you have discovered by reading about the structure of the InvCost data this information, which is missing in their DDFs, is really important stuff. But the complexity of the InvCost records makes them very messy to work with and even more confusing than the journal data.

What Peachtree really needs to do is build a good interface to PCAW similar to what they did for POA. Then CRP would work beautifully. Perhaps we will see something like that from them someday but we'll have to wait a bit before it happens. It is unfortunate for Peachtree users that Intuit has developed an SDK for QuickBooks and is actively encouraging developers to work with it while Peachtree has nothing to offer and discourages 3rd Party developers.

One further suggestion for getting insite to the structure of the Peachtree journal records: download the demonstation kit for PawCom. You can use it to examine the actual JrnlHdr and JrnlRow records in the Bellwether Garden Supply company data. You can even create your own journal records and see how they appear in the Peachtree data.

Bob Walraven
Designer of PawCom

[Marka]

Robert, thanks for your comments.

When I get time I will download the free demo and take a look at it.

I happened to spend a good portion of this past weekend creating a Crystal Report that prints picking tickets for backorders. Our sales orders from customers will range in line items from 15 to 90 per order. We get many small stores ordering one piece of 90 different items. Our problem is that this generates high volume of paperwork because we do have backorders. Even if we only backorder one item we end up printing 90 line items to show the prior shipped quantities on each line item. This is our book is a total waste of paper and creates so much more work and confusion. And it is not unlikely that we may have 2 or three items on backorder for an order and make 2 or 3 different shipments on the backorder as the goods arrive sotherefore it is not unlikely that we would have to print out the picking ticket 2 to 3 different times. So if the original order had 3 pages each and every time we print the back order 3 pages are printed. For an order with 3 pages and three shipments on backorders we print - 12 pages of picking tickets for this one order. With my picking ticket report we only print the original order at 3 pages and then one page for each shipment on the backorder each time a shipment is made which now equates to 6 pages. Also if I had not redesigned the peachtree picking ticket to begin with the 3 page picking ticket would have printed 5 pages. Then we would have had 20 pages printed. I guess you can tell how big our A/R files are getting. Another thing I do not like that peachtree does is generate a back order using the same Sales Order #. It should generate another picking ticket with a different SO#. Each backorder shipment should have a different SO# because each shipment should be considered a separate shipment. This makes it much easier for tracking purposes. I will be creating a special picking ticket for our picking tickets for first time shipments also, it is much easier to create a picking ticket with Crystal than using Peachtree's design function - yuk!! i hate it.

Mark

[Unregistered]

I think it's a great idea to have a forum dedicated to Crystal Reports users. Crystal Reports questions seem misplaced in one of the general forums, where the majority of users may not have any knowledge on the subject.

Additionally, it would give us a place to share reports that we have made with other users, preventing them from having to re-invent the wheel. Let's try to keep this thread alive until one of the administrators notices.

[Rog]

I fully support the idea of a Crystal Forum. People without database knowledge as myself would welcome. I was one who purchased this with great expection. I am very disappointed

Roger

[Shannon Tucker]

See the new forum dedicated to Crystal Reports issues (http://www.peachtreeusers.com/.forums/forumdisplay.php3?s=&forumid=15).

I moved all the existing CR-related threads that were in this forum to the new CR forum.

Thanks for letting us know how to make PeachtreeUsers.com a more effective resource for you.