Los escenarios de dirección transfronteriza se caracterizan por algo que no aparece en un pedido doméstico: en el mismo registro conviven varios territorios con funciones distintas. El país de facturación puede no ser el de entrega, y ninguno de los dos tiene por qué coincidir con el domicilio de la persona. Esta guía repasa cuántos territorios entran en juego, cómo se decide cuál manda al validar, qué campos se desalinean con más frecuencia y cómo separar dos mensajes de error que los usuarios confunden constantemente.
¿Cuántos territorios distintos caben en un mismo pedido?
Más de los que parece. Cada uno cumple una función y puede tener un valor diferente.
- El territorio de facturación, que determina el documento y las obligaciones asociadas al pago.
- El territorio de entrega, que determina la dirección física y las condiciones del envío.
- El territorio de registro de la cuenta, que puede ser donde se abrió el perfil y no donde se opera hoy.
- El territorio del documento de identidad, que puede no coincidir con ninguno de los anteriores.
Un formulario que asume que los cuatro coinciden funciona bien en el caso frecuente y produce datos incoherentes en cuanto uno de ellos se separa. Y no hace falta un caso exótico: basta con una persona que trabaja fuera de su país de origen.
Lo útil es decidir de antemano cuáles de estos territorios se guardan por separado y cuáles se derivan, porque cada uno que se guarda por separado multiplica los casos que hay que probar.
Cuando el territorio de facturación y el de entrega no coinciden
Lo primero es fijar qué campos se rigen por cada uno, y esa decisión debe salir de las reglas del negocio y no de la comodidad de la implementación.
Como criterio general, la dirección de entrega se valida con las convenciones del territorio de entrega, porque es ahí donde alguien va a leerla y a entregarla. Los datos asociados al pago y a la documentación se rigen por el territorio de facturación, porque es el que sostiene la obligación.
El error común es aplicar un único conjunto de reglas al registro completo y elegir el territorio por comodidad: se valida todo con el territorio de facturación porque es el primero que se rellenó. El resultado es una dirección de entrega rechazada por reglas que no le corresponden.
Cada campo debería declarar de qué territorio depende. Si esa dependencia no está escrita, se acaba duplicando la lógica en cada punto de la aplicación y las versiones divergen.
Los datos que se desalinean con más frecuencia
Hay cuatro datos que casi siempre acompañan a la dirección y que no tienen por qué seguirla.
| Dato | Por qué se desalinea | Qué conviene hacer |
|---|---|---|
| Teléfono | El número puede ser del territorio donde vive la persona y no del de entrega | Guardarlo como dato propio y no derivarlo |
| Moneda | Se decide por el contrato o el método de pago, no por la dirección | Fijarla explícitamente en la operación |
| Zona horaria | Depende de dónde está la persona, no de dónde va el paquete | Usarla para presentar, no para validar |
| Idioma de contacto | Es una preferencia de lectura | Mantenerlo aparte del territorio del dato |
Estos cuatro son el origen de la mayoría de las incoherencias que aparecen en las pruebas, precisamente porque el caso doméstico los hace coincidir por casualidad. Si se derivan del territorio de entrega, el día que se separen el sistema mostrará un teléfono que nadie contesta y una moneda que no corresponde al cobro.
Qué zonas se rompen con valores largos
Los escenarios transfronterizos tienden a reunir los valores más largos al mismo tiempo: una dirección de otro alfabeto, un nombre de territorio extenso y una línea de calle que no cabe.
Eso afecta a la composición visual antes que a la lógica. Las plantillas de etiqueta con ancho fijo recortan el final de la línea, que es donde suele ir el dato que distingue una dirección de otra parecida. Las tablas de resumen se desbordan porque la columna se dimensionó con los valores del territorio propio. Y los comprobantes imprimibles heredan el mismo ancho que la pantalla.
La forma de probarlo es tomar el caso con los valores más largos de cada territorio y componer la etiqueta con ellos, no con el ejemplo corto que aparece en la documentación.
¿Cómo se separa «no se entrega aquí» de «el dato está mal»?
Con dos mensajes distintos, porque son dos problemas distintos.
«No se entrega aquí» es una limitación de la operación. El dato puede estar perfectamente escrito y aun así no haber servicio. Un mensaje de error de formato en ese caso envía a la persona a corregir una dirección que no tiene nada que corregir, y el bucle se repite hasta que abandona.
«El dato está mal» es un problema de forma. El territorio sí se atiende, pero la dirección no permite completar la entrega tal como está escrita.
Cuando los dos casos comparten mensaje, no se puede medir cuántos abandonos vienen de la cobertura y cuántos de la calidad del dato. Separarlos mejora el producto y el diagnóstico al mismo tiempo.
Notas para quien programa
- Declara de qué territorio depende cada campo y hazlo en un solo sitio consultable.
- Evita los valores por defecto silenciosos: copiar el territorio de facturación al de entrega oculta el caso en que difieren.
- Guarda por separado teléfono, moneda, zona horaria e idioma de contacto, y no los derives de la dirección.
- Usa dos códigos de error distintos para el territorio no atendido y para el dato mal formado.
- Comprueba los requisitos adicionales que solo aplican cuando los territorios difieren, y no los pidas en el caso doméstico.
- Prueba con la combinación más larga que puedas construir, no con el ejemplo corto del manual.
- Deja la decisión de qué territorio manda escrita y fechada, porque cambia con las reglas del negocio.
Siguientes pasos
Toma un pedido reciente y anota cuántos territorios distintos aparecen en sus campos; el número suele sorprender. Si el problema es que los mensajes de error se confunden, empieza por separar el de cobertura del de formato. Para ver qué territorios tienen página propia y comprobar sus datos antes de preparar los casos, el directorio de países y regiones los agrupa por región con enlace al detalle de cada uno. Y si necesitas montar la matriz de pruebas con combinaciones incoherentes, la guía sobre país e idioma en los datos de prueba explica cómo cruzar los ejes sin emparejarlos. Y para los territorios que comparten código o no tienen uno propio, la guía sobre territorios pequeños y códigos especiales cubre esos bordes.
Los territorios, direcciones y campos de pedido que se usan como ejemplo están construidos para ilustrar el planteamiento. No proceden de ninguna operación real ni contienen información de transacciones existentes.