#C298P0BCK #C29J1BPM3 I'm trying to figure out why Display Name for Items is helpful or useful? It just seems to be more of an annoyance than anything. Why wouldn't one just use the item name/number and description? What does display name do besides make it impossible to import anything with items?

I agree with you but what our users like about display name is that they can search items using it especially in the Item field of the transactions. Our item codes are almost random letters and numbers.

thank @Luis I guess the searching by display name in the global search can be useful...I might just copy all the display names to a custom field with global search enabled, then it will give that ability but still not make life difficult for imports or other integrations

out of interest, why does display name make imports difficult?

@nsAI we got around this by just creating a small script that sets the items' external ID to match the name/ID field (we use 5-6 digit numeric item numbers) on create. Then any time we do imports we just set the item mapping to point at external ID of the item.

External id is a good way to handle it, just remember that item Name/ID are case sensitive, whereas external ids are not. And you can have duplicate item names across the different item types. i.e. these item names are all valid, but would cause duplicate external ids, which would fail.:

|      type      |   name   | externalid |
|----------------|----------|------------|
| Inventory Item | TESTNAME | TESTNAME   |
| Inventory Item | testname | testname   |
| Assembly Item  | TESTNAME | TESTNAME   |

Display name allows you to have another field that is searchable in the Global Search window other than the Item Name/Number. It causes issues on the Advanced PDF forms because NS hasn’t fixed the issue where it concats in the Item Number field on PDF form transactions. This can be corrected with Freemarker coding to prevent it from doing that. As far as the Display Name affecting CSV imports I am not following you there. If your referring to CSV imports where your updating active (not creating new) items) items you should be using the Internal ID for the items and you will never have a problem. The External ID should only be used for creating new items/transaction records. Since it has to be unique I always do an Excel formula on the CSV file to concat the current date with the Location, and Line # for transactions. I can see where the External ID is important when cutting over data as it can be a unique identifier for the record in your legacy system. Other than that you can just use the Internal ID that NS assigns to every record once it is created. No need for custom scripting the External ID.