No code changes are done in scope of this issue. Enhancement to mapping logic will be done in scope of  

confirmed that work-around have resolved the issue on their test environment and library do not have a plan to test it on their production tenant for now.

cc:  

Discussed with today in standup:

• Vendor code with brackets causes problems with DI's organization lookup because we append the vendor ID (in brackets) to the code when doing the lookup. Does not cause the same problem in the Orders app, so the issue is with our lookup, not with the overall order app

• Simplest solution: Ask library to change the 5 (out of 75K) affected vendor codes

• If no, then see if we can adjust the DI lookup to ignore any brackets except the last open/close brackets in the sequence (do that work in the scope of this ticket if necessary to resolve the RRT issue, or in a new ticket, if not needed for RRT fix)

• Longer-term: if there are punctuation marks that will cause problems for us in the vendor code field, talk with Thunderjet about possibly imposing some UI/BE restrictions on problematic characters in all associated apps, so that lookups in Orders, Invoices, Organizations, and Data Import will all function the same way

cc:

From SUPPORT SIG: Is this reproduceable in a Community Environment? If it is, should it be bumped up in priority?

  and this issue is impacting NLA highly - just wanted to bring this to your awareness. 

CC