Assuming that NOF doesn't meet your needs, I would assume you would want to use AP_ManualCheckHeader or AP CheckHeader.

Hi Tom,

Thanks, I think this is what i am looking for. I will give it a try.

Still no luck....

I am tying Kevin's suggestion now.

hopefully this will work.

Regards,

Manuel

Assuming you are using AP Invoice Entry to enter these invoices for the NOF or ONETIME vendor and you are also checking this checkbox.

Then you need to start with your UDFs in AP_InvoiceHeader.

Then create the UDFs in AP_InvoiceHeaderPosting.

Then create the UDFs in AP_OpenInvoice.

Then create the UDFs in AP_CheckDetail.

Then create the UDFs in AP_CheckStubWrk.

The above is the bare minimum needed to get the data into the work tables for check printing.

You can also push the UDFs into a number of other posting tables, history tables, and the manual check tables if needed. There are a bunch more that i don't have time to go into detail at the moment.

For now, once you have the UDFs added to the stub work table, you should see them in Crystal Reports if you drill into the stubs and if needed, verify the database to update the field listing if you don't see them.

I've added the my test UDF to all for stub sub reports just to demonstrate.

Using this check form type, any check form type that has the stub before the check will work.

Here is what it looks like.

Now if you need this value printed on the check, we have to utilize a shared variable to pass the value from the subreport to the main report where it can be displayed.

Start by adding a section before any other sections related to this record, since there aren't any groups and instead just multiple detail sections, you just need to add a new detail section and move it above all the others and suppress it.

Create a new formula, i've called it "Reset Variables". In the formula, you need to declare are the variables you need to pass, in this case, since i'm just passing my sample field, i just have [Shared StringVar UDF_Test := "";]. What i'm using the name of the field as the variable name as well and since it is a string field, i use StringVar, if it is a numeric field, use NumberVar. 

Add the formula to the new section.

Drill into the first sub report and create a new formula, i'm calling it "Set Variables". This is where we set the value of the shared variables to the value from the UDFs.

You can set more than one variable in this formula by duplicating the lines as many times as needed for each UDF you have and changing the variable name and field name accordingly. It would look like this.

Now add the new formula to a existing section or a new section where it will get the desired value. In this case, if you are generate a separate check for each invoice, than you should only have one invoice in the stub work table so it doesn't matter whether you add the formula to the group or detail section. Because i ended the formulas with "", they will not display a value when added to a visible section of the report so you don't have to worry about it overlaying other details. For this example, i'm just goping to add it to the group footer.

You then need to select the formula in the section of the report and copy it, then paste it into the same section of the next sub report sections that appear before the check section.

The final step is to create another formula in the main report to retrieve the shared variables. If you are going to join multiple variables into a single string, like the address fields with a carriage return and/or line feed between them, then you could just use one formula, if you want to have each variable as a separate field for more flexibility, then create a new formula for each field, you can call it "Get [FieldName]" or just "[FieldName]", whatever you prefer.

In this case, i'm only after the one UDF but i will call the formula "UDF_Test".

Then add it to the check section.

Here it is when previewed/printed.

On a final note, you can use the other alternative method of using a script to set the value to UDFs created in AP_CheckHeader based on the invoice entered in AP_CheckDetail, both work fine and both require a bunch of UDF sourcing, ultimately it is up to you based on what you feel comfortable with implementing.

Assuming you are using AP Invoice Entry to enter these invoices for the NOF or ONETIME vendor and you are also checking this checkbox.

Then you need to start with your UDFs in AP_InvoiceHeader.

Then create the UDFs in AP_InvoiceHeaderPosting.

Then create the UDFs in AP_OpenInvoice.

Then create the UDFs in AP_CheckDetail.

Then create the UDFs in AP_CheckStubWrk.

The above is the bare minimum needed to get the data into the work tables for check printing.

You can also push the UDFs into a number of other posting tables, history tables, and the manual check tables if needed. There are a bunch more that i don't have time to go into detail at the moment.

For now, once you have the UDFs added to the stub work table, you should see them in Crystal Reports if you drill into the stubs and if needed, verify the database to update the field listing if you don't see them.

I've added the my test UDF to all for stub sub reports just to demonstrate.

Using this check form type, any check form type that has the stub before the check will work.

Here is what it looks like.

Now if you need this value printed on the check, we have to utilize a shared variable to pass the value from the subreport to the main report where it can be displayed.

Start by adding a section before any other sections related to this record, since there aren't any groups and instead just multiple detail sections, you just need to add a new detail section and move it above all the others and suppress it.

Create a new formula, i've called it "Reset Variables". In the formula, you need to declare are the variables you need to pass, in this case, since i'm just passing my sample field, i just have [Shared StringVar UDF_Test := "";]. What i'm using the name of the field as the variable name as well and since it is a string field, i use StringVar, if it is a numeric field, use NumberVar. 

Add the formula to the new section.

Drill into the first sub report and create a new formula, i'm calling it "Set Variables". This is where we set the value of the shared variables to the value from the UDFs.

You can set more than one variable in this formula by duplicating the lines as many times as needed for each UDF you have and changing the variable name and field name accordingly. It would look like this.

Now add the new formula to a existing section or a new section where it will get the desired value. In this case, if you are generate a separate check for each invoice, than you should only have one invoice in the stub work table so it doesn't matter whether you add the formula to the group or detail section. Because i ended the formulas with "", they will not display a value when added to a visible section of the report so you don't have to worry about it overlaying other details. For this example, i'm just goping to add it to the group footer.

You then need to select the formula in the section of the report and copy it, then paste it into the same section of the next sub report sections that appear before the check section.

The final step is to create another formula in the main report to retrieve the shared variables. If you are going to join multiple variables into a single string, like the address fields with a carriage return and/or line feed between them, then you could just use one formula, if you want to have each variable as a separate field for more flexibility, then create a new formula for each field, you can call it "Get [FieldName]" or just "[FieldName]", whatever you prefer.

In this case, i'm only after the one UDF but i will call the formula "UDF_Test".

Then add it to the check section.

Here it is when previewed/printed.

On a final note, you can use the other alternative method of using a script to set the value to UDFs created in AP_CheckHeader based on the invoice entered in AP_CheckDetail, both work fine and both require a bunch of UDF sourcing, ultimately it is up to you based on what you feel comfortable with implementing.

Very nice, David.  When I did this for a customer, I believe the script I wrote was when I created a payment, when I selected an Invoice to pay, the script copied the UDFs from the Invoice on the line to the Payment header UDFs.  Then I didn't have to use shared variables in the report, I just had those header UDFs in the check form.  Since all of the Invoices are set up to create a separate check, creating a one-to-one relationship, this worked for them.