Flujo de Mercado Pago [v2.09]

Se describe las características de la versión v2.09.  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.

Entrega

Flujo de Mercado Pago: Acreditación Manual

Descripción

Se ha definido que un usuario con permisos para «Pagos Manuales» pueda acreditar una Orden  de Pago que se encuentra en estado «Pendiente de pago»

Para lograr esto, deberá hacer click en el botón $, en la sección de acciones de la pantalla. Esto desplegará el siguiente modal:

En esta sección, se deberá completar la fecha de pago y una observación. Y tras hacer click en Siguiente

Se procede a mostrar la información de  la operación, y se le solicitará su contraseña para finalizar con la acreditación del pago. En caso de que la contraseña sea incorrecta, se le indicará apropiadamente esto, dándole la posibilidad de volver a completarla.

Si la operación se ejecuta satisfactoriamente,en el detalle de la orden de pago, figurará un Pago manual, con la fecha provista. En caso de que el pago (Payment) original de MercadoPago impacte posteriormente a dicha operación, quedará asentado sin inconvenientes como se muestra en la siguiente imagen:

Pruebas básicas del flujo

• Pago de ordenes prepagas normalmente:
• Orden de Pago conteniendo 1 Orden
• Orden de Pago conteniendo 2 o más Ordenes
• Acreditación manual de:
• Orden de Pago conteniendo 1 Orden
• Orden de Pago conteniendo 2 o más Ordenes
• Verificación de que un Payment (callback) posterior a la acreditación manual no afecte en nada la Orden. Para ellos se puede manualmente postergar la ejecución del consumer o bien acreditar via Front Tracking una vez que se haya acreditado manualmente en el back.

Mejoras al Tarifador: Adaptaciones en el flujo de Lotes de Códigos Postales

Descripción

Se añadió el «Tiempo de demora desde» como un campo opcional, a diferencia del Tiempo de demora hasta** que  es requerido (siempre lo fue)**.

Por lo tanto se contempló esa definición al Crear/Editar un nuevo CP, y se muestra su valor tanto en la pantalla principal como en los detalles del mismo. Además de que se añadieron las validaciones pertinentes, como por ejemplo que el tiempo desde sea menor o igual que el hasta. Se añadieron a la exportación de CSV y al flujo de procesamiento de Lotes, estas mismas características.

Pruebas básicas del flujo

• Creación y Edición de un CP, indicando o no los tiempos de demora. También considerar brindar una configuración errónea (desde > hasta)
• Visualización de dicha configuración en el listado y en el detalle de un CP.
• Exportación del CSV: verificando que la información concuerde con lo visualizado en la pantalla del  listado.
• Importación: Procesar varios lotes de CP, cambiando los tiempos de demora y definiendo o no Operador.

Mejoras al Tarifador: Adición de IVA y Tiempos de demora

Descripción

A nivel Cliente

Se hicieron las adaptaciones requeridas a los Clientes. Ahora se les puede definir en la solapa «Tarifas» la característica de «Cotización con IVA», y dentro de «Configuraciones adicionales» indicar los días estimados que demora la colecta. Al activarse la opción de «Cotización con IVA» se le indica al sistema que toda cotización, ya sea via API o bien al crearse una nueva Orden, aplique el IVA (21%), tal como fue especificado.

Mientras que por el otro lado, al definir los días de demora de colecta, estos solo aplican en el flujo de la consulta del tarifador (via API).

A nivel flujo de Tarifador

Se hicieron 2 grandes cambios.

Primero se enriqueció la respuesta brindada por la API de Cotización (/api/rate) de uno o mas paquetes, de la siguiente forma:

{ "code": 200, "message": "Estimación realizada con éxito.", "count": 1, "results": { "shipping_cost": 213.8, "tax": 45.066, "insurance_cost": 0.8, "final_value": 259.666, "currency": "ARS", "min_delivery_date": "2021-04-13", "max_delivery_date": "2021-04-15" }}

Donde:

• shipping_cost (costo de envío): es el subtotal con el descuento (configurado a nivel Cliente) aplicado.
• insurance_cost (costo de seguro): valor discriminado del Seguro.
• tax (impuesto): el monto resultante de aplicarle IVA a (shipping_cost + insurance_cost).
• final_value: el resultado del shipping_cost + insurance_cost + tax
• min_delivery_date: la fecha estimada de entrega mínima, siguiendo la formula:
  Fecha actual + CP.Tiempo_de_demora_desde + Cliente.Dias_estimados_de_colecta + fines de semana
• max_delivery_date: la fecha estimada de entrega máxima, siguiendo la fórmula:
  idem a la anterior, pero tomando el tiempo de demora hasta del CP.

Se le añadieron las validaciones pertinentes con respecto al Código Postal:

• Si esta inactivo, no se realiza la cotización y muestra un mensaje de error

  {“code”: 500,“message”: “Codigo postal no habilitado para el envío. Motivo: el CP se encuentra inactivo”,“count”: 1,“results”: false}

Nota: un mensaje “equivalente” se muestra cuando se crea un Orden y el CP del comprador está inactivo.

• Si esta activo, pero sin tiempos de demora configurados, no realiza la cotización y muestra un mensaje de error.

  {“code”: 500,“message”: “Codigo postal no habilitado para el envío. Motivo: el CP no posee tiempos de demora.”,“count”: 1,“results”: false}

• En caso de que este activo, pero su Zona de tarifa, no esta incluida dentro de la Tarifa  del cliente, en ese caso se realizará una cotización basada en aquella zona definida como «Default». En ese caso la API responderá satisfactoriamente la consulta, tomando ese valor para el calculo.

Se unificó el criterio de cotización, para que indistintamente del escenario se obtenga el mismo valor cotizado, tendiendo en cuenta todas las variables involucradas en el cálculo. Entre los escenarios se encuentran:

• Orden nueva
• Orden « pendiente de Pago» sin cotizar que es remitida a Mercado Pago.
• Solicitud de Modificación de Domicilio que involucre cambio de CP.

Pruebas básicas del flujo

• Tomar un Cliente que cotice con IVA y otro sin (o bien hacer cambios en la configuración), y elaborar una petición (request) “equivalente” entre el cotizador (/api/rate/) y la creación de ordenes. Aca se tiene que considerar que el Cotizador maneja unidades expresadas en Kg, mientras que la API Creación de ordenes Grs. Tras realizar ambas consultas/peticiones, el final_value  arrojado debe ser el mismo.
• Crear ordenes para cliente prepago y asegurarse que no posean cotizacion al momento de ejecutar el flujo de pago de MercadoPago (modal).
• Crear una orden con un CP distinto a los anteriores, y luego hacer una modificación para setearle el que originalmente poseia: el valor cotizado debe ser el valor conocido.
• Enviar peticiones al cotizador haciendo referencia a un CP que no este activo o bien no posea los tiempos de demora configurados (desde = NULL).
• Realizar una creación de una orden sobre un CP inactivo, y verificar que la API arroje un mensaje de error.

Devoluciones: Adaptar comunicación con VKM ante «No Entregado»

Descripción

Se añadió al flujo de Devoluciones este cambio en el requerimiento original. Por lo tanto al darse la condición de que un envío se encuentre en el estado «No Entregado» y se solicite su devolución, cuando el consumer correspondiente procese ese requerimiento, invocará la anulación del pedido tal cual como fue especificado.

Por ejemplo: El consumer, añadiendole información extra para examinar e indagar su comportamiento, demuestra la correcta invocación de la Anulación a VKM Y luego la invocación del creaDocumentento del tipo W:

Pruebas básicas del flujo

• Añadir a un envío el estado «No Entregado» y solicitar su devolución. Verificar la comunicación con VKM al ejecutar el consumer de devoluciones, siguiendo como ejemplo otros casos de debugueo..
• Similar al anterior pero probando otros estados (distinto de «Retirado», «Descargado» y «No Entregado»), para verificar que la anulación no se invoque de manera inapropiada.