PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 12/9/2022 8:06 PM by  Fake_water
Special Character in Vendor Item
 6 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Fritz Osorio
Systems Analyst
Private
New Member
(4 points)
New Member
Posts:2


Send Message:

--
11/23/2022 3:00 PM

    I'm not sure if there's another thread with a resolution on this....

    My situatiion is that a special character was uploaded as a vendor item# so I tried adding another PO13 record with the correct vendor item# and made it default (it did not automatically default as it has the same vendor#).

    I'm now trying to inactivate or at best delete the erroneous record but "Vendor item does not exist" pops up....

    Any advice....

    JMAN818
    SUPPLY CHAIN ANALYST
    Private
    New Member
    (3 points)
    New Member
    Posts:1


    Send Message:

    --
    11/30/2022 7:38 PM
    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.
    LaDora
    Materials Management Supervisor
    Glendive Medical Center
    Veteran Member
    (115 points)
    Veteran Member
    Posts:47


    Send Message:

    --
    12/1/2022 4:11 PM
    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.
    childs0
    NA
    NA
    New Member
    (3 points)
    New Member
    Posts:1


    Send Message:

    --
    12/1/2022 5:55 PM

    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.

    LarryD
    APPLICATIONS DEVELOPER
    Private
    Basic Member
    (12 points)
    Basic Member
    Posts:4


    Send Message:

    --
    12/6/2022 4:40 PM
    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.)
    Kat V
    Sr Supply Chain System Analyst
    South Broward Hospital District
    Veteran Member
    (2942 points)
    Veteran Member
    Posts:1006


    Send Message:

    --
    12/7/2022 9:10 PM
    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.
    Fake_water
    ERP Analyst III
    Private
    New Member
    (3 points)
    New Member
    Posts:1


    Send Message:

    --
    12/9/2022 8:06 PM

    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)

    You are not authorized to post a reply.