El presente manual tiene como finalidad la capacitación al usuario que desee integrar su aplicación de ventas con los servicios que expone Promo.
Se provee una descripción detallada de los mensajes que deben ser enviados al mismo y de cómo interpretar los mensajes de respuesta que dará ante un requerimiento.
PROMO provee la siguiente documentación:
Este documento tiene la finalidad de capacitar al usuario que desee utilizar la consola de Administración de Promociones de PROMO.
Este documento describe los procedimientos para instalar los componentes de Motor y Consola, la creación e inicialización de la Base de Datos y los requerimientos necesarios para el correcto funcionamiento de dichos componentes.
Este documento describe detalladamente los mensajes que deben ser enviados al Motor de Promociones y la forma de interpretar los mensajes de respuesta que el mismo dará ante un requerimiento.
Este documento describe detalladamente los servicios que expone la consola de Promo y la forma de enviar y recibir información con ella.
Antes de continuar con la lectura del presente manual, se recomienda leer los capítulos 2 y 3 del Manual de usuario. |
En el desarrollo de este manual se utilizarán para los ejemplos básicamente tres herramientas que son de dominio público:
Antes de consumir un servicio provisto por Promo, deberá realizarse un Proceso de autenticación OAuth2. El mismo consiste en obtener un TOKEN que luego debe ser enviado en los subsiguientes mensajes.
Entonces como primer paso a comenzar la comunicación con los servicios de Promo, el sistema externo debe realizar el proceso descripto aquí.
Primero deberá de solicitarse el Token de acceso, que utilizando CURL el comando sería:
-- curl –v –X POST –u my-client: -d "grant_type=password" –d "username=sender" –d "password=mate" –d "scope=read" http://localhost:8080/promo/oauth/token |
Donde "http://localhost:8080/promo" debe ser cambiado por la URL donde se encuentra la consola de Promo.
La respuesta ejemplo se puede ver en la siguiente ventana:
Una vez obtenido el token, se deberá enviar en las subsiguientes solicitudes. Por ejemplo realizamos un GET con la herramienta CURL:
-- curl -X GET -H "Authorization: Bearer 8c014b30-a674-456e-bc18-29a072a7a1f8" -H "Content-type: application/json" -H "Accept: application/json" "http://localhost:8080/promo/api/rest/customer?code=1" |
De la misma forma, para obtener el Token en POSTMAN, sería:
Luego presionar el botón "Get New Access Token"
Por último presionar el botón "Use Token"
Una vez obtenido el token, se puede enviar una solicitud, por ejemplo realizamos un GET:
Al presionar el botón "Send", se obtiene el siguiente resultado:
|
---|
Aquí se presentan los servicios provistos para consulta de información contenida en PROMO.
Antes de consumir el servicio debe obtenerse el TOKEN de identificación como se explica en "Seguridad: Autenticación de Sistemas Externos con los Servicios".
Se agregó la nueva variable rabbitMq.date.UTC para que todos los mensajes que se devuelven a alguna de las consultas via Rest disponible en Promo, se informen con el formato del locale configurado en el servidor, que por default es GMT. |
Servicios afectados:
Tener en cuenta la configuración descripta en Información de Configuración |
PROMO expone un servicio que permite consultar elementos de fidelidad y transacciones (ventas y devoluciones) a la BBDD utilizando el ID de cliente.
Junto con los campos del cliente, también se devuelve un listado de Elementos de Fidelidad y Cupones, y sus últimas N transacciones.
Si no tiene elementos de Fidelidad, se devolverán los Elementos o Cupones vacíos; igualmente en el caso que no tengan transacciones, no traerá datos sobre las mismas.
El código de la consulta debe ser exacto y solo se devolverá un resultado, si es que el cliente existe.
El formato en que se responde es en JSON.
Este método accesible desde api/rest/customer es el encargado de devolver en formato JSON el customer o cliente solicitado por medio de la acción GET.
Tiene tres parámetros de ingreso:
Nombre | Valor |
---|---|
companyId | El código de la compañía. String. Requerido. |
code | El código del cliente. String. No requerido. |
identificationType | El código del tipo de identificación del cliente (por ej, "dni"). String. No requerido. |
identifier | El nro. de identificación de cliente (por ej. nro de dni). String. No requerido. |
lastSales | Con el valor configurado por el cliente, se habilita en la respuesta un listado con las últimas transacciones del cliente. No requerido |
offset | Número entero. Indica desde qué posición comenzar a retornar clientes cuando no se consulta un cliente específico. Por defecto es 0 . Si se omite, comienza desde el primer cliente. No requerido. |
max | Número entero. Define la cantidad máxima de clientes a retornar por consulta cuando no se consulta un cliente específico. El valor máximo permitido es 1000 . Si se omite, se toma por defecto 1000 . No requerido. |
Para buscar el cliente se debe enviar, o bien el parámetro "code", o bien el par de parámetros identifier e identificationType.
En caso de no enviar ninguno, retorna [] con un mensaje de error en el log. Si envían code y el nuevo par de parámetros mencionados, buscará por code ya que tiene prioridad de búsqueda por el campo anterior en este caso particular.
El código debe ser exacto y solo se devolverá un resultado, si es que el cliente existe.
El campo “lastSales” es numérico, e indica la cantidad de transacciones que tiene un cliente. El usuario deberá ingresar la cantidad de transacciones que desea visualizar.
Si pasan x números se retornan esas x últimas transacciones. Si pasan 0, o no lo pasan (vacío), no se retorna esa info.
Enviando a http://{{SERVER}}:{{PORT}}/promo/api/rest/customer?companyId={{COMPANYID}}&identifier=12345&identificationType=dni o bien http://{{SERVER}}:{{PORT}}/promo/api/rest/customer?companyId={{COMPANYID}}&code=1 o bien, para la consulta de las ultimas 10 transacciones asociadas al cliente, se deberá enviar, por ej. http://URLPROMO:PUERTO/promo/api/rest/customer?code=0102909421&companyId=napse&lastSalesInfo=N |
-- http://{server}:{port}/promo/api/rest/customer?code=12345&companyId={companyId} |
Obteniéndose la siguiente respuesta:
|
---|
En caso de que el cliente no exista en la base la respuesta se devolverá vacía.-
El tag "Segments" mostrara la informacion de semgentos externos si estuviera el cliente asociado a tales segmentos. |
Segmentos Internos en el Servicio de Consulta de Clientes Se ha actualizado el Servicio de Consulta de Datos de Clientes para incluir la posibilidad de obtener los segmentos internos de un cliente cuando se consulta de forma puntual.
|
La respuesta por cada elemento incluido en el atributo lastSales , tiene la siguiente estructura (estos datos se sumaran, en caso de corresponder, a los datos que ya se informan de tarjetas y cupones asociados al cliente):
Atributo | Descripción |
---|---|
transactionId | Código de la transacción |
transactionType | Tipo de la transacción |
storeCode | Código de la tienda |
terminalCode | Código de terminal |
customerId | Código de cliente |
customerType | El código del tipo de cliente |
mapVersion | El nro. del mapa evaluado al realizar esta transacción |
offline | Con valor true determina si fue originada offline, y false determina que fue originada online. |
date | Fecha de la transacción. Formato equivalente al de la fecha de creación del cliente (campo creationDate). Por ej. 2021-06-24T20:34:39Z |
transactionStatus | El estado en que se encuentra la transacción actualmente. |
itemsTotalQuantity | Cantidad de unidades de productos vendidos al cliente. En el caso de venta por magnitud, al no enviar qty, suma un 1; por ej. vendiendo los siguientes ítems, daría como resultado "itemsTotalQuantity": 2.0 : <item-add code="1234" magnitude="1.5" seq="1" <otros atributos>/> <item-add code="2222" magnitude="5.5" seq="2" <otros atributos>/> |
summaryValues | Representan el resumen de valores de la transacción. Objeto que contiene cuatro atributos. Detalle a continuación. |
summaryValues.subtotal | Indica el subtotal de la transacción sin descuentos ni recargos |
summaryValues.discount | Indica el monto de los descuentos aplicados en la transacción |
summaryValues.surcharge | Indica el monto de los recargos aplicados en la transacción |
summaryValues.total | Indica el total de la transacción con descuentos y recargos aplicados |
payments | Representan los pagos presentados en la transacción. Es un listado de objetos que contienen tres atributos. Detalle a continuación. |
payments.type | El tipo del medio de pago |
El id del medio de pago | |
payments.amount | El monto del pago realizado con ese medio. |
loyaltyCards | Representan un detalle de los elementos de fidelidad presentadas en la transacción. Es un listado de objetos que contienen cinco atributos. Detalle a continuación. |
El código de elemento del elemento de fidelidad | |
loyaltyCards.obtainedPoints | Puntos obtenidos durante la transacción |
loyaltyCards.benefitedByPromotion | true en caso de haber obtenido puntos. |
loyaltyCards.redeemedPoints | Puntos redimidos durante la transacción |
loyaltyCards.redeemedByPromotion | true en caso de haberse redimido puntos. |
coupons | Representan un detalle de la cantidad de cupones emitidos y consumidos en la transacción. Es un objeto que contiene dos atributos. Detalle a continuación. |
coupons.obtained | Cantidad de cupones obtenidos. |
coupons.redeemed | Cantidad de cupones redimidos. |
|
Tener en cuenta que este servicio rest, en la sección lastSales, se alimenta de las colecciones transaction, transactionFlatten, y viewCustomer. Para que esté la info disponible es necesario que se hayan procesado los jobs: sts.console.job.LoyaltyJob (Finalización de transacciones) y sts.console.job.TransactionFlattenJob (Aplanado de Transacciones). |
En caso de que el cliente no exista en la base la respuesta se devolverá vacía.
PROMO expone un servicio que permite consultar para un cliente, cuales son las promociones con limites que se le han aplicado en las transacciones que haya podido realizar, a la BBDD utilizando el ID de cliente.
Si no tiene limites asociados el cliente consultado. el campo "limitsDetail" se devolverá vacío.
El código de la consulta debe ser exacto y solo se devolverá un resultado, si es que el cliente existe.
El formato en que se responde es en JSON.
La solicitud utilizando CURL será:
-- curl -X GET -H "Authorization: Bearer-- -- 8c014b30-a674-456e-bc18-29a072a7a1f8" -H "Content-type: -- -- application/json" -H "Accept: application/json" -- -- "http://localhost:8080/promo/api/rest/limit/limitStatus?companyId=napse&code=85001"-- |
Obteniéndose la siguiente respuesta:
|
---|
En caso de que el cliente no exista en la base la respuesta informara "El cliente especificado no existe".
PROMO expone un servicio que permite consultar cupones a la BBDD utilizando solo el número de cupón y como respuesta se obtienen los movimientos asociados a dicho cupón.
También se pueden realizar consultas sobre el historial de movimientos de cupones.
Los parámetros de entrada de la consulta son:
Propiedad | Tipo de dato | Descripción | ||||||||||
companyId | Alfanumérico | Código de la compañía. Requerido | ||||||||||
barcode | Alfanumérico | Código del elemento de fidelidad la cual se quiere consultar. Opcional | ||||||||||
limit | Numérico | Cantidad de registros de movimientos a retornar (default: 5) con un máximo de 100.000 por consulta. Opcional | ||||||||||
dateFrom | Numérico | Fecha de Inicio en formato YYYYMMDD. Si no se especifica barcode. Opcional | ||||||||||
dateTo | Numérico | Fecha de Final en formato YYYYMMDD. Si no se especifica barcode. Opcional | ||||||||||
couponAction | Alfanumérico | Código de Operación que se quiere consultar. Si no se especifica barcode. Por defecto son todas las operaciones. Los valores disponibles son: CREATE, REDEEM, VOID. Opcional | ||||||||||
timeFrom | Numérico | Hora de Inicio con formato HHmm. Opcional | ||||||||||
timeTo | Numérico | Hora de Fin con formato HHmm. Opcional | ||||||||||
offset | Numérico | Permite navegar dentro del rango. Se usa en conjunto con el parámetro limit. Por ej: Se quiere navegar los primeros 10 registros, configurar offset=1 y limit=10. Se quiere ver los 10 siguientes, configurar offset=11 y limit 10. Cuando ya no hay más registros va a dar vacío. Opcional | ||||||||||
isTypes | Booleano | Si se ingresa "true" se podrá consultar los tipos de cupones existentes. Si está en "false" devolverá los cupones (se trata de una consulta de cupones y no de tipos). Opcional
| ||||||||||
typeCode | Alfanumérico | Si se deja este campo vacío, traerá todos los tipos de cupones. Sino, se podrá consultar por un tipo de cupón específico. Para utilizar este campo, "isTypes" debe estar en "true". Opcional | ||||||||||
typeActive | Booleano | Se podrá consultar por tipos de cupones Activos (true) o Inactivos (false) . Si se deja vacío (o no se envía) trae ambos. Opcional. | ||||||||||
cuponType | Alfanumérico | Tipo de cupón. Opcional |
Es obligatorio especificar al menos uno de los siguientes campos para completar la acción:
|
Se pueden enviar el dateFrom y dateTo sin cargar los datos de timeFrom y timeTo, estos serán opcionales. Pero solo se utilizarán los parámetros timeFrom y timeTo si tiene cargados los parámetros de dateFrom y dateTo, caso contrario no serán utilizados. |
Modificación del Servicio de Consulta de Cupones: En la versión 7.4 de Promo, se ha actualizado el servicio de consulta de cupones para ofrecer mayor flexibilidad en las consultas de tipos de cupones. Ahora es posible realizar las siguientes consultas:
Para lograr estas consultas, se han incorporado tres nuevas propiedades:
Comportamiento adicional:
|
La respuesta del servicio dependerá del tipo de cupón. Como se ve en el siguiente ejemplo, si utiliza el tipo de cupón Pre Impreso, como el mismo no utiliza amount ese campo traerá null en lugar de 0.
|
http://localhost:8073/promo/api/rest/coupon?companyId=2&barcode=1040BC005233 |
La misma pero utilizando CURL:
-- curl -- X GET -H "Authorization: Bearer c4349afa-2c2e-46a8-b768-f89a4cb334bf'" -- H "Content-type: application/json" -H "Accept: application/json" http://localhost:8073/promo/api/rest/coupon?companyId=2&barcode=1040BC005233 |
Obteniéndose la siguiente respuesta:
|
---|
-- http://localhost:8073/promo/api/rest/coupon?companyId=napse&dateFrom=20240301&dateTo=20240325&limit=100000&couponAction=create |
-- curl -X GET -H "Authorization: Bearer ea41e16c-6070-4a05-82c1-6d54ae70a225" -H "Content-type: application/json" -H "Accept: application/json"http://localhost:8073/promo/api/rest/coupon? dateFrom=20240301&dateTo=20240325&companyId=napse&limit=100000&couponAction=create |
Obteniéndose la siguiente respuesta:
|
-- http://localhost:8073/promo/api/rest/coupon?dateFrom=20240101&dateTo=20240319&companyId=napse |
Obteniéndose la siguiente respuesta:
|
PROMO expone un servicio que permite consultar el estado de cupones a la BBDD utilizando como parámetros el Id de cliente, Id de la compañía, el tipo de acción y el rango de fechas (Fecha_desde y Fecha_hasta) y como respuesta se obtienen los movimientos asociados a dicho cupón.
La Url para acceder al servicio es:
-- http://[server]:[port]/promo/api/rest/couponStatements |
os parámetros de entrada de la consulta son:
Propiedad | Tipo de Dato | Descripción |
---|---|---|
customerId | Alfanumérico | Identificador único del cliente. Requerido |
companyId | Alfanumérico | Código de la compañía. Requerido |
actionType | string | Tipo de operación que se quiere consultar. Si no se especifica, Por defecto son todas las operaciones. Los valores disponibles son: CREATE, REDEEM, VOID. Requerido |
dateFrom | alfanumérico | Fecha de Inicio en formato YYYYMMDD. Opcional |
dateTo | alfanumérico | Fecha de Final en formato YYYYMMDD. Opcional |
Ej, se solicitan los cupones generados para el cliente Id = 1
y como respuesta se obtienen los datos del cupón asociado al cliente y su estado.
Respuesta:
|
---|
PROMO expone un servicio que permite consultar elementos de fidelidad a la BBDD utilizando solo su número de elemento y como respuesta se obtienen los datos del elemento en cuestión y los movimientos asociados a dicho elemento. Los datos que se devuelven son: fecha, id de transacción, tipo de operación, monto, tienda.
Para consumir este servicio se debe realizar una solicitud del tipo GET con los parámetros correspondientes a la siguiente URL:
Los parámetros de entrada de la consulta son:
Propiedad | Tipo de dato | Descripción |
companyId | Alfanumérico | Código de la compañía. Requerido |
code | Alfanumérico | Código del elemento que se quiere consultar. Requerido |
limit | Numérico | Cantidad de registros de movimientos a retornar (default: 5) con un máximo de 100.000 por consulta. Opcional |
dateFrom | Numérico | Fecha de Inicio en formato YYYYMMDD. Opcional |
dateTo | Numérico | Fecha de Final en formato YYYYMMDD. Opcional |
requestTypes | Booleano | (desde 7.EP2.1) Si se especifica el valor true se retornarán solamente los tipos de elementos definidos. *ver ejemplo mas abajo. Opcional |
cardAction | Alfanumérico | Código de Operación que se quiere consultar. Si no se especifica code. Por defecto son todas las operaciones. Los valores disponibles son: CHARGE, RECHARGE, AMOUNT_UPDATE, SALE, EXTENDED_POINTS. Opcional |
timeFrom | Numérico | Hora de Inicio en formato HHmm. Opcional |
timeTo | Numérico | Hora de final en formato HHmm. Opcional |
offset | Numérico | Permite navegar dentro del rango. Se usa en conjunto con el parámetro limit. Por ej: Se quiere navegar los primeros 10 registros, configurar offset=1 y limit=10. Se quiere ver los 10 siguientes, configurar offset=11 y limit 10. Cuando ya no hay más registros va a dar vacío. Opcional |
Se pueden enviar el dateFrom y dateTo sin cargar los datos de timeFrom y timeTo, estos serán opcionales. Pero solo se utilizarán los parámetros timeFrom y timeTo si tiene cargados los parámetros de dateFrom y dateTo, caso contrario no serán utilizados. |
Si se especifica un elemento, se retornarán los datos y movimientos asociados a dicha elemento, pudiéndose opcionalmente especificar un rango de fechas y un limite en la cantidad de movimientos.
Si no se especifica el elemento, se debe especificar un rango de fechas y se retornaran todos los movimientos de los elementos en ese rango, incluyendo en ese caso el numero del elemento que se trata.
Para el caso de información de elementos, el Formato de la Respuesta será (JSON):
Propiedad | Tipo de dato | Descripción | ||||||
_id* | Alfanumérico | Uso Interno | ||||||
amount* | Numérico | Saldo Actual del elemento. | ||||||
code* | Alfanumérico | Número del Elemento | ||||||
Created* | Alfanumérico | Fecha de Creación en formato ISODATE | ||||||
customerId | Alfanumérico | Id de cliente asociado al elemento | ||||||
activation | Numérico | Fecha de activación | ||||||
isConsumed* | Booleano | Si ha sido consumida o no | ||||||
status* | Alfanumérico | Estado actual del elemento | ||||||
storeCode* | Alfanumérico | Código de Tienda de generación (si aplica) | ||||||
terminalCode* | Alfanumérico | Código de terminal de generación (si aplica) | ||||||
transactionId* | Alfanumérico | Código de Transacción que la genero (si aplica) | ||||||
lastPurchaseDate | Numérico | Fecha del ultimo movimiento | ||||||
type* | Alfanumérico | Tipo de Elemento | ||||||
typeName | Alfanumérico | Nombre del tipo de elemento | ||||||
amountPrev | Numérico | monto previo | ||||||
version* | Numérico | Uso Interno | ||||||
cardHistory | Colección | Conjunto de registros que corresponden a cada movimiento del elemento, con:
Conjunto de registros que corresponden a la promoción que aplica al movimiento del elemento
|
Para el caso de Tipos de elemento:
Propiedad | Tipo de dato | Descripción |
amountChargeLimit | Numérico | Limite de carga |
cardNumberLength | Numérico | Longitud del número del elemento |
cardTypePrefixRange | Array | definición de rangos de prefijos para ese elemento. |
code | Alfanumérico | Código del tipo |
customerValidation | Alfanumérico | Si es Nominado, el tipo de validación de customer (NO, API, FILE) |
description | Alfanumérico | Descripción del tipo |
isActive | Booleano | True si se encuentra activo |
isCVVRequired | Booleano | True si requiere cvv |
isNominated | Booleano | True si es nominado |
isRechargeable | Booleano | True is es recargable |
name | Alfanumérico | Nombre del tipo |
Via CURL:
-- curl -- X GET -H "Authorization: Bearer 8c014b30-a674-456e-bc18-29a072a7a1f8 -- H "Content-type: application/json" -H "Accept: application/json" "http://localhost:8080/promo/api/rest/card?code=1000000000001&companyId=napse&dateFrom=20200401&dateTo=20200431" |
El cual recibirá una respuesta del tipo:
|
---|
Via CURL:
-- curl -- X GET -H "Authorization: Bearer 8c014b30-a674-456e-bc18-29a072a7a1f8 -- H "Content-type: application/json" -H "Accept: application/json" "http://localhost:8080/promo/api/rest/card?companyId=napse&dateFrom=20200429&dateTo=20200429&limit=100000" |
El cual recibirá una respuesta del tipo:
|
---|
Cuando se especifica el parámetro "isTypes" se retornarán solamente los tipos de elemento definidos.
Via CURL
-- curl -- X GET -H "Authorization: Bearer 8c014b30-a674-456e-bc18-29a072a7a1f8 -- H "Content-type: application/json" -H "Accept: application/json" "http://localhost:8080/promo/api/rest/card?companyId=napse&isTypes=true" |
El cual recibirá una respuesta del tipo:
|
---|
PROMO expone un servicio que permite consultar el estado de los puntos de un elemento de fidelidad a la BBDD utilizando solo su número del elemento y como respuesta se obtienen los datos del estado de los puntos del elemento en cuestión y los movimientos asociados a dicha elemento.
Los datos que se devuelven son: número y tipo de elemento de fidelidad, Id de transacción, acción realizada, tienda, fecha de la transacción, cantidad de puntos involucrados en la acción y código del cliente.
Para consumir este servicio se debe realizar una solicitud del tipo GET con los parámetros correspondientes a la siguiente URL:
Los parámetros de entrada de la consulta son:
Propiedad | Tipo de Dato | Descripción |
---|---|---|
companyId | Alfanumérico | Código de la compañía. Requerido |
toDate | Numérico | Fecha de Final en formato YYYYMMDD. Requerido |
fromDate | Numérico | Fecha de Inicio en formato YYYYMMDD. Requerido |
customerCode | Alfanumérico | Identificador único del cliente. Requerido |
isConsume | Booleano | Si ha sido consumida o no. Requerido |
Todos estos datos son requeridos; cuando falte alguno de ellos la aplicación enviará un mensaje como el ejemplo:
El rango de fechas no puede ser mayor a un mes:
El Formato de la Respuesta será (JSON):
Propiedad | Tipo de Dato | Descripción |
---|---|---|
cardNumber | Alfanumérico | Número del elemento de fidelidad asociado al cliente |
cardTypeCode | Alfanumérico | identificador único de tipo de elemento de fidelidad |
transactionId | Numérico | Número de transacción |
action | Alfanumérico | Acción llevada a cabo (Otorga, Consumo) |
storeCode | Alfanumérico | Identificador único de Tienda donde se llevó a cabo la transacción |
date | Numérico | Fecha y hora de la transacción |
amount | Numérico | Cant. de puntos participantes en la transacción |
customerCode | Alfanumérico | Identificador único del cliente |
terminalCode | Alfanumérico | Terminal donde se realizó la transacción |
La respuesta al Ej 1 es:
|
---|
PROMO expone un servicio que permite consultar mapas utilizando solo el número de mapa y como respuesta se obtiene el xml del mapa de la misma forma que se obtiene por la opcion de "descargar".
Como en el caso de los servicios REST previamente descriptos se necesita una authorizacion vía OAuth2.
La siguiente figura muestra el contenido del request de ejemplo:
Donde:
La respuesta es del tipo:
|
Donde se observa:
PROMO expone un servicio que permite consultar promociones distribuidas utilizando un filtro por compañía (obligatorio) y parámetros de filtros opcionales (tienda/as, región/es, código/os) y como respuesta se obtiene un xml con las promociones obtenidas.
Como en el caso de los servicios REST previamente descriptos se necesita una autorización vía OAuth2.
La siguiente figura muestra el contenido del GET del ejemplo:
-- http://[SERVER]:[PORT]/promo/api/rest/promotions |
|
---|
Donde:
La respuesta es del tipo:
|
Donde se observa:
PROMO expone un servicio que permite consultar promociones disponibles utilizando un filtro por compañía y versión de mapa (obligatorios) y el código de Promoción como parámetro de filtro opcionales.
Para utilizar este servicio se debe realizar una solicitud del tipo GET con los parámetros correspondientes a la siguiente URL:
La siguiente figura muestra el contenido del request de ejemplo:
Los parámetros de entrada son:
Propiedad | Tipo de Dato | Descripción |
---|---|---|
mapVersion | Alfanumérico | Versión de Mapa que contiene la promoción. Requerido |
companyId | Alfanumérico | Identificador único de la empresa. Requerido |
promotionCode | Alfanumérico | código de la promoción que forma parte del mapa. No requerido |
Los parámetros de salida son:
Propiedad | Tipo de Dato | Descripción |
---|---|---|
mapVersion | Alfanumérico | Versión del mapa requerido. |
code | Alfanumérico | código de la promoción que está contenida en el mapa. |
name | String | nombre de la promoción. |
conditionSimple | String | condición simple de la promoción. |
conditionCombo | String | condición combo de la promoción. |
conditionDate | Alfanumérico | condición de fechas de la promoción. |
benefitTypeDescription | String | Descripción del tipo de beneficio de la promoción. |
benefitClassDescription | String | Descripción de la clase de beneficio de la promoción. |
benefit | String | Descripción del beneficio de la promoción. |
promotionType | String | Tipo al que pertenece la promoción. |
promotionSubType | String | Subtipo al que pertenece la promoción. |
promotionApplicationForm | String | Forma de aplicación de la promoción. |
La respuesta es del tipo:
|
PROMO expone un servicio que permite consultar todas las promociones disponibles que se ven en la pantalla "Gestión de promociones" para una compañía especifica (código de compañía obligatorio). Opcionalmente es posible filtrar por rango de fechas "Desde" y "Hasta", y/o por "Tienda" y/o por "Campaña".
Para utilizar este servicio se debe realizar una solicitud del tipo GET con los parámetros correspondientes a la siguiente URL:
-- http://servidor:puerto/promo/api/rest/promotions/allAvailable |
Filtros opcionales:
dateFrom
y dateTo
), tienda (store
) o campaña (campaign
). Todos estos filtros son opcionales, lo que significa que la consulta puede realizarse con o sin ellos.dateFrom
y dateTo
son opcionales, es necesario que se envíen ambos juntos para que el servicio consulte correctamente dentro de un rango de fechas.Rango de fechas:
Condiciones de tienda:
store
incluye esa tienda, se devolverá esa promoción.La siguiente figura muestra el contenido del request de ejemplo:
Los parámetros de entrada son:
Propiedad | Tipo de Dato | Descripción |
---|---|---|
companyId | Alfanumérico | Identificador único de la empresa. Requerido |
dateFrom | Numérico | Fecha de Inicio en formato YYYYMMDD. Opcional |
dateTo | Numérico | Fecha de Final en formato YYYYMMDD. Opcional |
store | Alfanumérico | Código de Tienda (storeCode). Default: Todas. Opcional |
campaign | Alfanumérico | Nombre de la Campaña. Opcional |
offset | Numérico | Registro desde el cual comenzar el conteo hasta “max” registros. Default: 0. Opcional |
max | Numérico | Máximo de registros a retornar con un máximo de 100 por consulta. Opcional |
Jerarquía de productos:
Limitaciones por tienda:
|
Los parámetros de salida son:
Propiedad | Tipo de Dato | Descripción |
promotions | Array | Lista de promociones |
conditionCategoryComparator | String | Comparador para la categoría |
conditionZoneComparator | String | Comparador para la zona |
conditionFormat | Array | Lista de formatos |
conditionSubCategoryComparator | String | Comparador para subcategoría |
endDate | String | Fecha de finalización de la promoción |
conditionBarcodeComparator | String | Comparador para código de barras |
conditionDepartment | Array | Lista de departamentos |
conditionSupplierComparator | String | Comparador para proveedor |
conditionCouponComparator | String | Comparador para cupón |
newPrice | Number | Nuevo precio de la promoción |
conditionBarcode | Array | Lista de códigos de barras |
frequency | Array | Frecuencia de la promoción |
discountPercentage | Number | Porcentaje de descuento |
createdAt | String | Fecha de creación |
conditionSku | Array | Lista de códigos SKU |
conditionBrandComparator | String | Comparador para la marca |
conditionSkuComparator | String | Comparador para SKU |
conditionFamilyComparator | String | Comparador para familia |
benefitsMaxApplicationValue | Number | Valor máximo de aplicación de beneficios |
conditionSupplier | Array | Lista de proveedores |
conditionSubCategory | Array | Lista de subcategorías |
updatedBy | String | Usuario que actualizó |
stores | Array | Lista de tiendas |
active | Boolean | Indica si está activa |
nro | String | Número mero de promoción |
conditionDepartmentComparator | String | Comparador para departamento |
applicationBenefit | Array | Lista de beneficios aplicados |
conditionBrand | Array | Lista de marcas |
conditionCoupon | Array | Lista de cupones |
benefitClassField | Object | Clase de beneficios |
createdBy | String | Usuario que créa |
conditionFamily | Array | Lista de familias |
conditionZone | Array | Lista de zonas |
lastUpdate | String | Última actualización |
name | String | Nombre de la promoción |
conditionCategory | Array | Lista de categoría |
comboComponentsMax | Number | Máximo de componentes en el combo |
campaign | Object | Detalles de la campañía |
startDate | String | Fecha de inicio |
conditionFormatComparator | String | Comparador para formato |
Formato de la respuesta:
Campos clave:
discountPercentage
: Si la clase del beneficio de la promoción es de tipo "Descuento Porcentaje", este campo mostrará el valor correspondiente. De lo contrario, devolverá 0.comboComponentsMax
: Representa la cantidad de ítems necesaria para cumplir con la condición de la promoción. Para promociones simples, será 1, mientras que para promociones compuestas se extrae el valor de combo.components(max)
.benefitsMaxApplicationValue
: Indica la cantidad afectada por el beneficio de la promoción.La respuesta es del tipo:
|
PROMO expone un servicio que permite consultar todas las promociones que se ven en la pantalla "Gestión de promociones" filtrando por un SKU específico pudiendo filtrar en caso de ser necesario por rango de fechas "Desde" y "Hasta", y/o por "Tienda" y/o por "Campaña".
Para utilizar este servicio se debe realizar una solicitud del tipo GET con los parámetros correspondientes a la siguiente URL:
-- http://servidor:puerto/promo/api/rest/promotions/allBySku |
Filtrado por SKU: El servicio permite obtener todas las promociones relacionadas con un SKU específico. Es obligatorio enviar el campo SKU para realizar la consulta.
Filtros opcionales: Se pueden incluir los siguientes filtros adicionales para refinar la búsqueda:
dateFrom
: Fecha de inicio en formato YYYYMMDD
. Es opcional.dateTo
: Fecha de fin en formato YYYYMMDD
. Es opcional.store
: Código de la tienda. Si no se especifica, devolverá todas las promociones aplicables a todas las tiendas.campaign
: Nombre de la campaña de la promoción. También es opcional.Rango de fechas:
dateFrom
y dateTo
, solo se devolverán las promociones que caigan dentro de ese rango.dateFrom
y dateTo
son opcionales, es necesario que se envíen ambos juntos para que el servicio consulte correctamente dentro de un rango de fechas.La siguiente figura muestra el contenido del request de ejemplo:
Las propiedades de entrada son:
Propiedad | Tipo de dato | Descripción |
companyId | Alfanumérico | Código de la compañía. Requerido |
dateFrom | Numérico | Fecha de Inicio en formato YYYYMMDD. Opcional |
dateTo | Numérico | Fecha de Final en formato YYYYMMDD. Opcional |
sku | Alfanumérico | Código del producto. Requerido |
store | Alfanumérico | Código de Tienda (storeCode). Default: Todas. Opcional |
campaign | Alfanumérico | Nombre de la Campaña. Opcional |
Jerarquía de productos: El sistema respeta una jerarquía de categorías en productos:
Consulta por tienda:
Promociones válidas: El servicio solo devolverá promociones activas, excluyendo las promociones incompletas o canceladas. Operadores soportados:
Formato de fechas: Las fechas devueltas por el servicio estarán en formato ISO DATE, como por ejemplo: |
Los parámetros de salida son:
Propiedad | Tipo de Dato | Descripción |
promotions | Array | Lista de promociones |
endDate | String | Fecha de finalización |
suggestMessage | String | Mensaje sugerido |
promotionStatus | Object | Estado de la promoción |
frequency | Array | Frecuencia |
alwaysValid | Boolean | Siempre válida |
createdAt | String | Fecha de creación |
id | String | Identificador |
benefitsMaxApplicationValue | Number | Valor máximo de aplicación |
deploymentChannels | Array | Canales de despliegue |
isEditedPromotion | Boolean | Promoción editada |
updatedBy | String | Actualizado por |
workflow | Object | Información del workflow |
active | Boolean | Indica si está activa |
combo | Null | Combinación |
reportParticipants | Boolean | Participantes del reporte |
isWorkflowApproved | Boolean | Aprobado por workflow |
conditionBrand | Array | Condiciones por marca |
promotionApplicationForm | Object | Formulario de aplicación |
companyId | String | Identificador de la compañía |
condition | Object | Condiciones de la promoción |
conditionCoupon | Array | Condiciones por cupón |
conditionFamily | Array | Condiciones por familia |
lastUpdate | String | Última actualización |
name | String | Nombre de la promoción |
conditionCategory | Array | Condiciones por categoría |
campaign | Object | Información de la campañía |
comboComponentsMax | Number | Máximo de componentes del combo |
pictureToolTip | Null | Tooltip de la imagen |
startDate | String | Fecha de inicio |
benefits | Array | Lista de beneficios |
code | Null | Código de la promoción |
isWorkflowRejected | Boolean | Rechazado por workflow |
description | Null | Descripción |
conditionDepartment | Array | Condiciones por departamento |
baseTemplate | Null | Plantilla base |
discountPercentage | Number | Porcentaje de descuento |
suggestType | Null | Tipo sugerido |
conditionSku | Array | Condiciones por SKU |
conditionTimeRange | Null | Rango de tiempo |
skuEvaluationCode | String | Código de evaluación del SKU |
cancelReason | Array | Motivo de cancelación |
conditionSupplier | Array | Condiciones por proveedor |
picturePath | Object | Ruta de la imagen |
conditionSubCategory | Array | Condiciones por subcategoría |
promotionType | Boolean | Tipo de promoción |
stores | Boolean | Lista de tiendas |
suggest | Null | Sugerido |
evaluateConditionInCombo | String | Evaluar condición en combo |
statusDescription | Array | Descripción del estado |
createdBy | Object | Creado por |
hdrFlds | Null | Campos del encabezado |
promotionSubType | Null | Subtipo de la promoción |
La respuesta es del tipo:
|
PROMO expone cuatro servicios que permiten consultar una promoción utilizando un filtro por compañía (obligatorio) y consultar mediante número de promoción o código de promoción o número de beneficio de promoción o nombre de promoción y como respuesta se obtiene un xml con la promoción obtenida.
Como en el caso de los servicios REST previamente descriptos se necesita una autorización via OAuth2.
Se puede acceder al servicio desde:
-- http://[Server]:[Port]/promo/api/rest/promotions |
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
Donde:
Donde se observa:
Si el código de la promoción no es único, en la respuesta se detallará el listado de todas las promociones que tengan ese código. Caso contrario la respuesta mostrará la información de la promoción que corresponde a ese código. |
PROMO expone un servicio que permite consultar, para un determinado tipo de elemento cual es el próximo número de elemento disponible inactivo y sin cliente asociado. Por medio de este servicio de consulta, el POS podrá conocer el número del "siguiente elemento inactivo y sin cliente asociado" para ser asignada a un cliente desde línea de cajas. Promo devolverá el número de elemento y el POS lo asociará al cliente y le reenviará (LoyaltyAssign) el número y tipo de elemento, más los datos del cliente para que se active y asigne el elemento.
Cuando no se disponga de mas elementoss inactivos y sin cliente asociado en la base de datos para el tipo de elemento consultado, se devolverá el mensaje de error indicando que no se cuenta con mas elementos disponibles para ser asociadas.
Considerar que el tipo de nominación que utilizará es "Asociación por canal de Ventas" y los elementos deberán darse de alta vía archivo.
En el archivo de alta masiva solo se informará el nro. de elemento y el Tipo.
Al darse de alta los elementos, estas quedarán en estado INACTIVO.
La activación del elemento y asignación de cliente se debe realizar por medio del "Canal de Ventas".
Para ello, una vez dadas de alta los elementos de forma masiva, desde el POS, cuando se desee dar de alta un cliente y asignarle una cuenta "prepaga" (Monedero), se enviará el mensaje de consulta de próximo Elemento (NextCardNumber). Promo informará a este mensaje el número del próximo elemento inactivo y sin cliente asignado, disponible.
Luego el POS, enviará un mensaje de asociación (LoyaltyAssign) del cliente al elemento, quedando este último activo y con el cliente informado asociado al elemento.
Para los ejemplos se realizaron las consultas de elementos utilizando la herramienta "PostMan" de Chrome. Deberá obtenerse un nuevo Token, y luego podrá realizarse la consulta de próximo número de elemento
El único método aceptado para realizar este pedido es POST.
Autenticación: Para poder acceder al servicio rest se deberá solicitar un token de autorización que será utilizado posteriormente en el encabezado de la llamada al servicio.
|
---|
Campo | Descripción |
<userName> | usuario (solicitado por Promo) |
<password> | password (solicitado por Promo) |
<servername> | nombre o ip donde este alojado Promo |
<port> | puerto http donde este corriendo Promo. |
|
---|
El token de acceso a utilizar está representado por el valor de access_token, que en este ejemplo corresponde a --dcb8a705-8b04-409f-98b7-3cd93fc7be3f. Este token deberá ser utilizado posteriormente en la cabecera del servicio rest.
El cuerpo del mensaje deberá ser un xml. A continuación se detallarán las posibles peticiones y sus respuestas involucradas.
|
---|
|
---|
|
---|
A partir de la version v7.EP2.1 promo disponibiliza el servicio de Repote de Promociones. |
PROMO expone un servicio que permite consultar la misma información que se obtiene del Reporte de Promociones por Consola (ver dicho reporte para información de filtros y datos).
|
---|
Los parámetros de entrada de la consulta son:
Propiedad | Tipo de dato | Descripción |
companyId | Alfanumérico | Código de la compañía. Requerido |
limit | Numérico | Cantidad de registros de movimientos a retornar con un máximo de 50.000 por consulta. Default: 25.Opcional |
offset | Numérico | Registro desde el cual comenzar el conteo hasta "limit" registros. Default: 0. Opcional |
dateFrom | Numérico | Fecha de Inicio en formato YYYYMMDD. Requerido |
dateTo | Numérico | Fecha de Final en formato YYYYMMDD. Requerido |
transactionType | Alfanumérico | Opcionalmente se puede filtrar por tipo de Transacción: SALES o RETURN. Default: '' (Todas). Requerido |
store | Alfanumérico | Código de Tienda por el cual se quiere filtrar. Default: '' (Todas). Opcional |
pname | Alfanumérico | El nombre de la Promoción por el cual se desea filtrar. Default: '' (Todas). Requerido |
pcode | Alfanumérico | El código de la Promoción por la cual se desea filtrar. Default: '' (Todas). Requerido |
Ejemplo de parámetros de entrada de la consulta en Postman:
La Respuesta será del tipo JSON con los siguientes parámetros:
Propiedad | Tipo de dato | Descripción |
Records | Vector | Cada uno de los registros que componen el reporte |
Header | Vector | Encabezado con información adicional |
|
---|
Cada elemento del Vector Récords contendrá los siguientes parámetros correspondientes a cada una de las columnas del informe:
Propiedad | Tipo de dato | Descripción |
transactionId | Alfanumérico | Código de la transacción |
offline | Booleano | Verdadero si la transacción fue realizada en modo offline |
unitPrice | Numérico | Precio unitario del producto |
benefitClass | Alfanumérico | Clase de beneficio |
itemCode | Alfanumérico | Código de Producto |
discountApply | Numérico | Descuento Aplicado |
deploymentChannels | Alfanumérico | Canal de Publicación |
date | Alfanumérico | Fecha de la transacción |
transactionType | Alfanumérico | Tipo de Transacción |
campaign | Alfanumérico | Campaña |
quantity | Numérico | Cantidad del Producto |
promotionCode | Alfanumérico | Código de Promoción |
promotionName | Alfanumérico | Nombre de la Promoción |
store | Alfanumérico | Tienda |
subTotal | Numérico | Subtotal de la transacción |
conditionTimeRange | Alfanumérico | Condición de Fecha/hora si aplica. |
Cada elemento del Vector Header contendrá los siguientes parámetros Informativos:
Propiedad | Tipo de dato | Descripción |
total | Numérico | Total de Registros disponibles |
offset | Numérico | offset solicitado actualmente |
limit | Numérico | Limite solicitado actualmente |
Esta información sirve para mantener una paginación como sucede en pantalla pero a nivel servicio.
En lo sucesivo se podrá ir pidiendo paginas hasta llegar a offset: 475, limit 25. También se podría realizar un paginado de a 100 registros por consulta, etc. (limit: 100). |
Obteniéndose la siguiente respuesta:
|
---|
PROMO expone un servicio que permite devolver la información referente al transaccional de limites para una determinada compañía.
Para ello deberá enviarse un GET a la siguiente URL.
|
---|
Tiene tres parámetros de ingreso:
Nombre | Valor |
---|---|
companyId | El código de la compañía. String. Requerido. |
mapVersion | n° de mapa. Requerido |
promoCode | Código de la promoción. String. Requerido |
Deberá validarse que el mapa consultado se encuentre activo en alguno de los motores conectados a la consola. |
Se obtendría un resultado como el siguiente:
Se espera obtener como respuesta un Json que informe los movimientos de limites que hayan tenido las promociones con limites definidas en el mapa consultado.
Los datos a informar deberán ser:
Nombre | Valor |
---|---|
PromotionName | Nombre de la promoción que interviene en la transacción. |
PromotionCode | Código de la promoción que interviene en la transacción. |
benefitType | Tipo de Beneficio que otorga la promoción. |
benefitClass | Clase de beneficio que otorga la transacción. |
limitScope | Tipo de Límite que tiene el beneficio de la promoción |
limitType | Indica el criterio por el cual se aplicará el límite. |
store | Id de la tienda sobre las que se distribuyó el mapa donde se encuentra la promoción |
customer | id de cliente que llevó a cabo la transacción. |
limitOriginalValue | Valor original del límite |
limitCurrentValue | Valor actual del límite |
storeCode | código de la tienda donde se llevó a cabo la transacción |
date | día en que se llevó a cabo la transacción |
transaction | id de la transacción que aplicó esa promoción con límite |
operation | Tipo de operación |
store | Id de la tienda donde se llevó a cabo la transacción |
terminal | Terminal donde se llevó a cabo la transacción. |
customer | Id del cliente que llevó a cabo la transacción |
initialValue | valor inicial de la transacción |
transactionValue | valor del limite aplicado en la transacción |
finalValue | valor final del limite aplicado en la transacción. |
|
---|
Aquí se presentan los servicios provistos para enviar o cargar información en PROMO.
Antes de consumir el servicio debe obtenerse el TOKEN de identificación como se explica en "Seguridad: Autenticación de Sistemas Externos con los Servicios"
PROMO expone este servicio para brindar una alternativa en la carga/recepción de catálogos que, hasta la presente versión, podía realizarse únicamente vía archivos. Para comprender esta sección se recomienda referirse al manejo de catálogos en el manual del usuario.
El esquema de autenticación es el mismo que en los demás servicios REST presentados aquí (ver mas arriba).
Una vez obtenido el token de acceso, el servicio puede ser invocado utilizando el método POST, desde la URL:
|
---|
El formato general del request es:
|
---|
Donde:
Campo | Descripción | Tipo de Dato | |||
---|---|---|---|---|---|
companyId | código de Empresa | alfanumérico. Requerido | |||
catalog | identificador del catálogo | alfanumérico. Requerido | |||
params | Parámetros que dependerán del catálogo | Listado de objetos de tipo clave, valor. Requerido Cada catalogo puede tener sus parámetros específicos, pero como valor genérico tenemos:
Cuando se importa un nuevo catálogo, el usuario que realizó la modificación es informado en el log de la consola:
| |||
items | Registros a importar | Colección de objetos dependientes de cada catálogo. Requerido
En el ejemplo anterior "prof" es el atributo dinámico creado para importar las profesiones de los clientes. |
Cada uno de los ítems dependerá del catalogo en su formato, pero existe un campo común a todos:
La operación a realizar sobre el elemento. Los valores posibles son:
| Alfanumérico. Requerido |
La respuesta será del tipo:
|
---|
Donde:
Campo | Descripción | Tipo de Dato | Posibles valores |
---|---|---|---|
status | código de Respuesta | alfanumérico | 200 (válido), 400 (errores de validación o de sintaxis json), 500 (error genérico) |
description | identificador del catálogo | alfanumérico | Cada uno de los nombre de los catálogos importables por mensaje rest, o bien cadena vacía si no es posible obtenerlos (por ej. ante un error de sintaxis json). |
detail | Información adicional | Objeto | Clave result, con los resultados posibles, es decir, ok o error. Clave detail, con valor correspondiente al mensaje informativo de validación, error, o procesamiento válido. |
|
Los catálogos a importar son:
Para la importación de campos adicionales de la cabecera por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de elementos de fidelidad por medio del servicio REST, deberá considerarse el siguiente formato general:
En la sección "ítems" deberán indicarse la colección de objetos dependientes de cada catálogo, en este caso, el de elementos, "Card"
|
Para la importación de Marcas por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Canales por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la carga de los catálogos de País, Provincia y Ciudad, deberá respetarse un orden en la carga de estos tres catálogos ya que hay una dependencia entre ellos. Primero deberá procesarse el catálogo de país (catalogCountry.catalog), después provincia/estado (catalogState.catalog), y al final ciudad (catalogCity.catalog). Para la importación de País por medio del servicio REST, deberá considerarse el siguiente formato general:
Para la importación de Provincias por medio del servicio REST, deberá considerarse el siguiente formato general:
Para la importación de Ciudades por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Campaña Crediticia por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Moneda por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Un cliente está conformado por los siguientes datos. (Datos como gender, identificationType, customerType, addressCountry, addressState, y addressCity, corresponden al código de cada uno de ellos y deberán importarse previamente antes de realizar cualquier operación sobre un cliente. En el caso particular de addressCountry, addressState, y addressCity, deberán importarse en ese orden debido a que se validará que una provincia/estado esté dentro de un país, y que una ciudad esté dentro de una provincia.).
Cuando desde la consola se indique que deben de Validar catálogos relacionados al catálogo de clientes, será requerida la carga de los catálogos relacionados previo a la carga del catalogo de cliente. Se importan entonces las entidades relacionadas previo a la importación de los clientes. Catálogo IDTYPE. Este catálogo define los tipos de documento o identificación válidos.
Catálogo GENDER. Este catálogo define los tipos de género válidos.
Catálogo CUSTOMERTYPE. Este catálogo define los tipos de clientes válidos
Importación de nuevos clientes.Una vez realizadas las importaciones anteriores, y considerando sus códigos, se pueden realizar altas, modificaciones, y eliminaciones de clientes.
|
Para la importación de Departamentos por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Catálogo de Evento por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Tipos de Transacción por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Familia por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Categoría por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Subcategoría por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Formato por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Ítem por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Stock por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Bancos por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Tipos de Pago por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Prefijo por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Tipo de Pago por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Bolsillo por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Perfil del Cliente por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Cadena por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Proveedor por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Zona por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Sub Zona por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Canje de Puntos por Catálogos por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Código de Producto por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Código de Barras de Producto por medio del servicio REST, deberá considerarse el siguiente formato general:
|
Para la importación de Balance por medio del servicio REST, deberá considerarse el siguiente formato general:
|
La aplicación permite borrar de ciertos catálogos, algunos atributos con solo enviar el id de dicho atributo que se le envíe en el post, utilizando el servicio Rest.
No es necesario enviar el id y la descripción. Con enviar sólo el código se puede realizar el borrado.
Los catálogos que cumplen con este criterio son:
De los anteriores, estos catálogos no admiten repetición de registros:
Y estos catálogos no son código-nombre pero igualmente cumplirán con el requerimiento porque su clave primaria incluye sólamente companyId y code
Estos catálogos no fueron afectados:
companyId-code
, no tiene un campo name
)Se pueden presentar los siguientes casos:
La Url es:
|
---|
|
---|
|
---|
Este servicio rest permite eliminar al cliente y todos los datos de fidelidad relacionados con este si se desea.
Campo | Valor |
---|---|
companyId | Id de la compañía (requerido) |
params | para dejarlo extensible, es una lista vacía |
code | Código del cliente (requerido) |
operation | D: es borrado parcial asignará rayita ( - ) en los datos del cliente (excepto el código, que se seguirá mostrando) o R: borrado total incluye fidelidad y borra también el código del cliente. Requerido |
Método | Url base |
---|---|
DELETE | -- http://URLPROMO:PUERTO/promo/api/rest/customer/delete Por ej. http://promo.com:8080/promo/api/rest/customer/delete |
Servicio rest para eliminar total o parcialmente al cliente y si se desea sus datos de fidelidad:
|
---|
Se puede enviar varios clientes por vez.
|
---|
Se observará que en la consola se ha eliminado el primer registro que encontró con los datos solicitados:
Este servicio permite realizar la importación de promociones en forma masiva a través de REST a la consola de PROMO.
El esquema de autenticación es el mismo que en los demás servicios REST presentados aquí (ver mas arriba).
Una vez obtenido el token de acceso, el servicio puede ser invocado utilizando el método POST, desde la URL:<promo>/api/rest/import
Método | Url base |
---|---|
POST | -- http://URLPROMO:PUERTO/promo/api/rest/promotion/import Por ej. – http://promo.com:8080/promo/api/rest/promotion/import |
Es importante que al momento de importar, se definan plantillas específicas, esto facilitará mucho la tarea del armado del servicio. Ejemplo: si vamos a importar descuentos por porcentaje, lo mas importante es definir la plantilla en JSON. El armado de la plantilla es un proceso que debe realizar una persona con conocimiento de la plataforma. |
Las promociones deben estar en estado Completa para poder importarlas a través de este servicio. Promo limita a 3000 la cantidad de condiciones simples que se puden agregar por promoción. |
Un ejemplo de creación, inactivación o actualización de un conjunto de promociones, es el siguiente:
|
---|
Al momento de insertar una promoción por servicio REST va a generar un nuevo id para el Beneficio, no va a considerar el id del beneficio asignado por el usuario en el json, eso es para evitar que se asignen id duplicados. Por lo que al actualizar de nuevo la promoción el usuario deberá tener en cuenta el id del beneficio generado y actualizarlo en el json antes de enviar su cambio, de lo contrario ese beneficio se tomara como nuevo y se insertara, generando como consecuencia que se duplique el beneficio, ya que al no conseguir el id cuando hace la busqueda de los beneficios en la promoción, lo tomara como un nuevo beneficio para la promoción.
|
Campo | Descripción |
---|---|
companyId | Código de la compañía. Requerido |
promotions | Conjunto de promociones a actualizar, pueden ser nuevas, actualizaciones o promociones que deseamos inactivar. Requerido |
operation | I: Insertar / U: Actualizar / R: Cancelación. Requerido |
name | Nombre de la promoción. Requerido |
code | Código univoco de la promoción. Requerido |
sets | Hace referencia a los conjuntos que definirán la condición y el beneficio de la promoción, por ejemplo:
|
conditions | Hace referencia a la combinación de conjuntos que forman parte de la condición para obtener el beneficio. Ejemplo: Conjunto 1 AND conjunto 2. Productos con Marca X y Familia Y Ejemplo 2: Conjunto 1 AND conjunto 3 Productos con marca X y Medio de pago VISA |
benefits | Hace referencia a los beneficios que se otorgarán si se cumplen las condiciones Los beneficios posibles son: NewPrice : Nuevo precio |
Si la solicitud ha sido exitosa, se podrá visualizar la siguiente respuesta:
|
En el caso de indicar un código de compañía que no existe, visualizará la siguiente respuesta:
|
Para cancelar una promoción, a través del servicio Rest se debe informar: 1. Nombre de la Promoción
La respuesta sará:
La respuesta será:
La respuesta será:
|
Ejemplo 1: Se invoca el servicio de importación masiva de promociones via CURL:
|
---|
Se enviará el siguiente request:
|
---|
El cual recibirá una respuesta del tipo:
|
---|
Si se desea cancelar y/o actualizar una promoción cuyo código se repite en otras promociones; se debe tener en cuenta informar el nombre de la que se desea cancelar y /o actualizar. |
Pasos a seguir para convertir un mapa (.xml) en un json de entrada del servicio de Importación Masiva de Promociones vía REST:
Dado el siguiente mapa .xml:
|
---|
|
---|
|
---|
Deberá pegar el contenido copiado dentro después de “operation”: I, tal como se ve en la siguiente imagen.
Esto da el siguiente resultado con el formato de importación ya completo y listo para usar desde POSTMAN:
|
---|
Al importar una promoción, la misma se importará con el workflow general por default. |
Promo admite tanto por servicio Rest como por importación de promociones en xml, importar promociones con tipo, subtipo y forma de aplicación.
Json de ejemplo:
|
---|
Desde el servicio Rest:
Request:
|
---|
Es posible insertar promociones, cuando se deshabiliten e inactiven los atributos de cabecera, en la consola (Módulo de Administración/Atributos de cabecera)
JSON de ejemplo:
|
---|
Desde Postman:
Servicio que permite tener la posibilidad de configurar una exclusión de fechas determinadas durante todo el período de vigencia para NO ser ejecutada una promoción por sucursal.
Esta opción va a permitir controlar que en determinadas fechas(que son días especiales) no se aplique las promociones que tienen productos que participan en estos días.
Este método accesible desde api/rest/catalogs es el encargado de devolver en formato JSON las fechas en que deben excluirse las promociones y en las tiendas informadas solicitado por medio de la acción POST. (http://{{SERVER}}:{{PORT}}/promo/api/rest/catalogs)
Ejemplo:
|
---|
El formato para el servicio será:
Campo | Ejemplos | Tipo de dato | Detalle |
companyId | napse | Alfanumérico | Código de la compañía - Requerido |
catalog | CatalogExclusionDates | string | Catálogo de Fechas de Exclusión - Requerido |
params | [ ] | Listado | Parámetros adicionales - Requerido |
storeCode | napse | Alfanumérico | Código de la tienda - Requerido |
promotionNames | Promo test | Alfanumérico | Nombre de la promoción que será excluida para la tienda y fecha indicada. No obligatorio para la operación R, solo en los casos en que se quiera eliminar todas las exclusiones de días específicos, este campo podrá quedar como vacío es decir "", indicando que todas las exclusiones de promociones en las fechas indicadas serán removidas. |
exclusionDates | ["2022-07-21", "2022-07-22"] | Listado de fechas | Fechas en las que será excluida la promoción, cada fecha deberá seguir el formato de "año-mes-día" - Requerido |
operation | I | Alfanumérico | Identifica el tipo de operación a realizar por cada limite a procesar (requerido), dentro de las opciones disponibles están:
|
Ejemplo:
|
|
---|
El siguiente json representa el formato para el registro de nuevas exclusiones de promociones por fecha para una tienda y promoción especifica.
|
---|
|
---|
El proceso de actualización de la exclusión de promociones por fecha, considera los puntos indicados para la operación I, teniendo solo las siguientes particularidades:
El proceso de actualización incorporara nuevos registros de fechas de exclusión para la promoción siempre y cuando ya no exista un registro previo sobre esa misma promoción, tienda y fecha.
|
---|
|
---|
El proceso de remover exclusiones contempla dos casos:
|
---|
|
---|
La diferencia con el formato anterior es que el valor del campo promotionName se deja como un string vacío igual a ""
|
---|
Si la solicitud ha sido exitosa, se podrá visualizar la siguiente respuesta (Interfaz Rest):
|
---|
En el caso de indicar un código de compañía que no existe, visualizara la siguiente respuesta:
|
---|
Como soporte al beneficio de Canje de Puntos por Catalogo), se deben especificar la tabla de productos que poseen equivalente en puntos a través de un catalogo definido para tal uso.
|
---|
Siguiendo el formato especificado anteriormente tendremos:
Campo | Valor |
---|---|
companyId | El código de la compañia correspondiente. Requerido. |
catalog | "CatalogRedeemBenefit". No se debe modificar. Requerido. |
params | Un listado vacío. No se debe modificar. Requerido. |
items | Un listado con cada item del catálogo de Canje de puntos. Requerido. |
Dentro de items, el formato es:
Campo | Valor |
---|---|
store | Código de tienda. Requerido. Alfanumérico. Si se aplica a todas las tiendas, el código de la tienda debe ser "-". |
code | Código del producto. Requerido. Alfanumérico. |
points | Puntos requeridos. Numérico con decimales. |
discountValue | Valor descuento. Numérico con decimales. |
discountType | Tipo descuento. Acepta sólo los valores "perc" (porcentaje), "fix" (descuento fijo), o bien, "nprice" (nuevo precio) |
operation | La operación a realizar sobre el elemento. Ver tabla con valores posibles. |
Así tendremos que un ejemplo de request para insertar registros en este catálogo será:
|
---|
|
---|
Esta operación es el equivalente a la función de asignacion/actualización de elementos, mas la importación de clientes nuevos (Ver proceso actual de asignación de convenios).
Esta operación realiza la asignación de tarjeta, cliente, convenio, y monto.
Debe existir previamente la tarjeta (activa o inactiva), un convenio activo, y el cliente, en caso de no existir, se da de alta.
En relación al monto, se le puede asignar o no un operador adelante del monto; especificando el operador + suma un valor al monto que la tarjeta tiene; especificando el operador - resta saldo al monto que la tarjeta tiene; si no se pone operador reemplaza el monto que la tarjeta tiene (ver más abajo el ejemplo del campo amount).
Un esquema de ejemplo es el siguiente:
|
---|
Donde:
Campo | Descripción |
---|---|
params | cardType: Tipo de elemento de fidelidad a importar que sera validado. Requerido contract: codigo de convenio al que pertenecen estos elementos/clientes. Requerido |
operation | I: Inserción / U: Actualización / R: Eliminación. Requerido |
id |
|
customer |
|
amount |
|
name | Nombre del Cliente. Cadena libre. Requerido |
surname | Apellido. Cadena libre. Requerido |
gender | Género. (ver valores por catálogo). Depende de los valores cargados en el catálogo a tal fin. |
birthDate | Fecha de nacimiento. Cadena en formato "yyyyMMdd". Más Información del formato |
idType | Tipo de identificación (ver valores por catálogo). Depende de los valores cargados en el catálogo a tal fin. Requerido |
identifier | Numero de Identificación del Cliente. Requerido |
idDate | Fecha de Expiración de la identificación. Cadena en formato "yyyyMMdd". Más Información del formato |
nacionality | Nacionalidad. Cadena Libre. |
Dirección de correo electrónico. Cadena libre. | |
customerType | Tipo de Cliente (ver valores por catálogo). Depende de los valores cargados en el catálogo a tal fin. |
address | Dirección. Cadena libre |
country | País. (ver valores por catálogo). Depende de los valores cargados en el catálogo a tal fin. |
state | Estado/Provincia (ver valores por Catálogo). Depende de los valores cargados en el catálogo a tal fin. |
city | Ciudad (ver valores por catálogo). Depende de los valores cargados en el catálogo a tal fin. |
postalCode | Código Postal |
phone | Teléfono |
Caso de uso:
Teniendo en cuenta que existe un convenio activo con código c1, y que hay un elemento existente, con código 1234000000000, y pertenece al tipo de elemento de código verano, se asigna al elemento el convenio mencionado, el monto de 100, y un nuevo cliente.
Al no existir se da de alta en la base de datos.
|
---|
Para incrementar el saldo al elemento se especifica un operador + con el valor a sumar. Siguiendo el ejemplo anterior, donde el elemento tenía un saldo de 100, se le suman 50 en este ejemplo. Después de esta operación el saldo resultante será de 150.
|
---|
Similar al incremento. Para restar saldo se usa el operador - y luego el valor del monto a restar. Si el elemento anteriormente tenía 150, al restar 20 queda en 130 de monto.
|
---|
Servicio Rest que opera de forma sincrónica para administrar clientes asociados a segmentos.
Una vez obtenido el token de acceso, el servicio puede ser invocado utilizando el método POST, desde la URL:
|
---|
El formato general de solicitud es:
Donde:
El formato de los ítems es el siguiente:
|
El formato general de respuesta es:
Donde
|
Para cualquier tipo de Programa de Objetivos, si un cliente no ha consumido durante un período igual o mayor a la frecuencia máxima y por el proceso ha sido quitado del segmento en que se encontraba; puede ser restituido al mismo segmento, a través del servicio Rest. |
Servicio Rest que opera de forma sincrónica para administrar elementos de fidelidad.
Una vez obtenido el token de acceso, el servicio puede ser invocado utilizando el método POST, desde la URL:
|
---|
El formato general de solicitud es:
|
---|
Donde
Campo | Descripción | Tipo de Dato |
---|---|---|
companyId |
| alfanumérico. Requerido |
params | Parámetros extra | Requerido detailedErrors: indica si se desea el detalle de errores en la respuesta. Default: true detailedSuccess: indica si se desea el detalle de registros correctos en la respuesta. Default: true validateCard: Realiza todas las validaciones del elemento de fidelidad. Por ej: el uso de cvv. Default: false. oneActiveCardByCustomer: Valida si un cliente posee un elemento de fidelidad activo. Default: true |
items | Registros a importar | Colección de elementos y su operación asociada. Requerido |
El formato de los ítems es el siguiente:
Campo | Descripción |
---|---|
operation | Operación a realizar sobre el registro. Ver tabla siguiente Requerido |
code | código de elemento. En este caso si se solicita crear un elemento, el mismo será creado con este código. Si se deja por defecto genera un número automáticamente. Valor por defecto: '' |
type | Tipo de Elemento en cuestión. Obligatorio, debe existir previamente. |
validFrom | Valida desde. Opcional, si se deja vacío se generara acorde al tipo de elemento. El formato es "YYYY-MM-DD" |
validTo | Valida Hasta. Opcional, ídem anterior. El formato es "YYYY-MM-DD" |
amount | Monto asociado a la operación. Requerido |
customerId | Código de cliente asociado. Valor por defecto: ''". Opcional |
cvv | CVV asociado. Valor por defecto: ''". Opcional |
reason | Motivo de la operación. Generalmente se utiliza en los cambios de saldo. Opcional. |
stroreCode | Tienda donde se realizó la transacción. Opcional. |
terminalCode | Terminal donde se realizó la transacción. Opcional. |
Se puede agregar a la mensajeria el storeCode y el terminalCode
Los cuales se detallarán en la consola en: Gestión de Elementos de Fidelidad, en el botón "acciones" /"ver" |
Los valores posibles del campo operation son:
Valor | Descripción |
---|---|
ACTIVATION | Activación del elemento con código "code". Si se utiliza la operación "ACTIVATION" sobre un Elemento de Fidelidad que no existe, Promo lo creará además de activarlo. |
AMOUNT_UPDATE | Actualización de saldo. Sumará o restará el valor según lo enviado en el Json de la operación. |
RECHARGE | Recarga |
CHARGE | Carga Inicial. Esta operación se utiliza exclusivamente cuando se activa una tarjeta con saldo, porque realiza la carga inicial activándola y cargándole el saldo. Nota: si activa la tarjeta sin saldo inicial, al realizar la primer carga esa operación es recharge. |
CONSUME | Consumo |
CANCEL | Desactivar el elemento en cuestión |
Este servicio no permite crear mas de una tarjeta activa para un mismo cliente (sin importar si está o no asociada a un convenio). Esto se controla con la variable: "oneActiveCardByCustomer", que por default es TRUE. Elementos de Fidelidad Nominados
Se observa que se crea la tarjeta; aunque el cliente ya tiene asociada una tarjeta activa.
Se observa que se creó la tarjeta. Elemento de Fidelidad no Nominado
Se observa que se ha creado la tarjeta.
Se observa que el elemento ha sido creado. |
Ejemplo de Envío de registro. En este caso se envían las siguientes tarjetas:
La respuesta informa que en la transacción "transactionId": "SVC_CRD_20230814181744", se procesaron 8 registros, de los cuales 5 se procesaron correctamente y 3 dieron error. En la sección "errorDetails" muestra información relacionada a los 3 registros que dieron error, y en la sección "successDetails" muestra para cada elemento de fidelidad insertado correctamente el monto que le quedó asignado a cada uno.
Se observa que ahora la tarjeta tiene un saldo de 120; cuando inicialmente era de 150
Donde
Los resultados de estas operaciones se verán reflejados en la Consola/Módulo de Fidelidad/Elementos de Fidelidad. |
Se puede realizar una transferencia parcial desde un elemento de fidelidad a otro.
Para permitir una transferencia parcial, el tipo de elemento de fidelidad debe tener seleccionada esta opción. |
Al operar con postman, como el mensaje correspondiente será en formato xml, la cabecera content type tendrá el valor application/xml en lugar de application/json.
Al operar con postman, como el mensaje correspondiente será en formato xml, la cabecera content type tendrá el valor application/xml en lugar de application/json.
Tener en cuenta que la url cambia para hacer esta operación, ya que se interactúa contra el motor.
El valor que aparece a la derecha de evaluate, en la dirección, es autocompletado por postman.
El cuerpo del mensaje (body) tendrá que estar vacío.
Los mensajes se enviarán como un parámetro en la dirección. Este parámetro es request. Separar el valor con dos puntos. Presionar, para facilitar el ingreso de datos, en bulk edit (a la derecha de la solicitud) que luego cambia a key-value edit.
El valor del parámetro request es el xml a enviar al motor, el cual no deberá tener ningún espacio entre etiquetas.
En la respuesta aparece como quedarían estas tarjetas de confirmarse la operación.
Se confirma la operación con el mismo mensaje, pero con el atributo status en "commit" en lugar de "loyaltyTransfer" o "rollback" para cancelar.
Al confirmar la operación....
Servicio Rest que opera de forma sincrónica para administrar Cupones.
Una vez obtenido el token de acceso, el servicio puede ser invocado utilizando el método POST, desde la URL:
|
---|
El formato general de solicitud es:
|
---|
Donde
Campo | Descripción | Tipo de Dato |
---|---|---|
companyId |
| alfanumérico. Requerido |
params | Parámetros extra | detailedErrors: indica si se desea el detalle de errores en la respuesta. Default: true detailedSuccess: indica si se desea el detalle de registros correctos en la respuesta. Default: true |
items | Registros a importar | Colección de cupones y su operación asociada. Requerido |
El formato de los ítems es el siguiente:
Campo | Descripción |
---|---|
operation | Operación a realizar sobre el registro. Ver tabla siguiente |
barcode | Código de barras del cupón. En este caso si se solicita crear un elemento, el mismo será creado con este código. Si se deja por defecto genera un número automáticamente. Valor por defecto: '' |
Correo electrónico destino para cupones de tipo electrónico. Opcional. Valor por defecto: "" | |
type | Tipo de Cupón. Obligatorio, debe existir previamente. |
amount | Monto asociado a la operación. |
customerId | Código de cliente asociado. Valor por defecto: '' |
storeCode | Tienda donde se realizó la transacción. Opcional. |
terminalCode | Terminal donde se realizó la transacción. Opcional. |
Los valores posibles del campo operation son:
Valor | Descripción | |
---|---|---|
CREATE | Emitir/Crear el cupón informado. | |
REDEEM | Redención | |
VOID | Desactivar | |
UPDATE |
|
Como máximo se podrán operar 1.000 cupones por vez, sin importar el tipo de operación (create, redeem, void, update). Por ejemplo como máximo se podrán crear 1.000 cupones en una transacción. |
Ejemplo de Envío de registro. En este caso se envían los siguientes cupones:
Donde
|
Se debe hacer la consulta en:
|
---|
Para la modificación de la vigencia de cupones se debe enviar bajo la operación "UPDATE" (solo se puede realizar con esta operación) un nuevo campo dentro del listado ítems: campo validTo.
Ejemplo:
|
---|
La respuesta será:
|
---|
Servicio rest sincrónico de clientes (alta, baja y modificación) además crea y asocia elementos (el número de elemento se genera con el prefijo más el identificador del cliente).
Se pueden generar hasta 100 clientes.
Utilizando el método POST :
|
---|
El campo “autoCard” contendrá un tipo de elemento, que si el cliente no posee será creada.
Ese elemento seguirá la definición de su tipo pero en el número asignará el nro de documento del cliente además del prefijo y largo de numeración.
Si el elemento existe no es creado. Si se crea, respeta el saldo inicial, vencimientos y todos los datos definidos en el tipo de elemento. Queda asociado al cliente en el mismo acto en que se crea.
|
---|
|
---|
También se puede administrar clientes a través del servicio de Importación de Catálogos/Catálogos de Clientes |
Se pueden dar de alta masiva de limites vía api rest, utilizando el método POST:
|
---|
El Json para insertar límites será:
|
---|
|
---|
Donde:
Campo | Descripción | Tipo de Dato | Valores posibles |
---|---|---|---|
operation | Tipo de operación a realizar | string | I(Insert), U(Update), R (Remove) |
promotionName | Nombre de la promoción, en la que se va a ingresar el límite o si ya existe se va a modificar o remover | string | |
benefitId | Identificador único del beneficio en el cual se va a ingresar, modificar o remover el/los limite/s | string | |
limitdId | Identificador único del limite que se quiere modificar o remover. Sólo se informa cuando la operacion sea U o R | string | |
limitScope | Tipo de límite | string | General, Tienda, Cliente |
storeCode | Código de la tienda. Sólo se informa si el tipo de límite seleccionado fue por tienda | ||
description | Descripción del limite | string | |
limitPeriod | Período a contabilizar del límite | string | Indefinido, Día |
numerDays | Cantidad de días si el período a contabilizar seleccionado fue días | integer | |
limitTypeCode | Tipo de variable a la que se va a aplicar el limite. | string |
|
value | valor del limite | double |
El json para modificar límites será:
|
---|
|
El json para eliminar límites será:
|
|
---|
Cada vez que se ejecute un Json con límites para las promociones esto generará un registro de importación, cuyo estado será visible desde Soporte/ Monitor de Importación. |