Third address

[SBTBILL]

Robert - I've got a customer who is interested in adding a third address to her invoices. It is a trucking company. They need bill to, ship to, and ship from. Don't much like access but am thinking about VB Seems would require a table of ship to's, a table of ship froms, and DDE' ing to the company with POKES into the sales order table. Any comments.

Bill Couture

[Robert Walraven]

(Shannon - could we put Bill's question in a separate thread so as not to mix it up with Joseph's original question?)

If I understand your client's application correctly the BillTo address would be the standard customer BillTo address, the ShipFrom could be one of the 9 standard customer ShipTo addresses, and the ShipTo address would be different for each shipment. (That is, it is the customer's customer address.)

A very simple minded approach would be to put the ShipTo address in the note field of the invoice. The problem with this is that the packing list and invoice that you could generate with Peachtree's limited report design capability probably wouldn't be acceptable to your client.

You could also export the invoice to Excel and hand edit it to include the ShipTo address, but this is a bit awkward and I doubt your client would like this approach either.

You could use Crystal Reports for Peachtree if you put the ShipTo address in the Note field and then extracted the address from the note to format the packing list and invoice properly. I think this would probably be acceptable to your client although entering an address in the flat note field and interpreting it properly could be a problem if whoever does the data entry isn't very consistent.

Obviously the approach I would favor is to use MS Access, VB, or Excel in conjunction with PawCom to create a form for pulling up the desired invoice. That form could provide appropriate fields for entry of the ShipTo address and the data could be stored in records that were joined to the original Peachtree invoices. If you really want to work with CRP instead you might be able to do something similar; I'm not familiar enough with CR to know if this is possible or how hard it would be.

Bob Walraven
Architect of PawCom

[Marka]

As Robert states:

"If you really want to work with CRP instead you might be able to do something similar; I'm not familiar enough with CR to know if this is possible or how hard it would be. "

Yes, you can use Crystal for this particular situation. But Robert is correct that when the user enters the information in the note field that the information absolutely must be consistant each and every time. Unfortunately Peachtrees field for NOTE is broken down into several fields in the data record when in fact when you enter the information into this field this fact is hidden. Not having my data field definitions in front of me I think the field is capable of holding 1000 characters or something like that. But Peachtree breaks the entry field down into about 5 fields each totally about 256 bytes. When entering this information as example the user would need to depress the "CTRL" + "ENTER" keys in order for the cursor to respond properly. Entering these keys will tell the system to go to the next line of data (this is not the next field of data.). What I mean by this is that if the information in this field is not greater than 256 bytes the information will appear only in comment field anything greater will extend to comment2 field.

I do have a picking ticket Crystal form that I did create already. I tested it and it does work properly where you can have three addresses at the top - sold to, ship to and ship from. A form would need to be created for an invoice also.

SBTBILL if you need further assitance with this you may email me directly at: jemworldwide@onlinecol.com

Hope I was able to help you.

Mark

[Robert Walraven]

Mark,

The Note field in the Peachtree records is actually 2000 contiguous bytes. The problem is that trying to expose a field with more than 256 characters in Btrieve DDF files creates some real problems so the field needs to be cut up into 256-character pieces. We ran into this same problem in a very early version of Pawet where we used DDF files to map directly into the Peachtree files. In PawCom we expose the note field as a single 2000 byte field.

There are two significant problems with using DDF files to access the Peachtree Btrieve records. One is the problem above and the other is that the data in many of the Peachtree files is not in a relational form, which makes it difficult to use for designing reports. Peachtree renormalized the journal data in V8 so that it can at least be used with CR. Before that each kind of journal record in the JOURNAL.DAT had a different structure so that there was no fixed way to map into the data, hence no way to define a useful DDF file. After the renormalization, however, things are still not all that nice - some fields in the JrnlHdr and JrnlRow tables apply to only certain journals and all journals are still mixed together in these files.

We gave up trying to use DDF files to map into the Peachtree data a long time ago. It is just not a satisfactory way to go. What we have done in PawCom is read the individual records by calling the Btrieve engine directly. What we get is a blob of information (like you see from CRP). We then break the blob into the individual fields and store the data in a nice relational form. For simplicity we also allow each kind of journal to be stored in a separate table.

We also have identified more information in the records than Peachtree's DDF files. We don't have any confusing "Don't use this field" definitions like Peachtree has done. And we have mapped almost all the Peachtree company files, so we expose a lot more data than the DDFs.

I think the most productive way to use CR with Peachtree is to snapshot the data into Access files and then use ODBC to expose the information to CR. This gives you a more extensive, relational view of the data.

[SBTBILL]

Wasn't so much thinking of using Crystal Reports as using DDE to grab the customer information and poke the invoice back into Peachtree. Want to have the Address all be validateable and trackable. Shipments will of course get lost and/or be late. So what I'm thinking of is a side app that merges data back into Peachtree. The customer is single user, so my objections to the original thread in that regard don't apply. The customer table doesn't need to be changed in this case. The ship to and ship from tables would be totally separetly maintained in their own app.

Your comments on the tables are interesting. I'm used to doing this kind of thing with ACCPAC where the tables are open and fully relational. Don't think that the problems you describe would get in the way with this concept, however.

Bill Couture