Skip to content
OMS Documentation

Tiempo de demora / Actualización de Clientes / Eventos de usuario y otros adaptaciones [2.14]

Se describe algunas de las novedades de la versión 2.14.  El mismo presenta las características principales de las funcionalidades y las pruebas mínimas de rigor de funcionalidad y/o consideraciones para las mismas.

Correcciones en Flujo de Históricos

Descripción

Se corrigió el flujo de históricos, puntualmente la migración y/o eliminación de las siguientes entidades:

  • Registros de Trabajo (Worklog): Migración y eliminación.
  • Ejecutivo de Cuenta: sólo migración.
  • Tipo de Integración: sólo migración.

Pruebas básicas del flujo

Se pueden hacer por separado o bien armar 1 solo caso, y evaluar todo junto:

  • Crear un envío, y posteriormente asociarle Worklogs (vía API o Front de CustomerCare) y verificar su migración y eliminación (local), vía BD
  • Crear un nuevo ejecutivo de cuenta, y verificar que se haya migrado, via Backoffice
  • Idem al anterior pero con un Tipo de Integración.

Cliente: Añadir campo Teléfono

Descripción

Untitled Se añadió el nuevo campo a la Entidad Cliente, y se lo ubicó en Perfil > Datos Personales, tal como fue requerido. Este campo mantiene el caracter de opcional.

A su vez se hizo disponible dicho campo, denominado phone, en la API de registración de Clientes, definiéndolo como opcional.

Pruebas básicas del flujo

-        Probar las asignación via Backoffice.

En cuanto a la API, se hicieron las adaptaciones a las pruebas automatizadas de Karate, por lo tanto bastará correr las pruebas normalmente

Usuarios: Crear endpoint de actualización

Descripción

Para dar soporte a este requerimiento se definieron varios endpoints nuevos, los cuales emulan el comportamiento del ABM de usuarios del back.

Dichos endpoints  fueron documentados en el repositorio, en el branch release/v2.14, y  posteriormente fueron pasados a master, tras finalizar la etapa de pruebas.

EntidadAcciónEndpointDescripción
PermisosListarGET {{url}}/api/v1/sys/role_groupLista los permisos disponibles en el Sistema.
UsuarioActualizarPUT {{url}}/api/v1/sys/user/:id Actualiza el los datos del Usuario, incluyendo los permisos.
Obtener DetallesGET {{url}}/api/v1/sys/user/:id Se representan una versión mínima de los datos del usuario
Obtener PermisosGET {{url}}/api/v1/sys/user/:id /roles_groupsLista los permisos asociados al usuario.
Obtener RolesGET {{url}}/api/v1/sys/user/:id /rolesLista los roles asociados al usuario.

Pruebas básicas del flujo

  • Actualización de campos de un usuario, incluyendo la relación con Permisos (0..N).
  • Verificación que los métodos “GET” devuelvan la información correspondiente.

Ordenes: Añadir Operador + Tiempos de demora

A la entidad Orden, se le añadieron los siguientes campos:

  • Operador

    • id  (Relación a la  entidad)
    • Días de Demora
    • Días de Demora Desde
    • Días de Demora Hasta

  • Operador Alternativo:

    • id ( Relación a la  entidad)
    • Días de Demora

Untitled Estos campos son seteados ante la creación de una orden, indistintamente de su canal, y dicha información es tomada a partir del Código Postal del Comprador (Receiver). Estos campos pueden ser visualizados desde la página de detalles de la misma.

                  A su vez se consideró, la posible modificación del C.P. en el flujo de modificación de Ordenes (Incidencias), por lo tanto ante cambios en dicho valor, se actualizará la información.

Pruebas básicas del flujo

-        Creación de varias Ordenes, que involucren varios distintos CP (del Comprador) y visualizar en el back la información.

-        Modificar el CP de una orden y evaluar que haya cambiado la información (visualizando el back).

Cola de Usuarios

Descripción

Se creó una cola de mensajes, junto con sus retry y “dead letter” (dl),  para que sea consumida externamente. Se la nombrado como*** if_user_management_event***, y esta contendrá la serialización de los distintos tipos de usuario (Usuario, Operador, PickUp Point,..) ante altas, bajas (solo los casos que corresponde) o modificaciones.

                  La serialización (JSON) depende de cada tipo de Usuario, pero aún así, comparten todas una en común:

  • operation: Indica la operación realizada sobre la entidad (“update”|“create”|“delete”),
  • endpoint: Da cuenta cual fue el contexto donde se llevo a cabo la acción (“backend”|“api_v1_sys_client”|“api_v1_sys_user”,”command”…),
  • id: Identificador,
  • type: Tipo de usuario,
  • username: Usuario,
  • nombre: Nombre del usuario,
  • apellido: Apellido,
  • email: Correo electrónico,
  • passwordHash: contraseña hasheada
  • salt: semilla utilizada para el hasheo de la contraseña
  • roles: array de nombres de permisos.
  • active: Indica si se encuentra activo

Se adjunta un ejemplo de Cliente

{ "operation": "create", "endpoint": "command", "id": 5, "type": "Client", "username": "cliente_test", "apellido": "test", "nombre": "cliente", "email": "devel@softlight.com.ar", "passwordHash": "nwerwerwerwerwerwerwerwerwerwerwerwerwerwerwew==", "salt": "3709b6b7ft45t4t45t45t45t477", "roles": [ "ROLE_CUSTOMER", "ROLE_API_CLIENT", "ROLE_API_CLIENT_CANCEL_ORDER", "ROLE_API_CLIENT_CANCEL_SHIPPING", "ROLE_API_CLIENT_MERCHANT_ORDER_ADD", "ROLE_API_CLIENT_SHIPPING_RETURN", "ROLE_API_CLIENT_SHIPPING_BATCH_PRINTING", "ROLE_API" ], "active": true, "cuit_cliente": "30123456789", "company_name": null, "phone": "", "sender_address_street_name": "Lapacho", "sender_address_street_number": "123", "sender_address_zip_code": "1669", "sender_address_neighborhood_name": "Su", "sender_address_city": "Mar del Tuyu", "sender_address_floor": "1", "sender_address_apartment": "none", "sender_address_state_id": 1, "sender_address_state": "BUENOS AIRES", "sender_address_other_info": "Azul y oro", "sender_address_active": true, "sender_address_alias": null, "package_pickup_cost": 27, "order_pickup_cost": 0, "insurance_ratio": 0.008, "discount_ratio": 0, "tax": 1, "mode": 3, "destination": 3, "delivery_days": 10, "collection_days": 1, "orders_limit": 0, "urbano_shipper": null, "urbano_password": null, "product_code": "ARTICULOSCOPAZZO", "can_send_shipment_id": false, "shipment_description": null, "duplicity_control": false, "prefix": "CLT", "prepaid": true}

Pruebas básicas del flujo

-        Realizar creación de los distintos usuarios, via API (Clientes y Usuarios) y Back

-        Actualizar los datos de los usuarios via API (Clientes y Usuarios) y Back

Notificación de cambios de estado: Cambios en template

Descripción

Se separaron en 2 plantillas/templates independientes de email, las que tienen como destinatarios al Vendedor y al Comprador, y se hicieron las adaptaciones requeridas, exclusivas para este ultimo:

-        Nuevo logo ubicado en la parte superior.

-        Cambios menores en leyendas, incluido el link a tiquetera WebTicket. Untitled

Pruebas básicas del flujo

-        Visualizar correctamente el email, tanto para Comprador como Vendedor. El mail recibido por el Vendedor, debería verse sin las modificaciones realizadas (osea en su versión original).

Cambios en Etiquetas: Adición de Carrier e info de Integración con OCA

Descripción

Se hicieron las 2 grandes adaptaciones:

  1. Se añadió el nombre de agencia asociada al Carrier. Este se determina a partir del C.P. de la dirección del Comprador, y es mostrado en la parte superior derecha, tal como fue requerido.

  2. Ante una etiqueta que integra con OCA, se hicieron las adaptaciones en el flujo y visualización de los datos. Se añadieron los 4 campos requeridos:

    1. Origen: texto fijo
    2. Destino: obtenido del API de OCA
    3. Operación: idem al anterior
    4. QR: se definió un directorio en el filesystem, donde se almacenarán los códigos QR renderizados, utilizados en las etiquetas.

Las adaptaciones se hicieron considerando los formatos A4, A6 y el formato Imagen, utilizado en el flujo de Impresión ZPL. Untitled

Pruebas básicas del flujo

  • Probar los formatos A4 y A6, utilizando el front de Client.
  • Acceder via API al formato en Imagen de un envio, utilizando el hash (leído via BD).
    Nota: esto está documentado en la API Pública.