Operadores Alternativos / Preferencias de impresión según preferencias del Cliente / Usuario system [v2.11]

Descripción

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

Back ZipCodes: Añadir Operador alternativo y leadtimes internos

Descripción

Untitled

Para esta funcionalidad lo que se hizo fue añadir los siguientes campos a la entidad Código Postal (ZipCode), los cuales tienen como características en común que no son requeridos ni tienen incidencia en los flujos (cotización, estadísticas de clientes,..), solo están pensandos para su “almacenamiento”:

Días de demora Operador: representa el tiempo de demora (leadtime) de uso “interno”. Se puso como restricción (mínima) que no puede ser mayor al Dias de Demora Hasta.
Operador Alternativo: Selector libre para elegir algún Operador.
Días de demora de Operador Alternativo: Días de demora de dicho Operador.

Estos campos fueron añadidos dentro del flujo de los CSV de los ZipCodes, esto implica que pueden ser exportados e importados por esa vía.

Pruebas básicas del flujo

- Asignaciones iniciales, con sus correspondiente visualización en la pantalla de detalles del CP editado. Verificación de validaciones mínimas (sobre campo Dias de demora Operador).

- Exportación a CSV

- Verificación de actualización via Lote de Códigos Postales.

API enpoint OrderCreate: setear print_url según configuración del cliente

Descripción

Para esta tarea lo que se hizo fue adaptar el flujo interno al serializarse la respuesta ante una creación exitosa de una Orden, para que cuando se acceda a la URL publica devuelta en el campo «print_url»:

Si el cliente usa ZPL → Se retorna un PDF renderizado con la configuración global/default.

- Si el cliente usa PDF → Se retorna el PDF renderizado con su configuración.

Pruebas básicas del flujo

- Crear una serie de órdenes, alterando la configuración del Cliente para observar el comportamiento descrito.

Back: Añadir configuraciones al Cliente

Descripción

Untitled

Se añadieron 2 campos nuevos en la entidad de Cliente, los cuales son nuevas entidades simples, esto significa que poseen un pequeño ABM

Tipo de Integración (Requerido): Se precargaron los valores iniciales que fueron indicados en el PM original. Este mantiene una relación N a N, con lo cual es posible indicar 1 o más tipos de integración.
Ejecutivo de Cuentas (Requerido): más allá de su asignación, se ha exportado su valor dentro de los detalles del CSV de la pantalla «Envios Facturación».

Pruebas básicas del flujo

ABM de ambas entidades
Asignaciones a Clientes
Verificación de exportación en CSV de Envios Facturación.

Front Client: Corregir el seguimiento ante Devolucion

Descripción

Siguiendo el requerimiento original, se implementó adaptaciones en el front de cliente, para que cuando un envio se encuentre en alguno de estos estados:

- Devolución

- En proceso de devolución

- Devolución a Central

- Devolución Registrada

Se renderice la leyenda «En devolución» junto con los “tres nodos” completos, indicando “fin” del recorrido.

Pruebas básicas del flujo

- Crear diversos envios, verificando esta adaptación ante esos 4 estados indicados.

Registración de Clientes

Descripción

Para satisfacer los requerimientos de esta tarea se han implementado, a grandes rasgos, las siguientes funcionalidades:

- Endpoints para la registración y actualización de los datos del Cliente

- Adaptaciones en el flujo de autenticación (JWT) ante la adición de una nueva «Password de Integración».

- Links parametrizables en el front de Clientes.

- Usuario System con posibilidad de acceder a enpoints de API Client

Endpoints

Se generaron 2 endpoints solo disponibles para el usuario System:

Registración: POST /api/v1/sys/client/

Actualización: PUT /api/v1/sys/client/

Ambos endpoints comparten prácticamente los mismos parámetros, que se detallan a continuación, lo que difiere principalmente es que en la registración, se hace uso del seteo de valores por default:


Campo	Observaciones	Valor Default	Registración	Actualización
username	Se valida unicidad.	(no aplica)	requerido	opcional
password		(no aplica)	requerido	opcional
password_integration	Campo nuevo: usada en integración	(no aplica)	requerido	opcional
nombre		(no aplica)	requerido	opcional
apellido		(no aplica)	opcional	opcional
cuit_cliente		(no aplica)	requerido	opcional
company_name	Campo nuevo: Razón Social	(no aplica)	opcional	opcional
email	Se valida unicidad a nivel Cliente	(no aplica)	requerido	opcional
mode		Puerta a Puerta	opcional	opcional
destination		Pablo Nogués	opcional	opcional
package_pickup_cost		(no aplica)	opcional	opcional
order_pickup_cost		(no aplica)	opcional	opcional
insurance_ratio		0,008	opcional	opcional
discount_ratio		(no aplica)	opcional	opcional
delivery_days		10	opcional	opcional
collection_days		1	opcional	opcional
orders_limit		(no aplica)	opcional	opcional
product_code		valor del parámetro client_default_values.vkm_product_code	opcional	opcional
urbano_shipper		valor del parámetro urbano.shipper	opcional	opcional
urbano_password		valor del parámetro urbano.password	opcional	opcional
can_send_shipment_id		(no aplica)	opcional	opcional
prefix		Generación automática	opcional	opcional
duplicity_control		false	opcional	opcional
prepaid	prepago	true	opcional	opcional
tax	Impuestos (IVA)	true	opcional	opcional
shipment_description		(no aplica)	opcional	opcional
sender_address_street_name		(no aplica)	requerido	(no aplica)
sender_address_street_number		(no aplica)	requerido	(no aplica)
sender_address_zip_code		(no aplica)	requerido	(no aplica)
sender_address_neighborhood_name		(no aplica)	requerido	(no aplica)
sender_address_city		(no aplica)	requerido	(no aplica)
sender_address_floor		(no aplica)	opcional	(no aplica)
sender_address_apartment		(no aplica)	opcional	(no aplica)
sender_address_other_info		(no aplica)	opcional	(no aplica)
sender_address_state	Nombre de la provincia	(no aplica)	requerido, solo si no se envia sender_address_state_id	(no aplica)
sender_address_state_id	Id de la provincia. Posee ponderación ante la presencia del anterior	(no aplica)	opcional	(no aplica)
sender_address_active		(no aplica)	opcional	(no aplica)
sender_address_alias		Valor del username	opcional	(no aplica)
active		false	(no aplica)	opcional

En el caso del campo «prefix», se ha definido un pequeño algoritmo que garantice la definición de 3 caracteres alfabéticos aleatorios, y que ante la duplicidad de este campo, se intente generar uno nuevo, tantas veces como sea necesario para su persistencia.

Vale aclarar que más allá de los campos, a la instancia del Cliente recientemente creada se le asignan los siguientes valores por defecto, siguiendo el comportamiento del backoffice:

Notificación de estados por Email: Comprador y Vendedor.
Cuit: El valor del parámetro client_default_values.vkm_operation_cuit.
Configuración de impresión: La default
Tipo de Integración: No integrado
Habilitación para Operadores: Ninguno
Límite de No Entregado: 5

Ejemplos en Curl

Registración:

curl --location --request POST 'iflow.local/app_dev.php/api/v1/sys/client/' \
--header 'Content-Type: application/json' \
--data-raw '{
  "username":"cliente_test",
  "password":"123456",
  "password_integration": "abcdef",
  "nombre":"Testing #01",
  "apellido": "QA",
  "cuit_cliente": "24123456789",
  "company_name": "Mi Razon Social",
  "email":"cliente_test_api01@test.com",
  "sender_address_street_name":"9 de Julio",
  "sender_address_street_number":"1200",
  "sender_address_zip_code":"7602",
  "sender_address_neighborhood_name":"El Mondongo",
  "sender_address_city":"Mar del Plata",
  "sender_address_floor":"3",
  "sender_address_apartment":"C",
  "sender_address_state":"Buenos Aires",
  "sender_address_state_id":1,
  "sender_address_other_info":"Some place",
  "sender_address_active": true,
  "sender_address_alias": "",
  "package_pickup_cost":100,
  "order_pickup_cost":120,
  "insurance_ratio":0.42,
  "discount_ratio":0.52,
  "tax": true,
  "delivery_days":5,
  "collection_days": 1,
  "orders_limit":5,
  "urbano_shipper":"UR29292",
  "urbano_password":"uP4ss",
  "product_code":"PC3939",
  "can_send_shipment_id":true,
  "prefix":"QAC",
  "shipment_description": "",
  "duplicity_control": true,
  "prepaid": true
}'

Actualización:

curl --location --request PUT 'iflow.local/app_dev.php/api/v1/sys/client/238' \
--header 'Content-Type: application/json' \
--data-raw '{
   "active": true
}'

Flujo de autenticación

Debido a que se ha añadido un nuevo campo llamado «password_integration» (Contraseña de Integración), se ha tenido que adaptar el complejo flujo de autenticación JWT, el cual es manejado por Bundles de Symfony.

Con esta adaptación ahora se permite el inicio de sesión con la contraseña original y la de integración.

Links parametrizables en Front de Clientes

Untitled

Se hicieron pequeñas modificaciones al Front de Cliente para mostrar 2 enlaces hacia urls parametrizadas vía src/config.js:

- Registración: Se añadió en el menú principal esta opción, y se renderiza con el parámetro url_register

Recuperación de contraseña: dentro de la caja de inicio de sesión, se añadió la leyenda «¿Has olvidado la contraseña?» la cual apunta a la url indicada en el parámetro url_passowrd_recovery.

Pruebas básicas del flujo

- Creación de Clientes:

- Verificando Unicidad de email y username

- Correcta inicialización de campos con valores default ante un request con cuerpo “mínimo”.

- Chequeo de usuario inactivo

- Pruebas de creación de múltiples clientes para verificar la creación correcta de prefijos.

- Actualización de Clientes:

- Activación

- Modificación de otros campos permitidos.

- Inicio de sesión con password común y de integración.

- Front Client navegación correcta hacia los links indicados. Al Loguearse como usuario la opción de «Registrase» no debería estar disponible (similar a lo que ocurre con Login).

- Acceso como usuario System a algunos endpoints simples de Cliente (zip_code,etc..)