We turned on Breaking and Routing for AR Invoices the other day. We have a Data Directive saying “If an Invoice is Posted and is either a Shipment or Deposit, and is not a Credit Memo or Unapplied Cash, then Auto Print X Style ARForm”
Breaking and Routing then breaks on InvoiceNum and determines if there’s a Primary billing Email to send to. If there is, email it, otherwise print it.
This worked great in tests and Live for about a day.
Today an accountant posted an entire group (tested fine) and most did not print/email at all. Two that did print had the Invoice Numbers swapped. I’m at a loss. No idea what could’ve happened.
Some things I noticed and don’t know if they matter:
while the entire group Posted, most invoices did not close
There was one CM in the group that I’d have expected to get passed over (and it did but might’ve caused InvoiceNums to be off by one??)
For some reason breaking and routing seems particularly fragile on AR invoices. We’ve had problems for about two years now.
One issue is that ARForm (at least our version) has code in the SSRS part to set the invoice number, and it hooks into the line data to print the number for the form as a whole. We have identified at least one circumstance where that leads to the number being wrong - when an invoice runs to more than one pages, and the last page has no lines, only a total. We get around that by using a BPM, as you mention, which makes sure each invoice prints independently, but we still get the odd few invoices not printing at all for reasons we can’t get to the bottom of.
Sorry, that isn’t really an answer to your problem. But if there are any clues in there and you do get some answers then I’ll also be interested to hear.
I do a lot of work with Print Routing and have not run into this issue yet.
I assume your break table is Invoice Head and you are breaking on the invoice number.
Can you check something in the auto print DD? check if the report parameters are configured for the invoicenum to equal the specified field?