The ChkPrint.rpt report uses the APTran & CheckHd tables. Neither of which have the PO for the receipt the invoice is for in them.
Here's what you'll have to do:
1. Make a duplicate of the ApCheck report data definition
(use: System Management\Company Maintenance\Report Data Definition)
2. To the new report def:
2.1 Add a table with the PONum (APInvHed has a field called POREFNum that might work)
2.2 Setup a relationship between the new table and the ApTran table
2.3 Select which fields of the new table to include( at least POREFNum)
3. Make a copy the ChkPrint.rpt (ex: ChkPrintX.rpt)
4. Add a new style to the ApCheck report style
(use: System Management\Company Maintenance\Report Style)
4.1 Set the Data Definition of the new style to whatever you named the dup you created in step 1.
4.2 Set the Report location to "reports/ChkPrintX.rpt,reports/APRemit.rpt"
Here's where it gets to be a pain, since you typically only print checks once.
5. Print some checks (make sure one is for an invoice against a PO) with the newly created style (from step 4) selected. Ignore the actual output.
6. Open then dup of the CR. It still won't know that you've added any new fields.
6.1 Change the data source to use the XML file created when the checks were printed. It's probably in the "mfgsysdata\Reports\your_user_ID" folder on the Epicor server.
6.2 Add the POREFNum field to the Crystal Report and save it.
Believe it or not I actually over-simplified it, and you'll probably find several important steps I skipped (or missed), and that it will be a real pain.
If you've not changed a Report Definition, or updated the source data for a Crystal Report, it may be easier to convince whoever wants the PO# on the check stub, that it's not worth it.
Calvin
Here's what you'll have to do:
1. Make a duplicate of the ApCheck report data definition
(use: System Management\Company Maintenance\Report Data Definition)
2. To the new report def:
2.1 Add a table with the PONum (APInvHed has a field called POREFNum that might work)
2.2 Setup a relationship between the new table and the ApTran table
2.3 Select which fields of the new table to include( at least POREFNum)
3. Make a copy the ChkPrint.rpt (ex: ChkPrintX.rpt)
4. Add a new style to the ApCheck report style
(use: System Management\Company Maintenance\Report Style)
4.1 Set the Data Definition of the new style to whatever you named the dup you created in step 1.
4.2 Set the Report location to "reports/ChkPrintX.rpt,reports/APRemit.rpt"
Here's where it gets to be a pain, since you typically only print checks once.
5. Print some checks (make sure one is for an invoice against a PO) with the newly created style (from step 4) selected. Ignore the actual output.
6. Open then dup of the CR. It still won't know that you've added any new fields.
6.1 Change the data source to use the XML file created when the checks were printed. It's probably in the "mfgsysdata\Reports\your_user_ID" folder on the Epicor server.
6.2 Add the POREFNum field to the Crystal Report and save it.
Believe it or not I actually over-simplified it, and you'll probably find several important steps I skipped (or missed), and that it will be a real pain.
If you've not changed a Report Definition, or updated the source data for a Crystal Report, it may be easier to convince whoever wants the PO# on the check stub, that it's not worth it.
Calvin
--- In vantage@yahoogroups.com, "daveeaton5150" <deaton@...> wrote:
>
> We are running Vantage 803.405a. I've been trying to add a PO number to the
> check stubs so it shows when we print an AP check. I can't seem to find where to
> get the data to add it to the Crystal report. Has anyone done this?
>
> Thanks in advance,
>
> Dave Eaton
>