Service de WMS / Clasificación de Ordenes / Modulo de Turnos de Entrega [v2.15]

Sustitución de VKM (Service WMS)

Descripción

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

Se implementó un flujo inicial de la futura sustitución de la actual comunicación que el sistema realiza con VKM. En dicha implementación se abordó la posibilidad de comunicar a un nuevo servicio WMS (*ServiceWMS) *los siguientes escenarios:

• Ordenes creadas mediante el canal iFlow (API / Lotes de Ordenes)
• Ordenes canceladas.
• Envios Devueltos.

Los escenarios, comparten una misma serialización JSON en común, desde la perspectiva de la Orden, y solo se diferencian algunos detalles particulares, como son el caso de las “tipificaciones” (type, event_type) o bien en el caso puntual de los envios devueltos, en donde solo se incluye a ese (y no al resto).

Se adjunta un ejemplo del serializado:

{
  "id": 2965975,
  "channel": "iflow",
  "delivery_mode": {
    "id": 1,
    "name": "Puerta a Puerta"
  },
  "mode": {
    "id": 3,
    "name": "Puerta a Puerta",
    "description": "Paquetes que van de Origen a Destino."
  },
  "type": "normal", // Clasificacion de orden [normal|pup|reverse|return|cancel]
  "event_type": "order_created", // El evento disparador de la notificacion [order_created|order_canceled|shipping_return|unknown]
  "created": "03/11/2021 14:47:30",
  "order_id": "3127",
  "tracking_id": "OR0002965975",
  "receiver": {
    "id": 2965970,
    "user_id": null,
    "nickname": null,
    "first_name": "Gonzalo",
    "last_name": "QA",
    "receiver_name": "Gon",
    "receiver_phone": "111-2233",
    "email": "devel@softlight.com.ar",
    "company": null,
    "agency": null,
    "address_street_name": "La Matoneta",
    "address_street_number": "321",
    "address_other_info": "La Matata",
    "address_neighborhood_name": "El Scaloneta",
    "address_zip_code": "1661",
    "address_city": "Mar del plata",
    "address_state": "BUENOS AIRES",
    "address_floor": "6",
    "address_apartment": "B",
    "address_between_1": "1",
    "address_between_2": "2",
    "address_latitude": "-34.93139800",
    "address_longitude": "-57.94890000"
  },
  "sender": {
    "id": 4335,
    "user_id": "T5d5ede02caa87",
    "nickname": "testing",
    "first_name": "Testing",
    "last_name": "QA",
    "email": "cliente_test@softlight.com.ar",
    "corporate_name": null
  },
  "sender_address": {
    "id": 37510,
    "street_name": "La Matoneta",
    "street_number": "123",
    "floor": "6",
    "apartment": "B",
    "other_info": null,
    "neighborhood_name": "Matata",
    "zip_code": "1661",
    "city": "La Plata",
    "state": null
  },
  "pickup_point": null,
  "shippings": [
    {
      "id": 2968680,
      "shipment_id": "UQA0000000074654",
      "tracking_id": "OR0002965975",
      "state": "Registrado",
      "items": [
        {
          "id": 3029359,
          "item": "DISCO EXTERNO 1TB",
          "sku": "6",
          "quantity": 1,
          "weight": 500,
          "length": 20,
          "height": 20,
          "width": 20,
          "value": "5000.00"
        }
      ],
      "created_date": "03/11/2021",
      "items_value": "100.00",
      "shipping_cost": null,
      "pacted_date": null,
      "estimated_delivery_date": "13/11/2021",
      "registered": "03/11/2021 14:47:30",
      "processed": "",
      "planned": "",
      "pickedup": "",
      "notified": "",
      "discharged": "",
      "ready": "",
      "dispatched": "",
      "delivered": "",
      "not_delivered": "",
      "height": 25,
      "width": 20,
      "length": 20,
      "weight": 1000,
      "weight_mode": null,
      "volume": 10000,
      "volumentric_weight": null,
      "items_quantity": 1,
      "shipping_service": null
    }
  ],
  "carrier_external": {
    "id": 1,
    "name": "FL C. External",
    "zone": "AMBA",
    "subzone": "Z0001"
  },
  "delivery_shift": {
    "id": 1,
    "name": "Todo el día",
    "start": "08:00",
    "end": "20:00"
  },
  "distribution": {
    "zone": {
      "id": 46,
      "name": "INT"
    },
    "subzone": {
      "id": 17,
      "name": "SUR O"
    }
  },
  "rate_zone": {
    "id": 4,
    "name": "AMBA"
  },
  "order_classification": {
    "id": 1,
    "name": "Orden Normal",
    "code": "default"
  }
}

Para esta solución en particular, implicó añadir configuración necesaria en el parameters.yml   service_wms:

        # URL base, sin ”/” al final

        api_url: ‘http://qa-gateway.iflow21.com/ms/api’

        api_key: ‘iflApiKey’

Y por otro lado, añadir “enganches”  en el sistema, en lugares donde hoy se hacen para la comunicación de VKM, además de crear una cola y consumer específicos (order_registered) ante Órdenes creadas.

En esta versión inicial** se excluye todo tipo de cambios de estados**, tanto los que  ocurren tras comunicaciones satisfactorias con VKM (p. ej. «Registrado» →  «Procesado»; «Devolución Registrada» -> «En proceso de devolución»,..), como asi también los que se le comunican ante nuevos estados en los envios (StateInfos, …) .

Pruebas básicas del flujo

Puntualmente del Service WMS:

• Probar devoluciones y Cancelaciones, y corroborar si se comunica (via log) con el service.
• Verificación de serializado (según el caso de Orden y/o evento).
• Comunicación con el endpoint configurado via parameters.
• Consumer ante ordenes registradas: app/console swarrot:consume:order _registered if_order_registered -vv

Además se deberan hacer pruebas generarles del sistema dado que se hicieron algunos enganches en services de envios (Indexado,etc…).

ABM y flujos asociados a Clasificación de Órdenes

Descripción

Se añadió la nueva entidad, junto a su ABM, para permitir clasificar la naturaleza de las distintas órdenes que hoy en día se manejan (frio, normal,…). Mas allá de los atributos nombre y código, se debe configurar a una sola instancia como la default. Esto es validado por el sistema, tanto al crear cómo así también al actualizar.

Más allá del ABM, se integró esta nueva entidad a varios  enpoints:

• Creación de órdenes: Se lo definió como un parámetro opcional (order_classification), y en caso de no estar presente en la petición, configurará la instancia que haya sido default del sistema.
• Detalles de órdenes: Se lo añadió en el serializado para ser mostrado desde el Front.
• Listado de Clasificaciones: se hizo este pequeño endpoint para poder implementar un selector.

La documentación de estos endpoints, se realizó vía el repositorio de la API.
Por último se añadió un selector, en el front de Client, para que pueda definir el tipo de orden al crearla.

Pruebas básicas del flujo

• Pruebas básicas del ABM, asegurándose de que solo sea posible definir una instancia default.
• Creación de ordenes indicando tipos de clasificación válidos.
• Acceder a una Orden vieja (back y/o front client) y visualizar que tenga un clasificador de orden default.
• Pruebas del selector desde el front de Client: se deberán visualizar los tipos activos.

Descripción

Para este requerimiento se tuvo que desarrollar nuevas funcionalidad y/o bien impactar en varias existentes, las cuales se detallan a continuación.

ABM

Se ha creado un ABM simple con los atributos principales de esta nueva entidad (nombre, descripción, hora desde / hasta y activo), y adicionalmente se ha definido una Configuración (SystemConfig) llamada «waiting_time», la cual representa el tiempo de espera.

Vale aclarar que actualmente, no se le ha dado un uso a «waiting_time».

Adaptaciones de flujos

Se tuvieron que realizar las adaptaciones pertinentes para pasar de evaluar una constante numérica (1..3) a una relación con la nueva entidad. En entre los flujos adaptados internamente están:

• Creación de órdenes indistintamente del canal y forma (API, Lote de Ordenes,..)
• Modificación de órdenes
• Serializados de endpoints (Client,Customer,..), para retornar el valor original y/o en algunos contextos puntuales devolver un dato mas enriquecido.
• Implementaciones requeridas en el flujo de Órdenes Históricas.

Etiquetas

Se añadió la información del turno a la etiqueta de un envío. Esta figura debajo de «Tipo de envio», y simplemente se muestra el nombre del mismo.

Endpoints (CS y Clients) y Fronts

                  Se implementaron una serie de endpoints para nutrir a los front Client y Customer Service (Customer Care), de un selector de turnos, en los siguientes contextos:

• Crear una nueva Orden: solo en Client
• Modificación de Órdenes: Ambos, en Client se consideró la posibilidad de Modificación por parte del Comprador (Usuario Anónimo / API Publica)

Los Endpoints en cuestión son:

• GET          /api/v1/client/delivery_shift/
• GET          /api/v1/public/delivery_shift/
• GET          /api/v1/cs/delivery_shift/

Su documentación más detallada están incluidas en el repositorio de Documentación de API, en el branch correspondiente a esta versión.

Service WMS

                  Se tuvo que añadir a la serialización la información relativa al turno. Un ejemplo de la misma, es provista en la documentación de este módulo.

Pruebas básicas del flujo

• Creación de ordenes desde el Front, haciendo uso del Selector, verificando que los turnos sean los activos. Al crearse una orden (POst) se deberá verificar que el turno haya quedado asociado a la orden y a su vez ser visible en la etiqueta correspondiente.
• Se puede probar la importación de Lotes de Ordenes, y observar que los turnos provistos coincidan con los que se visualizan.
• Probar que figure en la serialización del Service de WMS.
• Modificación de Ordenes siendo Cliente, Comprador (usuario anónimo) o bien Customer Service.