El presente documento tiene como objetivo mostrar el funcionamiento del módulo que permite conectar una interfaz entre el sistema SoftRestaurant® (SR) de National Soft de México y un ERP (Enterprise resources planning) o también conocido como sistema de gestión empresarial, así como también la integración con un PMS (Property Management Systems) o también conocido como HOS (Hotel Operating System).

Al implementar esta interfaz se logran el beneficio de contar con un sistema de restaurante robusto e integrarlo con los módulos de backoffice y operativos del ERP lo que permitirá a nuestros clientes contar con información para tomar mejores decisiones y automatizar la operación de su negocio.

1.1 Alcance.

Se plasman las necesidades de transmisión de datos entre ambos sistemas, con el objetivo de que sirva de comunicación al diseñar la interfaz y agilizar la implementación.

2. Módulo de conexión a ERP.

A continuación, se muestra el diagrama de funcionamiento y el modelo de operación considerando la experiencia obtenida de diferentes proyectos de integración de ERP de diversas marcas.

La idea general que SoftRestaurant® envía las ventas en una estructura de datos tipo JSON y el integrador pueda generar un servicio que lo reciba y realice las conexiones pertinentes con el ERP.

La idea general de la integración es que SoftRestaurant® (en adelante SR) utilice solo las funciones de punto de venta y las funciones administrativas sean realizadas en el ERP con lo cual se tienen los siguientes beneficios:

1. Al realizar las compras en el ERP se generan de manera natural las pólizas de egresos y la gestión de saldos a proveedores (si se trata de CXP o cuentas por pagar).
2. Se pueden realizar transferencias y movimientos de almacén entre sucursales.
3. Se evita complejidad operativa al realizar una sola integración que es el envío de venta, lo cual simplifica algún seguimiento en la comunicación de los datos (en ocasiones existen por cada plataforma 2 equipos lo cual el flujo de integración es más largo).
4. Integración automática en el módulo de presupuestos del ERP que está vinculado con las compras.

2.1 Gobierno de catálogos.

El ERP es el que gobierna los catálogos de productos en este modelo de operación e integración. Debido a esto, es necesario que las claves o identificador único de los productos sea el especificado en el ERP ya que justamente en el momento de enviar las ventas desde el SR, estos deben de coincidir para que se puedan procesar en el ERP.

Debido a que las funciones administrativas o de back office se realizarán en el ERP no es necesario alimentar otros catálogos de SR como insumos, presentación, recetas, proveedores y los relacionados a funciones de compras.

El catálogo de almacenes es un dato importante que envía SR para su procesamiento en el ERP, favor de ver el tema 3.2 seleccionar almacén por estación.

2.2 Explosión de productos o movimientos de salida de venta.

Junto con la información de ventas, se envía el detalle de los productos vendidos, el ERP toma esos productos y realiza los movimientos de salida por venta para integrarlos en su Kardex.

2.3 Configuraciones a realizar en SoftRestaurant®.

Debido a la demanda de solicitudes y proyectos de integración con ERP desarrollamos un nuevo módulo que permite configurar un servicio web para el envío de la venta, a continuación, se describen las funciones de dicho módulo.

2.3.2 Seleccionar el almacén por estación.

Configuración>Consultar/Eliminar estaciones
En este apartado se asigna el almacén en el cual se asignarán las ventas, es importante debido a que este dato se envía en la información de la venta y será procesado según corresponda en el ERP.

2.3.3 Configuración de equivalencias de forma de pago.

Configuración>Formas de Pago>Equivalencia
En esta sección se especifican el código de la forma de pago del ERP para que este pueda ser procesado, recordando que al momento de enviar la venta está considerados los datos generales, el detalle de los productos y las formas de pago.

2.3.3 Configuración de la interfaz del ERP.

Configuración>Interfaz con ERP y PMS>Configuración ERP y PMS
En esta funcionalidad se configuran la información técnica del servicio web para enviar la venta.

A continuación, se describen los datos de esta función:

1. URL de conexión: Dirección dada a un recurso único en la Web.
2. IDempresa: Identificador único para conocer cual sucursal o empresa está enviando o recibiendo información.
3. Método: Instrucción a realizar/enviar o recibir información.
4. Resource: Recurso de consulta.
5. Content-Type: Nos permite indicar que tipo de contenido será retornado.

Configuración de parámetros y encabezados opcionales.

1. Descripción: Información informativa para identificar el propósito del parámetro agregado.
2. Key: Nombre del valor a enviar o recibir.
3. Value: Valor del key a enviar o recibir.

Parámetros de ordenes de ventas de ejemplo:

Parámetros de cancelación de ventas de ejemplo:

Descripción de parámetros

• Número de orden: inicializar con valor 0.
• Tipo de Cancelación: inicializar con un valor de devolución.

2.4 Escenarios para enviar las ventas.

Existen 3 escenarios o momentos al momento de enviar la venta y dependerá de las necesidades de actualización de información que necesite el cliente.

2.4.1 Envío de ventas al finalizar la venta.

En este escenario los clientes desean enviar la venta en el momento para que pueda realizarse los movimientos de almacén en el ERP y se necesite tener inventarios en el momento. Este escenario tiene la desventaja de que al procesar la venta se añadirán el tiempo adicional en cada venta, por lo que en algunos negocios podría ser contraproducente.

Al realizar el pago de la cuenta aparecerá una ventana de espera, donde indica que se está procesando o enviando la orden de venta en que caso que por algún motivo no se pueda procesar se guardara el registro como pendiente de envió para que pueda ser procesado por el enlace.

2.4.2 Envío de ventas al cierre diario.

Este escenario es la más utilizada ya que realiza una sola comunicación a los servicios de venta del integrador al finalizar el día. Esta funcionalidad permite enviar todas las órdenes de venta pendientes procesadas.

2.4.3 Envío de ventas por intervalo de tiempo.

Configuración>Interfaz con ERP Y PMS>Enlace ERP
Esta funcionalidad permite enviar todas las órdenes de venta pendientes por intervalo de tiempo (en minutos). Es un punto intermedio entre enviarlas en el momento y al realizar el cierre diario.
Es importante mantener el enlace abierto para que se puedan procesar dichas órdenes, para ejecutar el enlace nos dirigimos a la opción.

Se tienen las siguientes opciones:

1. Consultar registros pendientes: Nos permite obtener todos los registros que aun no han sido procesados.
2. Eliminar registros pendientes: Si por alguna razón se capturo algún registro de forma errónea y no permite su envío se recomienda eliminarlo de los registros pendientes o de lo contrario siempre el enlace estará intentando enviarlo sin éxito.

2.4.4 Cancelación de ventas.

Consulta>Consulta de cuentas>Cancelar cuentas >Cancelar folio
Esta función que permite sincronizar las ventas realizadas en SR hacía el ERP y permitir que se vean reflejadas en sus procesos administrativos.

Es importante conocer que solo podemos cancelar las cuentas que aún permanecen con turno abierto por temas de control y auditoria.

3. Módulo de conexión a PMS.

A continuación, se muestra el diagrama de funcionamiento y el modelo de operación considerando la experiencia obtenida de diferentes proyectos de integración de PMS de diversas marcas.

La idea general de la integración es que en SoftRestaurant® se especifiquen los productos a consumir por el huésped y al pagar la cuenta, con una forma de pago especificada como cargo a la habitación, se envíe el importe consumido al PMS para que finalmente el huésped lo salde en su estado de cuenta.

3.1 Asignar concepto para el cargo en el PMS.

Configuración>configuración general>Enlace software hotelero>NS PMS Hoteles>
Esta opción sirve para especificar un concepto que es enviado cuando la cuenta es pagada con la forma de pago como cargo a la habitación.
Es importante mencionar que este valor es opcional, si se opta por dejarlo vacío, dicho concepto puede ser especificado por el integrador en el servicio que desarrolle, sin embargo, fue añadido para simplificar y estandarizar su uso ya que es una práctica utilizada al momento de enviar el cargo.

3.2 Configurar la forma de pago PMS.

Configuración>Formas de pago
Esta función permite especificar la forma de pago con la cual se activará el consumo del servicio para enviarse al PMS.
Es muy importante especificar el SUBTIPO a “ENLACE HOTEL”, ya que este valor y en conjunto con el registro del módulo, permitirá activar la integración y activar el envío del cargo a través del servicio configurado.
Considerar así mismo especificar en la descripción un texto adecuado que sirva a los recepcionistas indicar que es del tipo de cargo, por ejemplo “Cargo al huésped a través del PMS”.

3.3 Configuración de la interfaz del PMS.

Configuración>Interfaz con ERP y PMS>Configuración ERP y PMS

En la sección “2.3.4 Configuración de la interfaz del ERP” se describen a detalle las opciones a configurar y significado, por Lo que cualquier duda con los mismo, favor de consultar dicha sección.

Respecto a la conexión con sistemas PMS, es importante señalar 3 servicios que el integrador debe de considerar los cuales son importante porque SR los consume y forman parte del flujo operativo de sus respectivas funciones (como el cargo a habitación mencionado así como la cancelación):

• GetRoom: sirve para enviar una habitación y validar su existencia y saldo que tiene configurada en el PMS.
• PMSEnvios: es utilizado para enviar el cargo a la habitación.
• PMSCancelacion: es utilizado para cancelar un cargo previamente realizado.

3.4 Cargo a la habitación.

El momento en el cual se envían los cargos a la habitación, es al momento de finalizar el proceso de venta y se especifica la forma de pago con la cual se saldará dicha cuenta.
SoftRestaurant®, identificará la forma de pago que haya especificado en el punto 3.2 con lo cual tomará el servicio
especificado en la sección 3.3, para finalmente enviarlo en dicho servicio y si la respuesta es exitosa, salda la cuenta con esta forma de pago.
Esta cuenta se puede saldar con ya sea totalmente o de manera parcial, en caso de que el huésped por ejemplo desee saldar una cuenta con cargo y efectivo o tarjeta de crédito u otra forma de pago configurada.

Existen 2 tipos de escenarios respecto al manejo de crédito:

3.4.1 El huésped tiene un límite de crédito.

El huésped que se encuentra alojado en esta habitación tiene un monto fijo de crédito asignado y no puede limitarse del mismo.

Con lo cual SoftRestaurant®, mostrará el mensaje correspondiente para indicar al cajero que debe revisarse este parámetro y pagar la cuenta con otra forma de pago.

3.4.2 El huésped NO tiene un límite de crédito.

En este escenario el huésped por lo regular son de confianza o recurrentes el cual no tiene asignado un límite de crédito. En la pantalla de consulta de habitación se mostrará este mensaje.

3.5 Cancelación de cuentas pagadas.

Consultas>Consulta de cuentas
Si por algún motivo es necesario realizar una cancelación del cargo a habitación, se realiza en la consulta de las cuentas pagadas y desde esta opción se cancela. El objetivo es no dejar la información inconsistente en el cual un cargo se cancele en el PMS y dicho cargo permanezca en SoftResturant® con lo cual los saldos entre ambos sistemas no cuadren.

Es importante de igual manera señalar que solo se proceda a enviar cuentas canceladas cuya forma de pago fue realizada con el PMS.

Generalidades para ambos módulos.

4.1 Registro de módulo adicional.

Como prerrequisito es importante contactar a tu ejecutivo de ventas o distribuidor autorizado para adquirir el módulo de interface de ERP y PMS. Una vez teniendo el número de control y contraseña del módulo, este se registra en la siguiente ubicación: Configuración>Licencia>Registrar Licencia>Administrar módulos>Agregar.

4.2 Bitácora y Aditoría.

Configuración>Interfaz con ERP Y PMS> Bitácora de ERP
Parte importante del éxito de la interfaz es la transparencia en las intercomunicaciones de ambas plataformas. Debido a ello, añadimos una bitácora que permite consultar las ventas que han sido enviadas exitosamente y aquellas que no, para identificar la causa / raíz que ocasiona no se procese exitosamente y se pueda resolver.

Los mensajes de error los devuelve el mismo servicio desarrollado por el integrador.

Ejemplo de la estructura del JSON del envío de ventas:

{“IdEmpresa”:”SR10.002MX12345″,”Ventas”:[{“Estacion”:”NS-CLNT-MID81″,”Almacen”:”2″,”FechaVenta”:”2022-06-02T12:27:12″,”NumeroOrden”:”51795″,”IdCliente”:””,”IdUsuario”:”ADMIN”,”Total”:120.0000,”Area”:”DIDDI”,”Conceptos”:[{“IdProducto”:”01005″,”Descripcion”:”COMBO 2 PZAS/COMEDOR”,”Movimiento”:1,”Cantidad”:1.000000,”PrecioUnitario”:50.0000,”ImporteSinImpuestos”:43.1034,”Descuento”:0.000000,”Impuestos”:[{“Impuesto”:”IVA”,”Tasa”:0.16,”Importe”:6.896551}]},{“IdProducto”:”01006″,”Descripcion”:”COMBO 3 PIEZAS
/COMEDOR”,”Movimiento”:2,”Cantidad”:1.000000,”PrecioUnitario”:70.0000,”ImporteSinImpustos”:60.3448,”Descuento”:0.000000,”Impuestos”:[{“Impuesto”:”IVA”,”Tasa”:0.16,”Importe”:9.655172}]}],”Pagos”:[{“FormaPago”:”Tarjeta de Débito”,”Importe”:100.0000,”Propina”:0.0000},{“FormaPago”:”Efectivo”,”Importe”:20.0000,”Propina”:20.0000}]}]}

ANEXO B. Detalle técnico para la conexión al PMS:

El objetivo de esta sección es entender más a detalle el procedimiento y funcionamiento de nuestro sistema POS con su API, es necesario que el usuario técnico esté familiarizado con las peticiones HTTP POST, GET, y JSON POST.

Entornos.

Contar con un entorno de producción y un entorno de Pruebas QA, los entornos están definidos por la URL de dominio de los recursos, la siguiente tabla muestra un ejemplo.

Posteriormente a la URL de dominio se le debe concatenar el recurso de consulta.

https://pms-api-qa/{resource}

Por ejemplo, si tomamos el “resource”, para la consulta de una habitación, la construcción de la URL para solicitar la información será como se muestra a continuación.

https://pms-api-qa/rooms/{room_id}

Autentificación.

La autenticación se realiza agregando x-api-key en el header, el cual es un valor estilo {customerId}::{apiKey} este deberá ser brindado por el proveedor de la API. Esto es una recomendación, ya que, si el método de autenticación se realiza con otros parámetros, se puede considerar.

Requests.

Consultar habitación.

Obtiene información de la ocupación de una habitación del PMS

Realizar cargo.

Realizar el cargo habitación del consumo realizado en el POS

Cancelar cargo.

Cancela un cargo habitación desde el POS