Special Character in Vendor Item

Reach out to your system admin to make the fix. Our support admin verified with Infor Support that the fix needed to be done on the POITEMVEN table using SQL.

Fritz:
Out of curiosity, did you try to make the change in PO13 or PO13.3? You can do a replace and inactivate in PO13.3. That will pullover to PO13 and also change PO25. You would still need to manually change IC11 and IC12.

Yes this needs to be done in sql In most cases. We had a case where a non visible space was uploaded through req centre. Cobol would ignore the character when performing actions but wouldn't return any db records. You would also need to check related tables as the character may have been copied to these locations and cause problems later on.

Agree with childs0. There are several forms/tables that "special" characters can cause issues with, but sticking with this example: VENDOR is a column in the PIVSET1 index (and probably other SETs) in the POITEMVEN table. If the character is something that is not in the characterset used by the apps and/or database server, then Lawson can't "read" it in order to do anything with it, including delete (or invalidate it via PO13.3, I suspect). Direct SQL modification is usually the only option, and is typically "approved" by Infor if you open a ticket for your issue. Even a "paint screen" approach can have limitations in this use case.
(In my career, I've often heard references to 'special' or 'bad' characters, but keep in mind that there are such characters in Spanish, French, German, etc. and I assume they work fine in Lawson implementations in other countries. Again it's a function of the charactersets/locales, etc. that you are set up for in your installations.)

For PO13s where the correct value isn't the one on PO25.6

Step 1: Mark the old item as Active if it's not. Then mark as default.
You should now have PO13 and PO25.6 agreeing with each other again.
Step 2: Inactivate and Delete correct item.
Step 3: Now use R to replace old item with correct item.

If it doesn't let you delete the correct item, it's even more fun.

Step 1: Remains the same. Mark the old item as Active if it's not. Then mark as default.
You should now have PO13 and PO25.6 agreeing with each other again.
Step 2: Keep the correct item active.
Step 3: Now use R to replace CORRECT item with something else. We literally type WRONGITEM as the part number to avoid any possibility of future confusion.
You should now have OLD item as the default tied to PO25.6, CORRECT item as inactive and WRONGITEM as active but not default.
Step 4: You should now be able to delete CORRECT item.
Step 5: Replace OLD item with CORRECT item using FC R.
PO13 and PO25.6 should now match with the CORRECT item
Step 6: You should be able to inactivate/delete OLD and WRONGITEM - but if not, you can at least inactivate them.

GOOD LUCK.

If you are an on premise customer your DBA may be able to find which field has hidden characters. Look at enhancment 87489. i requested that they strip out hidden special characters from addins but support said put in an enhancement. Go like it and we may be able to get it done. Other remedy is to use a paint screen to rekey data with out special characters. Our DBA has at the direction of support cleaned up those records with hidden characters. In addition have the people using the addins clean up thier upload file and ensure no special characters are in the upload (paste into notepad and back into excel)