Skip to content
OMS Documentation

Estados de Orden - Gestión de Prefijos

Se describe las novedades de la versión 2.19. Se presentan las características principales de las funcionalidades y las pruebas mínimas de rigor de funcionalidad y/o consideraciones para las mismas.

Estados en Órdenes - ABM de Estados de Orden

Descripción

Untitled Se definió un ABM para la gestión de los Estados de Órdenes (dentro de Menú Configuración > Estado de Órdenes). Entre los atributos disponibles a gestionar para cada instancia se encuentran:

  • Nombre
  • Descripción Publica (opcional): leyenda / nombre cuya finalidad es mostrársela al usuario final (email,etc…)
  • Activo: para indicar su disponibilidad1.
  • Orden: Sirve para darle un “orden cronológicó” para cuando estos sean visualizados via API (Front de Client p.ej).

Pruebas básicas del flujo

  • Creación / Edición de una entidad
  • Ordenamiento de columnas
  • Detalles de una entidad (datos de auditoría,etc..)
  • Filtrado de entidades

Estados en Ordenes - Gestión de Reglas de Estado de Orden

Descripción

  1. Actualmente solo se utiliza para filtrar los estados de orden disponibles en las Reglas de configuración. Ante el pase de Activo -> Inactivo, se validará que no haya reglas asociadas.

Untitled Se definió un ABM para la gestión de las reglas requeridas para la aplicación de los estados de Ordenes (Menú Configuración > Configuración de Estados, pestaña Reglas de Estado de Orden).

Dentro de los atributos configurables se encuentran:

  • Estado de Orden: Se define 1 estado de Orden a aplicar. Se listan aquellos que estén activos

  • Estados Objetivos: Aquellos estados (de envío) que se desean involucrar para evaluar la aplicación del estado de Orden.

  • Porcentaje: define qué nivel de porcentaje tienen que alcanzar los estados de los envíos, según los objetivos definidos, para que se aplique el estado de Orden.

  • Tiempo de espera (en segundos): Configura el tiempo de espera ante la generación de la notificación (vía correo electrónico) del nuevo estado de Orden aplicado.

  • Notifica por Email: define quienes son los usuarios finales a notificar y** solo es posible establecer un valor si sus estados Objetivos no poseen una configuración al respecto**1. Entre sus valores se encuentran:

    • Comprador
    • Vendedor
    • Ambos
    • Ninguno

En cuanto a la aplicación efectiva de los estados, se definió que se aplicarán si:

  • El porcentaje se lo evalúa como la suma de los porcentajes de los estados objetivos definidos. Por ejemplo ante una orden con 3 envíos que se encuentre en 1 Retirado (33%); 1 Listo para despachar (33%) y 1 en devolución (33%), y ante una regla que defina el 60% en Retirado o Listo para despachar → Se terminará aplicando, dado que los envíos aplican al 66% con dicha condición.
  • Ante dos reglas que puedan ser aplicadas, ante una configuración poco “clara” (p. ej. mismos estados objetivos involucrados) , se aplica la que primera cumpla con el criterio. Esto da pie a que el día de mañana se impidan configuraciones poco claras o bien aplicar “prioridad”. En este punto se deja la asunción de que el usuario hará un uso claro de las reglas, muy similar a los ejemplos provistos en la definición inicial de los requerimientos.

Por último, vale aclarar dos criterios adoptados en las operaciones de gestión:

  • eliminación: es baja lógica
  • edición: se realiza la baja lógica de la regla, y se crea una idéntica con dicha configuración.

Estos dos criterios, están relacionados, dado que ante la aplicación de una regla, se requiere hacer referencia a la regla aplicada. Esto se explicará mejor en la próxima sección.

Pruebas básicas del flujo

  • Creación de reglas diversas, involucrando o no,

    • Mismos Estados de Orden
    • Configuración de email según Estados objetivos

  • Modificación y eliminación, revisando baja lógica de la regla original via BD.

  • Pruebas básicas de ABM (ordenamiento de columnas, show con detalles de auditoria,..)

Estados en Órdenes - Adaptaciones requeridas

Descripción

Se requirió varias adaptaciones en el sistema, dado el nuevo módulo de Órdenes de Estado.

Ordenes

Se añadieron 2 relaciones (posiblemente nulas) con Estados de Orden (OrderState), una desnormalizada (directa) pensada para optimizaciones en la navegación y otra hacia la colección histórica (fecha-desde). Esta última colección, tiene los detalles acerca de que regla fue la que se cumplió (la aplicada) y a su vez resuelve detalles del flujo de notificaciones (que se explicará en la sección correspondiente).

Además se puede visualizar dicha información, el estado actual y la colección, en el listado de órdenes (el actual) y en su detalle (el histórico).

Servicios Principales

Ante la aplicación de estados y/o creación de ordenes, a través de algunos de los canales existentes, se evalúan las reglas de Estados de Ordenes, para ver si aplica o no, alguna de ellas. En caso de que aplique, se actualizará la relación directa que poseen las órdenes con el estado (la relación desnormalizada) y se añadirá todo el detalle en la colección histórica.

A su vez se añadirá parte de esta información, el estado actual, al índice de envíos. Por el momento esta información no es consumida.

Migración de Ordenes

Se tuvo que adaptar el flujo para considerar la migración de los Estados de Orden asociados a una Orden al momento de ser migrada al entorno histórico.

API (parcial)

Inicialmente se implementaron algunas adaptaciones a nivel API

  • API Publica:

    • api_v1_public_order_states (Orden > Obtener detalles del Seguimiento)

  • API Client:

    • api_v1_client_order_list (Orden > Listar)
    • api_v1_client_order_show (Orden > Obtener detalles)

En estos endpoints se añadieron a su serialización, información del Estado de Orden actual.

Front

En el front se añadió la información de los Estados de Orden a nivel del listado y detalles de una orden.

Por otro lado, se enriqueció la información del seguimiento de una orden y/o envío con un widget de Linea de tiempo, que permite visibilizar los cambios de estados, a nivel orden, mas claramente.

Pruebas básicas del flujo

  • Revisar la aplicación de estados, según las reglas existentes, considerando:

    • Creación de Ordenes desde diversos canales (API, Lotes CSV, Urbano,..)
    • Creación y/o actualización de estados de diversos canales (State Infos, Tracking Manual, API…)

  • Pruebas de migración de Ordenes:

    • Sin Estados de Orden
    • Con estados de Orden, ya sean los predefinidos o bien uno nuevo.

  • Verificación de serializado enriquecido con información del Estado de Orden en los endpoints descriptos.

  • Verificación via Front de la publicación de la información: Seguimiento de envío, Listado y detalles de ordenes.

Estados en Órdenes - Flujo de Notificaciones

Descripción

Para cumplir con el requerimiento inicialmente planteado, se ha ideado el siguiente flujo:

1 Se considera configuración un valor distinto a «Ninguno». Untitled Básicamente ante la aplicación de un Estado de Orden, se enriquece en la colección histórica con los siguientes campos:

  • date_to_notify: fecha tentativa de notificación, se usará para determinar en que momento deberá enviarse la notificación.
  • notify_date: fecha “efectiva” en la cual se creó la notificación (se encola para notificar via mail).
  • notify_user: indica la configuración de notificación vía mail a aplicar (Comprador, Vendedor o Ambos).

Una vez persistida esa información, entran en escena, 2 nuevos componentes:

  • OrderStateNotifiacionCommand: el cual es el encargado de seleccionar, ante cada invocación, solo aquellos Estados de Orden a notificar según el campo date_to_notify. Aquellos que lo cumplan, serán encolados en una nueva cola if_order_state_notification .
    Invocación:
    app/console app:order:queue _order_state_history

  • OrderStateNotificationConsumer: a partir de los mensajes encolados, se procesan para dar curso a la notificación efectivamente. Esto es:

    • Renderizado de email
    • Seteo de fecha “efectiva” de notificación.

Invocación:
app/console swarrot:consume:order _state_notification if_order_state_notification

Por último se han definido templates de email, basadas en las actuales de notificación de estados, para ser usadas en este flujo

Pruebas básicas del flujo

  • Recepción de la notificación según los tiempos previstos (tiempo de espera en las reglas).

Administración de Prefijos de Etiqueta

Descripción

La implementación final fue hacer nueva entidad ClientLabelConfig que contenga prefix y label_size (largo total de la etiqueta), además es “auditable” y tiene la identificación del cliente. Descarté agregar el tipo y el can_send_shipment_id, ya que eso no afecta a las colisiones, para poder utilizar como clave de la tabla esos dos campos principales y no tener que repetirlos ante una modificación en una modalidad específica.

Lo que hace es verificar si los valores recibidos de prefix y label_size coinciden con alguno de los que ya posee el usuario, en ese caso lo deja como activo y desactiva el resto. Si no existe lo crea.

Luego valida en la base, si es uno nuevo, revisando que no existan otras configuraciones para el mismo size que se consideren colisiones:

  • primero verifica las cadenas que empiecen como prefix (prefix*), esto garantiza que no haya otro igual o que empiece exactamente igual.
  • Luego va quitando de a una letra y comparando que no exista ese otro patrón más genérico exacto.

Con estos dos criterios cubrimos el espectro de repeticiones.

Esos casos de colisión los junta y luego los muestra en el mensaje de error.

Ejemplo si prefix es ABCD y size = 16:

  1. WHERE label_size = 16 AND prefix LIKE ‘ABCD%’
  2. WHERE label_size = 16 AND prefix LIKE ‘ABC’
  3. WHERE label_size = 16 AND prefix LIKE ‘AB’
  4. WHERE label_size = 16 AND prefix LIKE ‘A’

Si antes de ese existía uno igual o con prefix ‘ABDCEF’, la primera regla lo detecta, ya que el nuevo podría solaparse con ese.

Si existía uno que sea A, AB, o ABC; podría alguno de ellos colisionar generando uno dentro del rango del nuevo.

Consideraciones

Se unificó el circuito control de la generación automática de etiquetas (con o sin prefijo por cliente) con control de etiquetas recibidas (prefijo y longitud).

Aunque se mantuvieron algunos criterios/restricciones actuales en el caso de la generación:

  • Pueden definir o no prefijo.
  • En caso que lo hagan, debe tener 3 dígitos si o si.
  • Tiene un largo default de 16 caracteres, aunque eso ahora permite modificarlo si se agrega un prefijo (sino siempre es 16 y con el prefijo original T00).

En caso de resultar de utilidad, éstos criterios se pueden quitar y permitir automáticas con distinto largo de prefijos (como las manuales).

Aclaración importante

En todos los casos todos los caracteres (ya sean números o letras) son tomados como STRINGS, por eso no hacemos mayores distinciones al respecto. Lo que si es importante es que en las etiquetas, aunque sean numéricos vengan con los dígitos adecuados siempre (porque además eso se controla y si no cumple la longitud total (además del prefijo) lo rebota.

Ejemplo, si el prefijo es 000235 y el largo es 12, no pueden mandar 235000001, sino que deben mandar 000235000001.

Circuitos Afectados Directamente:

  • Alta/Edición de Cliente por el Backend
  • Alta de Cliente por API original
  • Alta de Cliente por API V1
  • Generación de etiqueta automática (con y sin prefijo de cliente)
  • Alta de Ordenes, generación/validación de la etiqueta en conjunto con can_send_shipment_id

Circuitos Afectados Indirectamente:

  • Entidades Carrier/Usuario. El campo prefix existía a nivel usuario porque también le daban otro uso los Carriers, al quitar éste uso de los Clientes, pasó a manos específicas de Carrier. Es un circuito antiguo, que no parece ser usado, pero sufrió esa modificación.