Keep in mind that the following is a completely untested, off the top of my head idea, and might not be worth the digital ink with which it was written.
What about maybe first building a calculated field that tests if the last character in the initial address block field is numeric (so the field already has a zip code)? If it is, great, use that. But if it isn't, then add a fake one, say all 9's, to the initial address block field.
Now run that calculated field through the wizard, and have one last calculated field that checks to see if the Zip code field generated by the wizard is all 9's and if it is display no value ("" or Null 1/0 for Numerics), otherwise use the real zip, then hide the generated Zip field.
Worth trying maybe?
Surprisingly, this actually worked. And rather well to boot!
As a test I copied a few customer blocks from the Classic.prn sample report to Notepad and removed the zip codes. You're correct, that really does a number on the address block wizard.
Build a RevisedAddress field using:
and run that into the wizard.
Then add another field to check the resultant zip code:
and finally hide the initially generated zip field, PreCusPostalCode in the example above.
Thanks. Adding a placeholder zip code is a good idea. I've done things where I create calculated fields for city and state that manually parse the source field is the processed zip code is blank. It works, but it's a bit of a hassle. I'm just surprised Monarch doesn't pick out the state abbreviations, since it seems like that would be pretty straightforward.