design - planilla - partes de una orden de compra

¿Cuál es el mejor formato para un número de cliente, número de pedido? (21)

Usamos ceros a la izquierda para algunos de nuestros "números" de referencias donde trabajo y no puedo decirle cuántas horas desperdiciadas he tenido en los últimos siete años forzando a Excel a tratarlas como texto. No lo hagas
Los enteros de incremento automático son buenos para las computadoras, pero reducen en gran medida la capacidad de los seres humanos para detectar errores. La importancia de eso dependerá de su negocio. Trabajo con datos relacionados con la propiedad (vivienda) y nuestra referencia principal tiene incorporada la puerta de entrada. No es elegante, pero significa que el personal administrativo experimentado puede detectar el 90% de los errores menores (cuando recibimos facturas, etc.) antes de que se acerquen a una base de datos. Pero en un entorno en el que no se depende de ese tipo de proceso, este argumento es menos convincente.

(Ahora, algunas personas han advertido fuertemente sobre el uso de datos significativos en las referencias, ya que podría cambiarse, y hay algo de verdad en eso, pero puedes ser inteligente. No tienes que elegir algo obviamente voluble, como si la persona está casada - puede anclarse en eventos pasados como un personaje que representa la región en la que abrió una cuenta en particular. Incluso si no lo hace, tenga algún tipo de patrón para ayudar a la comunicación con los clientes. He trabajado en varios centros de llamadas. y la gente a veces llega al teléfono con cada pieza de documentación desde el certificado de nacimiento en adelante mientras tratan desesperadamente de encontrar su cuenta / orden / número de cliente. No creo que decir "Será un número entre 1 y 100 billones" sería muy útil)

Se ha dicho, pero no cree referencias enormemente largas. Somos gente ocupada, no tenemos tiempo para manipular esta basura sobre un sistema telefónico y cometer un error en el dígito 17 solo para reiniciar (nuevamente). Algunos de sus clientes pueden tener discapacidades y es probable que un número creciente supere los 55 años. Una vez más, ten cuidado con los ceros. Verá números de órdenes de compra y similares con catorce dígitos. ¿Cuántas órdenes creen que van a colocar?
Si va a haber agregación de datos fuera de su red (y por lo tanto no está conectado a su base de datos), tenga algún tipo de patrón de control de dígito / expresión regular que sus socios / proveedores puedan verificar que no hayan cometido errores. Un ejemplo de esto es el sistema de numeración de suministro eléctrico del Reino Unido (MPAN) es un buen ejemplo de esto: diseñado para que las personas mantengan sus propios registros sin tener que descargar la gran lista de cada medidor de electricidad en el universo para comprobar que no han realizado un error.

Una gran compañía internacional implementa un nuevo sistema de manejo web y MOTO (orden por correo y orden telefónica). Entre otras cosas, tiene la tarea de diseñar el formato para los números de identificación del pedido y del cliente.

¿Cuál sería el mejor formato en tu opinión? Por favor, enumere cualquier suposición y consideraciones.

Respuesta aceptada

La respuesta de Michael Haren se seleccionó debido a la mayoría de los votos, pero lea otras respuestas y comentarios a medida que completan la respuesta de Michael.

El mayor problema aquí es tratar de no pensar demasiado el problema.

Aunque tengo más experiencia en sistemas de comercio electrónico, creo que algunos de los puntos incluidos en esta publicación podrían aplicarse a los sistemas de pedidos por correo y pedidos por teléfono.

Para pedidos, un entero de incremento automático funciona perfectamente como la clave principal en la base de datos, así como también el número que el cliente verá en su factura. No hay absolutamente ninguna razón para crear un algoritmo demasiado complicado para sus números. Si desea saber de qué país / región provienen, utilice un campo separado en su base de datos. También si le preocupa que sus competidores lo espíen; ¡Déjalos! Si su negocio gira en torno a espiar a sus competidores porque no está generando suficientes ingresos, lo más probable es que su businessidea no sea buena en primer lugar. Además, si quieres engañar a tu competencia, puedes crear tu propia secuencia de comandos que autocreará pedidos falsos. Si su sistema de comercio electrónico está bien diseñado, entonces esto no será un problema.

Cosas clave usando un número entero de incremento automático:

Todos los números / dígitos => más fáciles de comunicar, sin ambigüedades por teléfono, funciona para todos los idiomas / culturas que usan 0-9 como su sistema numérico
Sin codificación adicional
Se ve bien en la factura y es la cantidad más corta posible de dígitos que un cliente necesitaría deletrear por teléfono.
Funciona para pequeñas y grandes empresas
Es escalable
Mentalidad / Atención al cliente (Lo que es mejor para el cliente) (ver viñetas 1 y 3)
Sencillo

Siempre que sea o lo que sea que diseñe siempre debe comenzar con lo que sea mejor para el cliente. Al final del día, ellos son los que ponen comida en su mesa. Un cliente feliz es un cliente que regresa.

Guau, ¡qué pregunta tan simple pero reveladora! Y qué tantas respuestas contradictorias. Creo que hay 3 respuestas candidatas obvias aquí:

1) Use un entero largo autoincrementing. 2) Use un GUID 3) Use un tipo de compuesto que incluya otra información en el ID.

Para sistemas más simples, y especialmente sistemas basados en la web donde todos los usuarios están llegando a una base de datos central, (1) funciona bien. Tiene la ventaja de que los números se mantienen lo más cortos y simples posible, pero no más cortos, evita los caracteres alfabéticos (se sorprendería de cuán diferentes son los nombres de las mismas letras en diferentes países: un país E es otro país). No distingue la ID del pedido de la ID del cliente de forma intrínseca, pero siempre se puede anteponer o anexar una "C" u "O" a cada una y colocarlas silenciosamente en la entrada. Tampoco tiene una suma de comprobación o verificación de error.

Para los sistemas distribuidos donde muchos componentes de software necesitan crear los números sobre la marcha, sin referencia a una base de datos maestra (2) es el único camino a seguir. Tienen la ventaja de ser en gran parte errores de comprobación, ya que el espacio de direcciones es tan grande, pero por la misma razón, son demasiado largos y alfanuméricos para leer cómodamente por teléfono.

En cuanto a (3), integrar la información de la región o la fecha de hoy en el número, ese es el tipo de ideas que los desarrolladores experimentados se entrenan a sí mismos. Parece una buena idea al principio, pero siempre regresa para perseguirte. Considere el caso en que un cliente se mueve a un nuevo estado, o un pedido se vuelve a modificar manualmente una semana después de emitido originalmente. Estos elementos de información pertenecen a tablas relacionadas donde se pueden editar independientemente de la ID que debe representar la identidad de las entidades solamente. Para repetir: NUNCA CODIFICAR LOS DATOS DE LA EMPRESA EN UNA IDENTIFICACIÓN O LLAVE PRINCIPAL: cada vez que lo haces, dejas una bomba de tiempo para que otros limpien un día.

Dado que se trata de un sistema centralizado (basado en el teléfono), iría con la opción (1) hasta que surja una clara necesidad de cambiar. Más simple es usualmente mejor. Inserte guiones como otros sugieren y antependen o pospenden una suma de verificación y / o letra de identificación si es necesario.

Haría que mis números de orden sigan este formato:

ddmmyyyy-####-####

Donde #### - #### se restablece a cero al comienzo de cada día. Esto hace que sea muy fácil correlacionar los pedidos con la fecha en que se realizó.

Para las identificaciones de clientes, mezclaría letras mayúsculas y números, pero como Michael dijo, evite las letras comúnmente confundidas (0, o, L, 1,5, s). Esto te dará 30 personajes para tratar. Si usa 20 caracteres, eso le dará casi un rango de 64 bit de ID de cliente, bastante bueno para la seguridad. Asegúrese de utilizar un generador seguro de números aleatorios al generar ID. En cuanto a cómo mostrar el formato, debe ser el siguiente:

####-####-####-####-####

Como dijo Michael nuevamente, asegúrese de que su sistema pueda manejar guiones, espacios, sin espacios o sin guiones. (Simplemente debe quitar todos esos caracteres de la entrada antes de la validación).

¡Espero que eso ayude!

Hay varias suposiciones que hago al responder esta pregunta; algunos se basan en el hecho de que es una gran organización internacional, y algunos se basan en el hecho de que el formato es para dos tipos de tablas diferentes.

Supuestos basados en el hecho de que es una organización internacional:

Es probable que cada región necesite operar de manera independiente, es decir, la región A debe poder agregar números de clientes independientemente de la región B
Es probable que cada región use un idioma diferente para que los identificadores puedan ser fácilmente configurables por usuarios de todo el mundo, lo mejor es limitarse solo a los números y espacios.

Suposiciones basadas en el hecho de que hay dos tablas para las cuales se usará este formato:

Este formato puede ser utilizado por más de las dos tablas enumeradas, por lo que debería ser capaz de manejar una cantidad arbitrariamente grande de tablas.
Los usuarios experimentados deberían poder saber qué tipo de identificador están buscando en base a la información codificada en el propio identificador.
Sería bueno si los identificadores fueran únicos en todo el mundo dentro de todo el sistema.

Consideraciones:

Para una compañía global, los identificadores pueden ser muy largos si solo se usan los números. Deberíamos intentar limitar la cantidad de información extraña codificada en el identificador tanto como sea posible.
Los identificadores deben ser autoverificables de forma limitada; es decir, un programa debería ser capaz de detectar un gran porcentaje de identificadores inválidos sin buscar nada en absoluto. Esto implica una suma de comprobación.

Formato propuesto: SSSS0RR0TTC

El formato propuesto es lo más simple posible, pero no más simple:

C El primer carácter (más a la derecha) será una suma de comprobación de todos los demás caracteres en el identificador. Una suma de comprobación simple servirá. Esto eliminará el 90% de todos los errores de tipeo. Si se decide que esto no es suficiente, se puede ampliar a 2 dígitos, lo que eliminará el 99% de todos los errores de tipeo.
TT Los siguientes N dígitos representan el número de tipo de tabla. Ningún número de tipo de tabla puede contener el dígito cero.
El siguiente dígito es cero. Este cero separa el número de tipo de tabla del número de región.
RR Los próximos N dígitos son el número de región. Ningún número de región puede contener un cero.
El siguiente dígito es cero. Este cero separa la región del número de secuencia.
SSSS Los próximos N dígitos son el número de secuencia. Este número puede contener ceros.
Cada conjunto de cuatro números está separado por espacios cuando se imprime o tipea por convención. Internamente no están separados, pero esto ayuda al usuario a transferirlos correctamente.

Ejemplos

Asumiendo:
- Tipo de tabla de clientes = 1
- Tabla de tabla de pedidos tipo = 2
- Código de región para EE. UU.-Alabama = 1
- Código de región para CA-Alberta = 43
- Código de región para Ethopia = 924
10 1013 - Cliente n. ° 1 en Alabama (3 es la suma de comprobación: 1 +1 + 1)
10 1024 - Orden # 1 en Alabama
9259 0304 3016 - cliente # 925903 en Alberta, Canadá
20 3043 4092 4023 - número de pedido 2030434 en Ethopia

Ventajas de este enfoque:

90% de los números mal escritos serán atrapados
Hay un número ilimitado de tipos de tablas
Hay un número ilimitado de regiones
Hay un número ilimitado de números secuenciales para cada tabla
Los números de identificación son globalmente únicos para el sistema. Esto es importante: un número de cliente no puede confundirse con un número de pedido y viceversa.
Cada región puede agregar independientemente números de secuencia sin una clave global

Desventajas

Cada identificador tiene al menos seis caracteres
los números de tabla y los números de región no pueden contener un cero porque el cero se usa para separar el número de secuencia del número de región del número de tabla.

Para construir sobre las preguntas de Daniel y Michael: es incluso mejor si los números separados SIGNIFICAN algo diferente. Por ejemplo, trabajé para una empresa donde los números de cuenta eran así:

xxxx-xxxx-xxxxxxxx

El primer conjunto de números representaba la región y el segundo representaba el mercado dentro de esa región. Una vez que se acostumbró a saber de qué números se trataba, se hizo realmente fácil decir en qué área se encontraba una cuenta sin siquiera tener que mirar la cuenta del cliente.

Para mí, mi preferido es obtener la combinación de fecha + contador para la transacción de hoy. Tuve el reto de obtener solo un número de orden de 5 dígitos. Entonces con eso, se me ocurre lo siguiente a continuación:

Tengo que obtener la fecha actual, entonces
obtener el contador actual para la transacción de hoy y luego agregar 1.

Decidí usar un conteo mayor que el decimal (10), así que uso la base 16 para contar. Así que con eso, si obtendré el máximo de 5 dígitos de hexadecimal (FFFFF) que serán 1,048,575 cuentas. Al incluir la fecha, puedo decir que puedo obtener 1,048,575 cuentas por día. Entonces, para hacer que esto sea único cada día, mezclé la fecha obteniendo la suma de lo siguiente:

Recuento del año actual a partir del año de la implementación que es 1
Hora actual (máx. 24)
Día actual del año (máximo es 365)

Así que con eso, tendré un máximo de 3 caracteres de inicio para mi conteo. Entonces esa será la transacción actual de XXX + Hoy. Ejemplo:

Fecha actual: 2014-12-31 01:22 PM Fecha de implementación: 2010 Total acumulado para la transacción de hoy: 100

Recuento: (5 + 13 + 365) + 101 = 383101 Número de pedido: AD-5D87D

AD solo hay un prefijo de número de orden personalizado. Por lo tanto, para el momento en que esté fuera de servicio el número será 1000000 años desde el momento de mi fecha de implementación.

De todos modos, esta no es una buena solución si crees que tu transacción por día puede ser tan alta como 1000000 cuentas.

Puede agregar una pequeña suma de comprobación (usando XOR por ejemplo) para asegurar (mejorar) la corrección de los identificadores proporcionados. Si es por correo, considere la codificación z-base-32 . Pero aquí, con las órdenes telefónicas, puede preferir la identificación decimal.

Se adhieren a los números (sin caracteres ni cosas especiales):

Se puede ingresar fácilmente en un flujo de IVR
es internacional - Sin problemas de idioma
Sin confusión en caracteres vs. números - O vs. 0, I vs. 1
Mientras que 0 como líder no tenga sentido, puedes almacenarlos / manipularlos de manera más efectiva

Siempre me quedo con los números de incremento automático, y siempre siembro la secuencia lo suficientemente alta para que todos tengan una cantidad consistente de dígitos, parece ser menos confusa.

También a veces comienzo un número de pedido, digamos 6 dígitos, comenzando con 200,000 y números de clientes con 5 dígitos, comenzando con 10,000, que me daría 90,000 números de clientes únicos y 800,000 números de orden únicos para usar, y siempre se puede decir con mirándolo ya sea un número de cliente o un número de pedido. (es decir, si un representante del cliente solicitara un número por teléfono, sería obvio cuál era cuál)

Sin embargo, no crearía lógica en la aplicación que dependería de eso, por lo que incluso si se volcara, al sistema no le importaría.

Sugeriría usar identificadores de 16 dígitos que cuando se imprimen o se muestran a los clientes se formatean en el formato de xxxx-xxxx-xxxx-xxxx, pero se almacenan como números sin los guiones en su sistema.

La razón para usar este formato es que hace que sea más fácil para las personas que leen el número en el teléfono leer, ya que pueden hacerlo en grupos de 4 en lugar de tratar de recordar cuánto han dicho ya.

Si desea, los primeros 4 dígitos se pueden usar para identificar el tipo de número, 1000 para clientes, 2000 para proveedores, 3000 para pedidos, 4000 para facturas, etc.

El segundo conjunto puede entonces por un identificador de año / mes si desea mantener ese tipo de información codificada en el número mismo, usando un formato de yymm, de modo que 1000-0903-xxxx-xxxx sería un cliente ingresado en marzo de 2009.

Esto luego te deja con 8 dígitos para los datos reales.

Consideraría que el uso de letras en los identificadores es una muy mala idea para cualquier sistema que trate con teléfonos, ya que las diferencias en los acentos y las comprensiones son tan variadas que la gente se enojará al intentar que alguien identifique su identificador. no puedo entender su acento correctamente

Una consideración adicional a la cuestión de formato, en el código, crea una clase separada para OrderId y CustomerId. Estas clases son inmutables y validan su entrada para garantizar que sean identificadores aceptables. Además, ningún valor podría ser una ID de pedido y una ID de cliente.

El enfoque más simple sería simplemente tener los valores de respaldo para OrderId en entradas que comiencen con 1, y CustomerIds sean entradas que comiencen con 2 o algo similar.

Una ventaja principal de usar solo números es que se pueden ingresar mucho más eficientemente con 10 teclas.

La longitud de ese número debe ser lo más corta posible, y al mismo tiempo abarcar todo el espacio de la entidad que espera catalogar con espacio de sobra. Esto puede ser complicado y debe pensarse un poco. Una pequeña teoría de conjuntos puede darle la cantidad de claves únicas a las que tendrá acceso, dado un grupo de elementos.

Al hablar, es natural dividir los números en conjuntos de dos a cuatro dígitos. Al insertar guiones en algún patrón, puede "forzar" al cliente a repetirlos de una manera más eficiente y sin ambigüedades.

Por ejemplo, 323-23-5344, que, por supuesto, es el formato del número de la seguridad social, ayuda a informar al orador dónde pausar al vocalizar el número. También proporciona una delineación visual al escribir el número y facilita la comparación al copiar el número.

En segundo lugar, recomiendo que el sistema de ordenamiento enmascare la entrada correctamente para que no se introduzcan guiones en ningún momento. Esto debe llevarse a cabo en formularios impresos para proporcionar una expectativa clara de lo que debe ingresarse. Por ejemplo, un cuadro impreso para cada dígito separado por guiones impresos.

No estoy de acuerdo con que se incluya demasiada información en este número, especialmente si esos atributos pueden cambiar. Por ejemplo, digamos que le damos a "323" el significado de "es un buen cliente", pero luego llaman cuatro veces con una actitud. ¿Vamos a cambiar su clave de cliente a "324", "es un idiota"? ¿Qué pasa si están en la región 04 y trasladan su compañía a la región 05?

Si eso sucede, sus opciones serán actualizar esa clave principal en toda la base de datos o vivir con la ambigüedad de que la información incorporada en esa clave ya no es confiable, y por lo tanto, toda la información incrustada en las claves de utilidad cuestionable.

Es mejor almacenar los atributos que pueden cambiar como campos separados en la base de datos y hacer que el número de cliente sea una clave única e inalterable para ese cliente.

Usaría números solo porque es una empresa internacional. Usaría espacios o guiones cada 4-6 números para separarlo. También mantendría el formato separado para una identificación rápida

Ejemplo:

000-00000-00000 - podría ser un número de cliente

00000-00000-00000-00000 - podría ser un número de pedido

Utilizaría un sistema completamente numérico para el Número de pedido y el Número de cliente, esto le permitirá evitar problemas con otros idiomas.

Evite los ceros a la izquierda, ya que esto puede causar problemas con la entrada y validación de datos.

La cantidad de dígitos para cada uno dependerá de su volumen esperado. Siempre tendrá una mayor cantidad de números de orden que números de cliente. Un número de cliente de seis dígitos que comienza en 100000 todavía le dará 899,999 clientes. Agregue 3-4 dígitos adicionales para el número de orden, le dará 999 a 9.999 pedidos por cliente (más si considera clientes únicos).

No es necesario crear ningún tipo de identificación en su secuencia de numeración. Tiene otros campos de base de datos para identificar de dónde es un cliente, etc. No complique demasiado su sistema.

KISS (mantenerlo simple )

Ve con todos los números o todas las letras. Si debe mezclarlo, asegúrese de que no haya caracteres ambiguos (Il1m, O0, etc.).

Cuando se muestran / imprimen, ponga espacios en cada 3-4 caracteres pero asegúrese de que sus sistemas puedan manejar las entradas sin los espacios.

Editar: Otra cosa a tener en cuenta es tener una forma integrada de distinguir pedidos, clientes, etc. Por ejemplo, los clientes siempre comienzan con 10, los pedidos siempre comienzan con 20, los vendedores siempre comienzan con 30, etc.

suponiendo que la creación de pedidos / clientes no está centralizada, o no siempre estará centralizada, use un GUID

si la creación de pedidos / clientes siempre estará centralizada, un entero sin signo estaría bien

No hay una razón convincente para que el número de pedido del número de cliente "signifique" nada, y es probable que cualquier esquema de número segmentado inventado deba revisarse más adelante. Aténgase a algo único y sin sentido.

EDITAR: para MOTO, cualquier identificador alfabético de múltiples caracteres causará problemas por teléfono, por lo que los GUID son correctos. Asumiendo múltiples ubicaciones MOTO descentralizadas, asigne a cada ubicación MOTO un prefijo (A, B, C, etc., o 01, 02, ...) y use un número entero o entero grande para el cliente y los ID de pedido, por ej. 01-1 es el primer pedido desde la ubicación MOTO # 1. Tenga en cuenta que el relleno cero es innecesario, impone un límite de dígito implícito a los números y requiere que el cliente distinga entre seis ceros y siete ceros al pronunciar el número. Si debe usar un formato acolchado de longitud fija, divida el número en grupos de no más de 4 o 5 dígitos cada uno.

ADDENDUM: el número de pedido y el número de cliente no tienen que ser las claves principales de sus tablas respectivas, solo columnas indexadas únicas para la búsqueda. Probablemente desee utilizar algo más simple / más eficiente para las claves principales en la base de datos.

Nunca usaría información de usuario en ID. Supongamos que utiliza las primeras letras del apellido del cliente seguidas de un número: por ejemplo, Thomsom podría ser el cliente THOM-0001. Solo que parece que cometiste un error, y el nombre del hombre es Tomson en lugar de Thomson. Los datos del usuario pueden corregirse, los ID nunca deben ser modificables. Así que la próxima vez que busques a Tomson en TOMS ... no podrás encontrarlo. Lo mismo con otros datos, como un tipo de cliente. Siempre puede cambiar, la identificación no puede.
Esto es muy básico para RDBMS.

Simplemente usa números de conteo. Para facilitar la lectura, es una buena idea insertar separadores de modo que nunca tenga más de 4 dígitos sucesivos: 9999-9999 es mejor que 999-99999. Y no hagas que el número sea más largo de lo necesario; las personas están mucho más molestas al ser reducidas a un número de 20 dígitos que simplemente reducirse a un número.

Hay una trampa, sin embargo. Especialmente si tiene una pequeña empresa, los contadores simples pueden regalar más de lo que usted apreciaría. Digamos que ordeno algo de usted, y el número de orden es 090145. El mes que viene ordeno nuevamente, y el número de orden es 090171. Er .. ¿26 pedidos en un mes? Lo mismo, no me sentiría cómodo para convertirme en cliente 0006 en un negocio que ha estado activo durante 10 años.
La solución es simple: omita los números. No use números aleatorios, porque aún desea que estén en secuencia.

¡NO codifique CUALQUIER información mutable de cliente / orden en los números! ¡Y debes asumir que todo es mutable!

Algunas de las sugerencias anteriores incluyen un código de región. Las empresas pueden moverse. Su propia empresa podría reorganizar y cambiar su propia definición de regiones. Los nombres del cliente / compañía también pueden cambiar.

La información del cliente / orden pertenece al registro de cliente / pedido. No en la ID. Puede modificar el registro de cliente / pedido más tarde. Los ID generalmente están escritos en piedra.

Incluso la simple codificación de la fecha en la que se generó el número en la ID puede parecer segura, pero eso supone que la fecha nunca es incorrecta en los sistemas que generan los números. Nuevamente, esto pertenece al registro. De lo contrario, nunca se puede corregir.

¿Más de un sistema generará estos números? Si es así, tiene la posibilidad de duplicación si usa solo números basados en fechas y / o secuenciales.

Sin saber mucho sobre la compañía, comenzaría por este camino:

Un código de un carácter que identifica el tipo de número. C para clientes, R para pedidos (no use "O" ya que podría confundirse con cero), etc.
Un identificador del sistema que generó el número. La longitud de este identificador depende de cuántos de estos sistemas habrá.
Un número de secuencia, exclusivo del sistema que lo genera. Solo un contador.
Un número aleatorio para evitar números de orden / cliente adivinados. Haga esto mientras su paranoia lo requiera.
Una suma de comprobación simple. No por seguridad, sino por comprobación de errores.

Romper esto en segmentos lo hace más legible como otros han señalado.

CX5-0000758-82314-12 es un número posible generado por este enfoque. Esto consiste en:

C: es un número de cliente.
X5: la estación que generó el número.
0000758: este es el número 758º generado por X5. Podemos generar 10 millones antes de retirar esta identificación de estación o la estación misma. O no rellenes con ceros y no hay límite.
82314: esto se generó aleatoriamente y da como resultado una probabilidad de 1 / 100.000 de adivinar una ID de cliente.
12: suma de comprobación.

Primer paso: en una organización lo suficientemente grande como para requerir un sistema de este tipo, existe un sistema existente que está reemplazando. Continuar el esquema del sistema anterior, si es posible. Facilita mucho las cosas si puede acceder, incluso a un nivel básico, a los datos del sistema antiguo.

Dicho esto, a menudo hay una buena razón para cambiar el esquema, particularmente cuando proviene de un sistema heredado. sin embargo, encuentro que a menudo es útil descartar formalmente el viejo esquema antes de proceder.

Segundo paso: sistemas como este nunca existen en el vacío. ¿Existe ya un esquema para toda la organización de ID de usuario y / o de pedido, como en el sistema de contabilidad, gestión de inventario o CRM? De ser así, considere adoptar los esquemas existentes para facilitar la interoperabilidad. Muchas organizaciones grandes tienen múltiples formas de especificar un único cliente u orden, y eso hace que obtener inteligencia útil de los datos sea mucho más difícil.

Tercer paso: si el esquema del viejo sistema es demasiado malo para continuar y no hay otro esquema que adoptar, haga el suyo. En este caso, observe las deficiencias del esquema original, sean lo que sean, y corríjalo. La respuesta correcta dependerá de los requisitos específicos de la aplicación. El enunciado del problema que nos ha dado es demasiado vago para especular de forma útil sobre cómo se vería la forma final.

Haga el número el tiempo que sea necesario, pero no más. Cada vez que pago mi factura de agua, debo ingresar mi número de cliente de 20 dígitos y un número de factura de 18 dígitos. Afortunadamente, un guion en mi número de cliente lo separa en dos partes.
No dependas de los ceros a la izquierda. Tener que averiguar cuántos ceros hay en mi número de factura es extremadamente molesto. Tome 000000000051415432 por ejemplo. Su sistema no reconocerá solo 51415432.
Dígitos de grupo juntos . Si tiene que usar números largos, los trozos de cuatro dígitos deberían funcionar bien.