Help needed - Choose Phone Format Rule no longer working

[Amanda VB]

I'm using FusionPro VDP Creator version:  11.2.0

and Acrobat version: 2020.005.30467

The strangest thing has started happening, the default rule for Phone Number rule has just stopped working.

I haven't changed anything on them, I keep the rule as is but it won't return the selected format.  I will just return whatever the client enters "as-is"

 

[Douglas Cogan]

If you compose this record of output do you get any errors in the log file?

[Amanda VB]

Hello Douglas,

No errors in the log when I compose

[Dan Korn]

Can you post the job, or a minimal example which demonstrates the problem?

[Amanda VB]

So I pick this rule in FusionPro in Acrobat:

 

And make these selections:

 

Then add to the proper field in a text box:

 

Then use Preview and/or Compose with an intentionally wrong input for the phone number to make sure the rule works:

 

But in recent few I've done, the rule no longer seems to be functioning (screen shot of the preview, composed file looks the same):

 

 

[Dan Korn]

So you're giving it "intentionally wrong input."  What result are you expecting?

Also, you say that "in a recent few I've done," it's not working.  What was different before?  Were you on an older version of FusionPro?

What was the result previously with the intentionally wrong input?

Also, does it work if you give it valid input, such as "000.000.0000"?

[Amanda VB]

The rule is meant to correct a phone number format, so if their format is supposed to be 000-000-0000 then I put 000.000.0000 in the test to make sure it gets corrected properly.

Yes it seems to be recent, like the last few months.  No updates to FusionPro, but could have been updates to Creative Cloud/Acrobat.

Before when I selected that rule it would change the input from 000.000.0000 to 000-000-0000 as requested in the rule

[Dan Korn]

Sorry, I'm confused.

So when you give the rule "000.000.0000", does it change it to "000-000-0000" or not?

An input value such as "000.000.0000" should be converted, but "000.000.000" should not, as that's not a valid input format.  (Note the three digits after the last delimiter vs. four.)

I think the best way forward here would be for you to collect up a small sample job which reproduces the problem and post it here.