Quel est le meilleur format pour un numéro de client, un numéro de commande ?

Question

Une grande entreprise internationale déploie un nouveau système de traitement des commandes par Internet et MOTO (Mail Order and Telephone Order). Vous êtes chargé, entre autres, de concevoir le format des numéros d'identification des commandes et des clients.

Quel serait, à votre avis, le meilleur format ? Veuillez énumérer toutes les hypothèses et considérations.

---

Réponse acceptée

La réponse de Michael Haren a été sélectionnée en raison du plus grand nombre de votes positifs, mais veuillez lire les autres réponses et commentaires car ils rendent la réponse de Michael plus complète.

Answer 1

Allez-y avec tous les chiffres ou toutes les lettres. Si vous devez mélanger, assurez-vous qu'il n'y a pas de caractères ambigus (Il1m, O0, etc.).

Lors de l'affichage/impression, mettez des espaces tous les 3 ou 4 caractères, mais assurez-vous que vos systèmes peuvent traiter les entrées sans les espaces.

Modifier : Une autre chose à considérer est d'avoir un moyen intégré de distinguer les commandes, les clients, etc. Par exemple, les clients commencent toujours avec 10, les commandes commencent toujours avec 20, les vendeurs commencent toujours avec 30, etc.

Answer 2

N'ESSAYEZ PAS encoder N'IMPORTE QUEL des informations mutables sur les clients/commandes dans les chiffres ! Et vous devez supposer que tout est mutable !

Certaines des suggestions ci-dessus incluent un code régional. Les entreprises peuvent déménager. Votre propre entreprise peut se réorganiser et modifier sa propre définition des régions. Les noms des clients/sociétés peuvent également changer.

Les informations relatives aux clients et aux commandes doivent figurer dans l'enregistrement du client ou de la commande. Pas dans l'ID. Vous pouvez modifier l'enregistrement du client/de la commande ultérieurement. Les identifiants sont généralement gravés dans le marbre.

Le simple encodage de la date à laquelle le numéro a été généré dans l'identifiant peut sembler sûr, mais cela suppose que la date ne soit jamais erronée sur les systèmes générant les numéros. Encore une fois, cette information doit figurer dans l'enregistrement. Sinon, elle ne pourra jamais être corrigée.

Est-ce que plus d'un système va générer ces chiffres ? Si c'est le cas, vous risquez de faire double emploi si vous utilisez uniquement des numéros basés sur la date et/ou des numéros séquentiels.

Sans en savoir beaucoup sur l'entreprise, Je commencerais par ce chemin :

• Un code à un caractère identifiant le type de numéro. C pour les clients, R pour les ordres (n'utilisez pas "O" car il pourrait être confondu avec zéro), etc.
• Un identifiant du système qui a généré le numéro. La longueur de cet identifiant dépend du nombre de ces systèmes.
• Un numéro de séquence, unique au système qui le génère. Un simple compteur.
• Un nombre aléatoire, pour éviter que les numéros de commande/client ne soient devinés. Faites-le aussi long que votre paranoïa l'exige.
• Une simple somme de contrôle. Pas pour la sécurité, mais pour la vérification des erreurs.

Comme d'autres l'ont souligné, le découpage en segments rend le texte plus lisible pour l'homme.

CX5-0000758-82314-12 est un nombre possible généré par cette approche . Il s'agit de :

• C : c'est un numéro de client.
• X5 : la station qui a généré le numéro.
• 0000758 : c'est le 758ème numéro généré par X5. Nous pouvons en générer 10 millions avant de retirer l'identifiant de cette station ou la station elle-même. Ou bien ne pas mettre de zéros et il n'y a pas de limite.
• 82314 : ce chiffre a été généré de manière aléatoire et donne une chance sur 100 000 de deviner l'identité d'un client.
• 12 : checksum.

Answer 3

L'un des principaux avantages de l'utilisation exclusive de chiffres est qu'ils peuvent être saisis beaucoup plus efficacement à l'aide de la touche 10.

La longueur de ce numéro doit être aussi courte que possible tout en englobant la totalité de l'espace de l'entité que vous prévoyez de cataloguer avec un peu de marge. Cela peut s'avérer délicat et il faut y réfléchir un peu. Un peu de théorie des ensembles peut vous donner le nombre de clés uniques auxquelles vous aurez accès, étant donné un groupe d'éléments.

Il est naturel, lorsqu'on parle, de décomposer les chiffres en ensembles de deux à quatre chiffres. En insérant des tirets dans un certain schéma, vous pouvez "forcer" le client à les répéter de manière plus efficace et sans ambiguïté.

Par exemple, le 323-23-5344, qui est bien sûr le format du numéro de sécurité sociale, permet d'indiquer au locuteur où il doit faire une pause lorsqu'il prononce le numéro. Il fournit également une délimitation visuelle lors de l'écriture du numéro et facilite la comparaison lors de la copie du numéro.

J'appuie la recommandation selon laquelle le système de commande doit masquer correctement la saisie afin qu'aucun tiret ne doive être saisi à aucun moment. Cette recommandation devrait être appliquée aux formulaires imprimés afin de fournir une indication claire de ce qui doit être saisi. Par exemple, une case imprimée pour chaque chiffre séparé par des tirets imprimés.

Je ne suis pas d'accord pour dire que trop d'informations devraient être intégrées dans ce chiffre, surtout si ces attributs sont susceptibles de changer. Par exemple, disons que nous donnons à "323" la signification de "est un client sympa", mais qu'il appelle quatre fois avec son attitude. Allons-nous alors changer son code client en "324", "est un crétin" ? Et s'ils sont dans la région 04 et qu'ils déplacent leur entreprise dans la région 05 ?

Si cela se produit, vous aurez le choix entre mettre à jour cette clé primaire dans toute la base de données ou vivre avec l'ambiguïté que les informations intégrées dans cette clé ne sont plus fiables, rendant ainsi toutes les informations intégrées dans les clés d'une utilité discutable.

Il est préférable de stocker les attributs susceptibles de changer dans des champs distincts de la base de données et de faire en sorte que le numéro de client soit une clé unique et immuable pour ce client.

Answer 4

Pour répondre aux questions de Daniel et Michael, c'est encore mieux si les chiffres séparés ont une autre signification. Par exemple, j'ai travaillé pour une entreprise où les numéros de compte étaient comme ceci :

xxxx-xxxx-xxxxxxxx

La première série de chiffres représente la région et la deuxième série représente le marché au sein de cette région. Une fois que l'on s'est habitué à savoir à quoi correspondent les chiffres, il est devenu très facile de savoir dans quelle région se trouve un compte sans même avoir à consulter le compte du client.

Answer 5

Je fais plusieurs hypothèses pour répondre à cette question ; certaines sont basées sur le fait qu'il s'agit d'une grande organisation internationale, et d'autres sur le fait que le format est pour deux types de tableaux distincts.

Des suppositions basées sur le fait qu'il s'agit d'une organisation internationale :

• Il est probable que chaque région doive fonctionner de manière indépendante, c'est-à-dire que la région A doit pouvoir ajouter des numéros de clients indépendamment de la région B.
• Chaque région utilise probablement une langue différente. Pour que les identifiants puissent être facilement tapés par les utilisateurs du monde entier, il est préférable de s'en tenir aux chiffres et aux espaces.

Hypothèses basées sur le fait qu'il y a deux tableaux pour lesquels ce format sera utilisé :

• Ce format peut être utilisé par plus que les deux tables listées, il doit donc pouvoir gérer un nombre arbitrairement grand de tables.
• Les utilisateurs expérimentés devraient être en mesure de savoir quel type d'identifiant ils ont sous les yeux sur la base des informations encodées dans l'identifiant lui-même.
• Il serait bon que les identifiants soient globalement uniques dans l'ensemble du système.

Considérations :

• Pour une entreprise mondiale, les identifiants peuvent être très longs si seuls des chiffres sont utilisés. Nous devrions essayer de limiter autant que possible la quantité d'informations étrangères encodées dans l'identifiant.
• Les identificateurs doivent être auto-vérifiables dans une certaine mesure, c'est-à-dire qu'un programme doit être capable de détecter un grand pourcentage d'identificateurs invalides sans avoir à chercher quoi que ce soit. Cela implique une somme de contrôle.

Format proposé : SSSS0RR0TTC

Le format proposé est aussi simple que possible, mais pas plus :

• C Le premier caractère (le plus à droite) sera une somme de contrôle de tous les autres caractères de l'identifiant. Une simple somme de contrôle suffira. Cela éliminera 90% des erreurs de frappe. Si l'on décide que ce n'est pas suffisant, il est possible de passer à deux chiffres, ce qui éliminera 99 % des erreurs de frappe.
• TT Les N chiffres suivants représentent le numéro du type de table. Aucun numéro de type de table ne peut contenir le chiffre zéro.
• Le chiffre suivant est un zéro. Ce zéro sépare le numéro du type de table de celui de la région.
• RR Les N chiffres suivants sont le numéro de la région. Aucun numéro de région ne peut contenir un zéro.
• Le chiffre suivant est un zéro. Ce zéro sépare la région du numéro de séquence.
• SSSS Les N chiffres suivants constituent le numéro de séquence. Ce numéro peut contenir des zéros.
• Par convention, chaque série de quatre chiffres est séparée par des espaces lorsqu'elle est imprimée ou tapée. En interne, ils ne sont pas séparés, mais cela aide l'utilisateur à les transférer correctement.

Exemples

• Assumant :

  • Table client type=1
  • Table de commande type=2
  • Code régional pour US-Alabama=1
  • Code régional pour CA-Alberta=43
  • Code régional pour l'Éthiopie = 924
• 10 1013 - Client n°1 en Alabama (3 est la somme de contrôle : 1 +1 + 1)
• 10 1024 - Commande n° 1 en Alabama
• 9259 0304 3016 - client # 925903 à Alberta, Canada
• 20 3043 4092 4023 - numéro d'ordre 2030434 en Éthiopie

Avantages de cette approche :

• 90 % des numéros mal saisis seront détectés
• Il existe un nombre illimité de types de tables
• Il existe un nombre illimité de régions
• Il y a un nombre illimité de numéros séquentiels pour chaque table.
• Les numéros d'identification sont globalement uniques au système. C'est important : un numéro de client ne peut pas être confondu avec un numéro de commande et vice versa.
• Chaque région peut ajouter indépendamment des numéros de séquence sans clé globale.

Inconvénients

• Chaque identifiant comporte au moins six caractères
• Les numéros de type de table et les numéros de région ne peuvent pas contenir de zéro car le zéro est utilisé pour séparer le numéro de séquence du numéro de région du numéro de type de table.