webERP Forum

Full Version: Non-alphanumeric characters in supplier ID
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I am in the process of trying to get webERP to live side-by-side with our existing ERP/CRM software until our webERP rollout is sufficiently complete that it can start taking over functions from our old ERP. At this point I have vendors/suppliers staying in sync via a custom php script.

The problem is with a few vendor IDs in the old ERP that use characters that are not allowed in webERP. The vendor ID in the old ERP allows 5 characters, and 98% of our vendor IDs are entirely alphanumeric, but there are a few that are not. There are a few with ampersands, a few with hyphens, one with a leading space(?), and even one with an apostrophe. These vendors import with their IDs intact because I'm more or less sneaking around behind webERP's back, but when I try to view/edit the ones with ampersands and the one with the apostrophe, bad things start happening, understandably. The hyphenated ones, however, seem to be well-tolerated.

There are few enough of these where I'm pretty sure if I restrict the old ERP to alphanumeric-only for new vendors in the future and override the forbidden characters with something on the webERP side on import/update everything should be fine. However, I'm not sure what would be well tolerated. Has anybody run into a similar situation where some kind of non-alphanumeric special character can be used to override blatantly bad characters like & and ' without breaking things? Failing that, something like an X would probably be OK, but a little odd (AT&T would become ATXT, etc.) and there may be some collisions.

Changing IDs in the existing ERP is not really an option, as there are a ton of databases derived from data in that ERP that are dependent upon those IDs and to go throughout the entire system and replace them en masse would be a monumentally complex task, so I'm looking for a work-around here. Thoughts?
I think your idea of str_replace characters in the dodgy codes is the answer. I don't suppose the "munting" of the abbreviations is too major of a compromise in the circumstances.


Tim has asked me to post this:

"These days none of these characters will provide any trouble to webERP, I did the code to stop any problems a long time ago. Really we should take out this check in the Suppliers.php script. I got into trouble for suggesting this before, but I really think it is worth doing.

The only thing that may happen is that there may still be a few inquiries/reports that show the ampersand as & but most of these have been done, and the only way we will find if any are left is to actually remove this out dated check.



Actually these characters will now work perfectly well for supplier codes. The restrictions were put in because the characters weren't correctly escaped or quoted before, but I did this works some time ago so the illegal characters function is obsolete. I got into trouble for suggesting this before, so don't want to upset the powers that be by removing it myself.

Have fixed up the problems with ampersands and apostrophes set out below

I would hate to introduce trouble , but if you think we no longer need these illegal character checks then please do remove them. It will need a lot of testing. To be sure.
I'm glad there is some tolerance for these characters, but ampersands and apostrophes do not work perfectly well (not that I had expected them to.)

For example, AT&T's ID is... well... AT&T. If I do a vendor search on "AT&T" in the partial code field, I get no results. If I just search for "AT", AT&T is in the results, but if I select it, I get a red error box above the Vendor Data table on SelectSupplier.php: "ERROR Message Report : The date does not appear to be in a valid format. The date being converted from SQL format was: " The same error message shows at the top of Suppliers.php (and all inputs are blanked out) if I choose "Modify Or Delete Vendor Details" on SelectSupplier.php.

We have another vendor with an apostrophe in the ID. That one doesn't give me an error on SelectSupplier.php if I select it, but if I go to edit details, the apostrophe is escaped with a \ in the query string parameter to Suppliers.php and the invalid date format error shows there and the inputs come up blank. If I take out the escape character in the query string, the vendor loads just fine. However, if I try to save any changes, I get yelled at for having an invalid supplier ID.

I'm not surprised that these don't work, I just wanted to point out what happens with these two specific characters. The vendor with the leading space and the ones with hyphens seem to be behaving "normally."

I realize I'm breaking conventions here, but I just wanted to point out that certain non-standard characters will definitely break things differently than others, and that the error messages are obviously not indicating what's really going on.

Thanks for the input, y'all...
Thanks for the feedback - sounds like the CheckForIllegalCharacters function needs to stick around then - albeit perhaps with a subset of characters.
Reference URL's