Name and code

19.04.2018

A colleague of mine who is working on implementation of a modern procurement software complained to me recently about following story. They changed names of the fields in the application together with the implementation vendor in order users (and external partners - vendors) have the screens in local language. However, they will probably have an issue with an old stupid ERP system. This ERP will not accept that they will send to it now signs with special diacritics. So either they will have to go back to the English terms or they will use local language without diacritics. They will not be able to provide users with the proper language. And this all due to the old stupid system with which they have to integrate. Funny story and an opportunity to think about metadata.

I am afraid that in this case the stupid one is not the old system but the "modern" one that does not distinguish betwee data that are displayed to the user (according to the language set by the user) and data that are exchanged with other systems.

ObjectGears requires at all entities (classes, columns, reports etc.), that have a (localized) name, also a code which allows for problem-free characters only. The code is then used for mapping at data exchange between systems.

The same approach should be used also with data themselves. If we create a master data table for users, we may want to work with various variants depending on user language. However, let`s create also a code value for transfers to other systems or for work in program code.

It may sound as a detail but it is a good example of how some applications are developed. It is worth to notice such details since it can help us to select a proper software. If the authors did not consider such differences, it is almost certain that their work will contain many other things that were not thought through.

Top
This website is using cookies files to provide services and analyse visits. You agree with that by using this website.     Further information