If you know you way around the BOI, you could do this with a little bit of ProvideX and calculated fields.  A simple test in AP Manual Check Entry showed that when a invoice number is entered that is not on file, the Lines object's LastErrorNum property is set to "AP_ManualCheck_NewInvoice.Y" so you could just search the LastErrorNum value for the "NewInvoice" string and if it is found, you could conditionally set the comment text field to something like "SKIP".  Then on the Select tab, add the comment text field and configure it to select when the comment text is not equal to "SKIP".  You could use "NOF", "Not On File", etc as long as you are consistent.  You would also need to make sure you are resetting the LastErrorNum property before setting the invoice number to make sure to clear it from previous line records.

Unfortunately I'm not adept at BOI and your suggestion is over my head.

Maybe someone could shed some light as to why I wouldn't be able to simply enter a conditional expressing for InvoiceNo. where {AP_ManualCheckDetail.InvoiceNo$} = {AP_OpenInvoice.InvoiceNo$}?  

First, because AP invoices are not unique, and the same invoice # can be on multiple vendors.

Second, there is no link to the Open Invoice file when importing manual checks.

You could do something in a pre-write script for the check header table, doing the lookup to Open Invoices (using the full key fields for that table) and failing the record when not found... filtered to your specific VI job's program name if you want, but it is not something you can do directly in VI (that I know of... without Perform Logic, which is not something I do).

Thank you for the explanation, Kevin.

There is some perform logic to check for duplicate invoices, but I have no idea how to update it to check a different file.

https://www.sagecity.com/us/sage100_erp/f/sage-100-personalization-customization-and-productivity-tools/37605/4-3-perform-logic-for-a-p-invoice-duplicates/324886#324886

As Kevin said, there isn't a link at that point.

I was considering a UDS, but you may want to filter it so it only triggers during the VI import so it doesn't affect manual entries. If you embed everything in the VI job, you don't have any additional dependencies or have to worry about filtering a UDS.

If you use a UDS, then you should still be able to use the LastErrorNum instead of doing your own lookup in AP_OpenInvoice.  Might as well leverage existing functionality when possible because Sage 100 is validating the invoice number entered and setting the warning when it is a new invoice number.  If the warning is set, then you would use oScript.SetError to force it to fail.

Using the LastErrorNum shouldn't be needed... since InvoiceType indicates new invoices.

I wonder if this could be brought in as a FileAssign temp field (before the line is saved), and override the line payment amount when New.  Hmm... something to test perhaps.

I didn't look that close at the file layout, but you are right, should be able to use InvoiceType on the Select tab and have it set to not equal "A" and that will cause them to not be selected.  I did a simple test with Manual Check Entry through the UI and confirmed that the InvoiceType is set to "A" after entering a new invoice number and answering yes to the prompt asking if it is a new invoice.  The prompt is bypassed during the VI import but would imagine the InvoiceType would still be set in the same manner.

EDIT: Guess I spoke to soon, the InvoiceType field does not appear in the list of available fields.

Tried this option with different files and modifications but couldn't get it to compare.  Thank you for the suggestion though.