Special Characters

Jack, You're going to have issues with a space ' ' and/or a forward-slash '/' for sure. You may have issues with the colon ':' and or a semi-colon ';'. The dash '-' should be less problematic, but I wouldn't bank on that in every case. I have to ask, do you have a consultant guiding you through these decisions? This is something your functional SME consultant should be telling you upfront. Kwane

Thanks Kwane for your quick response. We are working with consultants from INFOR and they did not identify this as an issue. But we have had issues in the past with other systems, so I wanted to reach out and confirm our concerns. Thanks again and if you have any additional advice, it would be greatly welcomed and appreciated! Thanks, Jack

I have been with two different organizations that have used "-" before in Location and we never had issues. We also use "-" in employee groups. But while Lawson may allow it your secondary vendors may not, you will need to test each of those specifically.

Kelly H's experience is likely what you will encounter, specially relating to the dash, but needs to be mapped out at the high-level to be sure all systems you are implementing will also accept it. I have seen the dash cause issues in portal, depending on usage. That's why I couldn't give a blanket all clear on its usage in key fields. Additionally some forms won't allow a dash as part of a key identifier, no matter the scenario. For those reasons, it's not best practice to use them as key identifiers, especially since there is a need for uniformity with the setup on the financial side, and the inclusion of Landmark apps. This is why I ultimately stated your implementing consultant should be advising you, as they know your specific scenario, implementation requirements, and state of the data you plan on importing from your previous systems.

Additionally you will run into difficulty with some or all of the following characters: @ (at-sign) _ (underscore) & (ampersand) ? (Question mark) $ (dollar sign) * (asterisk) | (pipe) # (number sign; octothorp, per IBM and AT&T) Internally, I'd also avoid back-slash '\', greater-than '>', and less-than '<', as this could cause unintended issues when parsing exported data. I think most other characters should be fine, but you'd need to test it

We have seen issues caused by the special characters Kwane listed when creating/parsing ags calls, using microsoft add-ins, and especially when they are typed into comments fields in Lawson Financials (? and & in particular). You'd do well to heed his advice to avoid them.

I may be speaking out of turn but my experience is that mostly these issues occur when you are doing something that relies on DME or AGS calls. The problem lies in the fact that for some, unfathomable to me, reason, Lawon decided to pass arguments to DME and AGS calls via HTTP URLs without properly escaping said arguments.

This is the equivalent of the XKCD 'Little Bobby Tables' cartoon ( https://xkcd.com/327/ ). Any arguement value that contains a character that is reserved in URI protocol is going to cause a problem unless you pre-emptively percent encode it ( https://en.wikipedia.org/wiki/Percent-encoding ) or otherwise protect it from actually be seen by the HTTP server as that special character.

Outside of those cases, I've never seen an issue with any characters being used in any of the fields in which they are allowed.

Sam, You're correct, but the OP didn't specify use cases or methods of data consumption. Since it was left wide open, I wanted to cover all the bases. Now with that said, a point you made is worth repeating: "I've never seen an issue with any characters being used in any of the fields in which they are allowed." This is mostly true. Exceptions notwithstanding, the issue for the OP is that not every character that could be considered special is allowed for use in a key identifier uniformly. This could break the OP's use cases and planned integration requirements.

Thanks so much for all the information, please keep any feedback coming! It is really helping us. Our functional users and Consultants have make the design with the special characters listed above, but now as I stated we are concerned about how this will interface internally and to outside vendors. Thanks again!

We'll be sure, the space, WITHIN A KEY IDENTIFIER, will not be allowed. I'm not aware of any form, that has a key field that allows a space in the value (with the possible exception of Activities).

Spaces are OK in some cases (for instance, I've seen them in HR55 employee group names where they are part of a key), as are underscores and dashes. In addition to encoding issues, avoid special characters as part of hierarchical structures; as it limits the number of characters you have available (for instance in activities, accounting units, etc.), and it also makes it harder to change the hierarchies.

John, thanks for chiming in and correcting any misinformation.

and for goodness sakes, don't use the . (period)

Our experience with character issues is more driven from the database that Lawson runs on than the Lawson application itself. For "key" fields - codes and such we're strictly letters and/or numbers. No spaces. Description fields we're slightly more liberal allowing period, dash and slash (. - /) A piece of hard learned wisdom when setting up and loading these values using MS AddIns or SpreadSheet designer, be careful for unseen trailing characters - ie: if the Excel cell had an line return in it it will load unseen into the database and produce some fascinating results -