22 de diciembre de 2011

Registros hoteleros personalizados


Los registros y pre-registros, para los huéspedes son una herramienta y en muchos casos una obligación a nivel corporativo o de ley. Su uso ayuda al hotel a formalizar el ingreso de los huéspedes y a tener un documento que finalmente puede servir como herramienta legal.

La diferencia radical entre el pre-registro y el registro es su punto de emisión, el primero se emite desde la reserva mientras el segundo desde la ventana de check-in. 

El pre-registro es un documento, que como su nombre lo indica, se presenta antes de registrarse, con el objetivo de facilitar y acelerar el check-in. Si desde la reserva tomamos la mayor cantidad posible de información del cliente, podremos tener el pre-registro listo e impreso para su llegada,  de tal forma que solo requiera llenar o corregir información y plasmar su firma. Finalmente al lograr este proceso el registro puede acelerarse.

En las ventanas de reserva y registro de huéspedes encontramos un botón para imprimir el pre-registro y registro hotelero respectivamente. En la de registro (y próximamente en la de reserva) al hacer clic sobre este botón despliegan (si se cumplen algunas condiciones) una serie de opciones para imprimirlos en diferentes formatos e incluso para seleccionar un formato personalizado.

En particular en este artículo nos interesa entender el porqué de los formatos personalizados y cuáles son sus ventajas. En primera instancia podemos considerar y pensar que el registro hotelero de un hotel es uno solo y que no parece haber razón para tener varios de ellos, pero si analizamos con más detalle podemos encontrar que existen situaciones que lo ameritan:

  1. Idiomas: si estamos en un hotel en el que recibimos extranjeros de varios países con idiomas diferentes al local, podemos considerar en tener un formato por cada idioma, de tal forma que el huésped se sienta cómodo con lo que lee y firma.
  2. Variaciones de condiciones: tener múltiples planes y diferentes segmentos de huéspedes nos puede llevar a contar con diferentes clausulas y muchas de ellas pueden no ser generales. Si partimos que el huésped al firmar el registro está firmando un contrato, podemos contar con múltiples tipos de registros para múltiples tipos de cliente.
  3. Walk-in, Individuales, Grupos y Empresas: las condiciones y presentaciones de los registros puede cambiar en razón de si estoy registrando un grupo o una reserva individual, o si es una empresa o un particular, o incluso tener un formato especial para los walk-in.


Estas pueden ser algunas de la razones para contar con múltiples formatos ajustados a nuestras necesidades. La ventaja es que como usuarios finales de Zeus podemos crearlos y usarlo a nuestro gusto, sin que haya un límite respecto al número de formatos que queramos dejar disponibles. Desde el módulo de parámetros en el menú procesos, podemos modificar los reportes, o crear reportes nuevos.

La recomendación para los reportes personalizados relacionados con los registros hoteleros es partir siempre del formato estándar y copiarlo para luego modificarlo y ajustarlo a nuestras necesidades.
Por defecto la emisión del registro hotelero no emite opciones, solamente emite el formato estándar sin dar opción de seleccionar, sin embargo si creamos dentro de la carpeta RDU* una subcarpeta llamada REGISTROHOTELERO y copiamos allí los formatos personalizados, el sistema nos dará la opción de seleccionar uno de ellos. Solo debemos tener la precaución de colocar solo formatos validos como registros para no tener inconvenientes o errores al emitir el informe.

En la versión 2012 de Zeus contaremos con esta misma funcionalidad para los pre-registros que imprimimos desde Reservas.

* RDU: Reportes de Usuario, carpeta especial ubicada dentro del directorio donde está instalado Zeus Hoteles (por defecto C:\ZeusSoftware\Front). Usada por los usuario finales para colocar sus formatos personalizados.

6 de diciembre de 2011

Generalidades Guest Service


Existe una tendencia muy clara en la actualidad hacia el autoservicio, que consiste básicamente en que el usuario pueda tener acceso a servicios sin la necesidad de que una persona del hotel le esté atendiendo directamente. La razón es que hoy día un gran porcentaje de las personas tiene la capacidad de interactuar con un computador, una tableta o un Smart Phone con total naturalidad, esto implica que si se le expone un sistema lo suficientemente intuitivo, el usuario podría acceder a funcionalidades de los sistemas que en el pasado solo podían ser operados por usuarios avanzados.

Guest Service es un producto pensado para autoservicio, con el que un huésped puede realizar un grupo importante de tareas relacionadas con Zeus Front, las cuales van desde consultas hasta pedidos para servicio al cuarto.

Podemos instalar este producto en varios dispositivos y en diferentes ambientes. Si pensamos en que el huésped pueda tener fácil acceso a sus funciones el lugar más adecuado es la habitación, donde podríamos tener un PC de escritorio, pero también una tableta y aún mejor un televisor con conexión a internet (Smart TV). En cualquiera de ellos el cliente podrá acceder a las mismas funciones.

Otra opción, que puede incluso ser complemento de la anterior, es dejar equipos en zonas comunes del hotel como el lobby –en una especie de kiosco por ejemplo-, para que los huéspedes se acerquen a él a realizar sus consultas y transacciones.

Finalmente podríamos dejar un sitio web público en la intranet al que el huésped pueda acceder desde su portátil o tableta personal y aprovechar las ventas del autoservicio; y aún mejor, el sitio podría ser expuesto a internet y el cliente podría ingresar y realizar las operaciones disponibles incluso estando fuera del hotel. Pensemos en un cliente que viene de una reunión fuera del hotel, y quiere llegar y tener su comida lista; podría entrar a Guest Services, mirar la carta de Room Service y pedir su plato preferido, todo mientras se desplaza en un taxi.

Entre las funcionalidades que ofrece Guest Service para los huéspedes están:


Consultas

  • Consulta de estado de cuenta
  • Consulta de las llamadas que ha realizado
  • Consulta de los mensajes que le han dejado con la operadora
  • Consulta de Objetos Olvidados que puedo haber dejado incluso en otra estadía
  • Consulta del estado de sus vouchers (de control de consumos


Transacciones

  • Colocar una queja
  • Solicitar un pedido a Room Service
  • Enviar un mensaje a un departamento o persona del hotel
  • Reporta su ubicación para el traslado de llamadas
  • Pagar su cuenta

El huésped solo tendrá que solicitar una clave de seguridad en la recepción para que pueda ingresar al sistema y así garantizar la privacidad de sus datos, y realizar con confianza sus consultas y transacciones.

Las funcionalidades de Guest Service seguirán en evolución, pronto veremos a los huéspedes haciendo check-in y check-out por sí solos, y a los clientes de los restaurantes pidiendo sus platos sin llamar al mesero.

Guest Service viene en 2 versiones: una web disponible para cualquier navegador y otra instalada en un equipo (Windows). La versión web tiene básicamente funcionalidades para el huésped, mientras que la Windows ofrece otras opciones para seguimiento, las cuales veremos en otro post.

22 de noviembre de 2011

Tarjeta de Bienvenida o Despedida En Check-In y Check-Out

En este artículo explicaremos las características que ofrece el sistema para configurar las tareas automáticas de envío de correos luego de un proceso de check-in o check-out.

Los correos enviados normalmente corresponden a bienvenidas cuando el huésped hace el check-in, y a agradecimientos cuando hace check-out.

En el correo puede adjuntarse una imagen, enviar texto y adjuntar un archivo HTML si se requiere.

La siguiente información detalla la paremetización que debe llevar a cabo para activar el envío de correo, tenga en cuenta que además de está, debe haber un proceso previo de montaje de la opción de envío de correo por parte de un funcionario de Zeus tecnología.

PARÁMETROS BÁSICOS PARA CORREOS DE CHECKIN Y CHECKOUT
Se puede disponer de carpetas con las imágenes y archivos de configuración para el envío de dichos correos, de acuerdo al lenguaje que se requiera. Si no se quiere especificar una imagen distinta para alguna nacionalidad de cliente, simplemente el sistema asumirá siempre por defecto la ruta que se especifique en los parámetros de Ruta de Imagen y Ruta de Imagen Check-in que miraremos más adelante.

Para realizar la indicación de las rutas para las imágenes y archivos de configuración se ha  habilitado una nueva opción ubicada en el maestro de Países del módulo “Parámetros”. En esta ventana encontraremos el botón “Restricciones a Paises”, en la barra de herramientas.

Cuando se da clic a esa opción se podrá entonces determinar las rutas asociadas para el Check-in y Check-out, en la ventana “Asignación de Países” que se despliega. Simplemente debemos indicar el tipo de evento (CHIN o CHOUT) y la ruta que le corresponde en el servidor a la imagen.

Al momento de realizarse el envío de los correos se verificará entonces que si la nacionalidad del cliente tiene especificada esta restricción, entonces en vez de irse a buscar la ruta del parámetro de la tabla hotel buscará la ruta que indique dicha restricción.


ESTABLECIMIENTO DE PARÁMETROS DE CONFIGURACIÓN DEL ENVÍO DE CORREOS
Se deberá realizar la configuración de los parámetros requeridos para el funcionamiento del envío de correos de agradecimiento a huéspedes que realicen Check-Out y/o Check-In.
Para esto se debe ingresar al módulo “Parámetros” en la opción “Definición de Parámetros - Hotel” del menú “Procesos”:

Dentro de esta opción, encontrará 5 parámetros así:
1. CORREO ELECTRÓNICO: e debe configurar la dirección de correo electrónico del hotel desde donde se enviará el correo de agradecimiento al cliente-
2. CONTRASEÑA CORREO: Se debe especificar la clave de validación de la dirección de correo especificada anteriormente:
3. SERVIDOR DE CORREO DEL HOTEL (SMTP): En este parámetro se indicará el servidor de correo SMTP (Simple Mail Transfer Protocol) que utiliza el hotel para el envío de correos:

Estos tres parámetros anteriores son indispensables para el envío del correo al cliente.
Adicionalmente, existe un cuarto y quinto parámetro que permite enviar una imagen en el cuerpo del mensaje.
4. RUTA TARJETA (Check Out): Indicar la ruta física de una imagen que se incluirá en el correo que se enviará al cliente cuando este hace Check Out. Esta ruta hace referencia a una carpeta en el servidor donde se encuentra instalada la base de datos SQL de Zeus Hoteles.
5. RUTA TARJETA (Check In): Indicar la ruta física de una imagen que se incluirá en el correo que se enviará al cliente cuando este hace Check In. Esta ruta hace referencia a una carpeta en el servidor donde se encuentra instalada la base de datos SQL de Zeus Hoteles.

Estos parámetro (4 y 5) tiene una doble función. En primera instancia sirve para indicar la ruta física de una imagen que se incluirá en el correo que se enviará al cliente cuando este hace Check-Out y/o Check-In. En segundo lugar permite que se tome como referencia ese directorio donde se encuentra el archivo de imagen para buscar el archivo de configuración (CONFIGURACIONCORREO.cfg) que permite personalizar el Asunto del mensaje y el Texto del Cuerpo del mensaje. Más adelante se explicará cómo se utiliza este parámetro para poder omitir el envío de una imagen y para poder personalizar el cuerpo del mensaje a enviar. La imagen a incluir puede ser de cualquiera de los formatos comunes de imagen (jpeg, tiff, gif, png).


CREACIÓN DE JOB PARA EJECUCIÓN DE LA TAREA DE MANERA PROGRAMADAPara que el sistema pueda enviar automáticamente el correo luego de terminado un check-in o un check-out, se debe crear un trabajo en el servidor SQL de Zeus Hoteles, que se mantenga revisando tales eventos y tome las acciones correspondientes.
Para que el envío de correos se realice de manera automatizada, se deberá entonces crear un JOB (trabajo) en el servidor que se ejecute una vez al día y que envíe el correo de agradecimiento a aquellos clientes que realizaron Check-Out el día anterior y/o Check-In desde Ayer que no se le ha mandado el correo.
Se dispone de un archivo con un script que se encarga de realizar la creación del JOB (“Script Crear Tarea.sql”). Se debe tener en cuenta que en dicho script se deberá realizar el cambio del Nombre de la Base de Datos para que el procedimiento almacenado que se encarga del envío de los correos se ejecute de manera correcta.
El script de que se dispone realiza la creación del JOB indicando una programación diaria a las 02:00 am. Sin embargo, se puede realizar el proceso de cambio de esta programación a partir del Management Studio de SQL. Allí se podrá ver que el Agente SQL contiene dicho trabajo y con la acción de doble clic se pude pasar a modificar o inactivarlo:


CONFIGURACIÓN/PERSONALIZACIÓN DEL MENSAJE A ENVIAR
Por defecto, si no se indica una ruta de archivo de imagen, el sistema enviará un mensaje estándar que incluirá un texto base para el Asunto (Agradecimiento por su Visita.) y un texto base para el cuerpo del mensaje (Nuestro hotel le agradece por su estadía.)
Si se quiere indicar un mensaje personalizado para el correo a enviar al cliente, se podrá configurar entonces un texto particular para el Asunto del correo, y un texto particular para el Cuerpo del correo.
Para realizar dicha personalización se deberá entonces usar el archivo de configuración CONFIGURACIONCORREO.cfg. Dicho archivo contiene dos secciones, que corresponden precisamente a esos dos textos personalizables: Asunto y Cuerpo del Mensaje.

El texto comprendido en la sección de Cuerpo del Mensaje se basa en HTML, por lo cual se podrá incluir Tags de HTML para poder realizar inclusión de retornos de carro, aplicación de fuentes y colores al texto, o incluso la adición de listas o tablas al mensaje.
Por ejemplo, se tiene el siguiente archivo de configuración que envía el mensaje con letra de color azul, y con una separación marcada entre párrafos:
[ASUNTO]Tarjeta de agradecimiento visita al hotel
[CUERPOMENSAJE]<font face=”times new roman”> <font color=”blue”>
Agradecemos su amable estadía en nuestro hotel. <p>
Esperamos su pronta visita.<p>
Cordialmente, <br>
Administración del Hotel. </ ont> </ ont>
Se debe tener en cuenta que este archivo de configuración debe tener las secciones correctamente identificadas, de lo contrario no se podrá enviar el correo. La estructura del archivo se deberá mantener tal y como se encuentra (las palabras [ASUNTO] y [CUERPOMENSAJE] deberán estar siempre y deben ir seguidas de un cambio de línea).
El archivo de configuración se deberá ubicar en la misma ruta que se indicó para la imagen en el parámetro de Hotel que se explica al comienzo de este documento (Parámetro 4 ó 5). De allí radica la importancia de indicar una ruta y nombre de archivo en dicho parámetro. Si no se quiere usar el envío de una imagen en el cuerpo del mensaje se puede colocar un nombre de archivo inexistente, pero es importante que se disponga de ese nombre para poder tener acceso a la ruta donde se ubicará el archivo de configuración que es el que permite personalizar el mensaje a enviar al usuario.
Cuando se quiera usar la imagen incluida en el cuerpo del documento, solo se deberá entonces colocar un nombre válido de imagen (con la ruta completa y extensión del archivo), y asegurarse de que esté correctamente indicada en el correspondiente parámetro de la Ruta de la Tarjeta.
En el ejemplo mostrado inicialmente (Parámetro 4 RUTA TARJETA (Check Out)), se indica que en el directorio raíz C se incluirá una imagen con el nombre Zeus.jpg, y allí mismo se incluirá el archivo de configuración CONFIGURACIONCORREO.cfg, específicamente a modo de ejemplo se ubicará el que se modificó para que se envíe el mensaje con texto azul y separación de párrafos. El resultado del mensaje enviado sería el siguiente:
Imagen de la ubicación de los archivos en el servidor:

El siguiente es un ejemplo de un correo generado por el sistema luego de un check-out.



La ruta del archivo puede verse afectada por la nacionalidad relacionada al huésped, dado que es posible adjuntar diferentes archivos por cada uno de ellos. Si no se especifica se tomará el valor por defecto antes mencionado.
En el maestro de países, a través del botón “Restricciones a Países” (En la ventana desplegada) podrá indicar la ruta del archivo para el envío del correo de check-in y check-out en el país seleccionado.




18 de noviembre de 2011

Contabilizazión POS-Hotel Separada

El manejo de múltiples contabilidades para Zeus Front tiene varios aspectos para analizar, en especial si tenemos en cuenta cuál de las estructuras vamos a usar.

La forma más sencilla de manejo de múltiples contabilidades es la que se aplica al separar los movimientos de POS de los de Hotel. En este caso tenemos básicamente 2 contabilidades para registrar los movimientos generados por los movimientos relacionados con AyB, y otra para los demás tipos de movimiento. Otro modelo más complejo permite tener una contabilidad para cada complejo del hotel o bien una para cada ambiente de POS.

En esta oportunidad analizaremos el primer caso, la forma como se configuramos, parametrizamos y aplicamos este modelo de contabilización.

   
El modelo que tenemos es el siguiente:







Cómo funciona la contabilización estándar?

Recordemos alguna generalidades de la generación de movimiento de Zeus front. Podemos separar los movimientos generados en 3 tipos básicos (aunque en la práctica son más): Ingresos, impuestos y pagos. Esta separación no es exclusiva para la contabilización separada, de hecho aplica para cualquier tipo de movimiento contable realizado por el sistema. Tanto para POS como para Hoteles.

En hotel:
La generación de movimiento contable en de los cargos en Hotel tiene como principal protagonista la “Cuenta Saldo Huéspedes en Casa” (SHC). Recordemos que esta cuenta sirve de puente para cualquier registro contable; finalmente la cuenta huésped es la contrapartida de cada uno de los 3 tipos movimientos básicos, además como su nombre lo indica esta cuenta nos muestra el saldo pendiente (a favor o en contra) de un folio específico.

Por ejemplo si se carga un alojamiento a una habitación, el sistema contablemente generará un crédito a la cuenta de ingreso de alojamiento, contra un débito a SHC. Lo propio hará con su respectivo impuesto. En este momento el saldo contable en la cuenta SHC será lo que el cliente nos debe. Cuando se realice el pago del alojamiento, el sistema hará un débito a la cuenta contable asociada al pago (por ejemplo caja) y un crédito a SHC. Desde luego el débito (positivo) registrado por el alojamiento menos el crédito (negativo) del pago hará que el valor de SHC finalmente sea cero.


En POS:
Hay algunas diferencias en POS respecto al manejo de SHC, debido a que solo es utilizada cuando cargamos un cheque-cuenta  a un folio, para el resto de los movimientos no aplica su uso. Por ejemplo si hacemos una venta de contado, el sistema registrará un crédito a la cuenta de ingreso del producto, otro crédito a la del impuesto y un débito a la cuenta de caja asociada a la forma de pago; la razón es que no tenemos en este caso un saldo por cobrar, el pago se dio de forma inmediata.

Cada uno los movimientos para Hotel y POS se generan en el módulo correspondiente, Auditoría y POS Admin respectivamente, y terminan siendo un comprobante contable en el sistema de contabilidad. Sin embargo lo más importante en el estándar es que tengo una única cuenta para SHC.



Cómo funciona la contabilización con contabilidades separadas?

En términos generales el concepto es el mismo desde el punto de vista contable, es decir, existen los mismos tipos de movimientos y seguimos manejando SHC, también generamos movimientos para cada módulo y tenemos al final un comprobante contable. Entonces cual es la diferencia?

Cuando manejamos dos contabilidades para POS y Hotel, la premisa es que los huéspedes son responsabilidad del hotel, y por tanto es el hotel quien maneja el saldo. Es algo así como pensar que los puntos de ventas son de terceros, y por no ser del hotel, a ellos no es a quien les debe el huésped.

Mirémoslo con un ejemplo: un hotel tiene contratado un restaurante con una empresa X, el cual es el encargado de dar la alimentación a los huéspedes. Obviamente el huésped no conoce esto, para él es un restaurante del hotel. Sin embargo la realidad es que el restaurante vende al hotel y este a su vez al cliente, lo que implica que finalmente es el hotel quien paga al restaurante lo que vende a los huéspedes. Esto necesariamente nos lleva a concluir que el dinero por cobrar a los huéspedes que consumen  en el restaurante, hablamos de “Saldo de Huéspedes”, es una responsabilidad del hotel; obviamente las ventas de contado no son de interés del hotel, eso lo cobra directamente el restaurante.

Habiendo aclarado esto, podemos hablar de las diferencias y coincidencias respecto al movimiento estándar, pero antes que tenemos que entender es cómo el sistema determina que información debe enviar a cada contabilidad. Son tres reglas muy sencillas:

1.      Todo producto cargado desde los puntos de venta son enviados siempre a la contabilidad de AyB

2.      Todo cargo definido como tipo alimentación y que ha sido cargado a un folio, es por defecto enviado a la contabilidad de AyB

3.      Todo cargo no definido como Alimentación se envía a la contabilidad del hotel.


Partiendo de estas reglas podemos analizar el proceso que sigue el sistema para el registro de movimientos:

1.      Los movimientos registrados en Hotel y que No tienen que ver con AyB, son registrados de la misma forma que el estándar.

2.      Los movimientos registrados en POS y que No tienen que ver con huéspedes, son registrados de la misma forma que el estándar

3.      Los movimientos registrados en Hotel y que SI tienen que ver con AyB, generan una cuenta por pagar del hotel al POS.

4.      Los movimientos registrados en POS y que SI tienen que ver con huéspedes, generan una cuenta por Cobrar al hotel.

5.      Solo existe cuenta de SHC en la contabilidad del hotel.


Que pasa entonces cuando un huésped un producto en POS o se le hace un cargo de AyB en Hotel, que movimiento contables se genera?
En la contabilidad de POS queda un registro crédito en la cuenta de ingreso y otro en la cuenta de impuestos, contra un débito en una cuenta por cobrar al  hotel.

Por su lado en la contabilidad de POS queda un registro crédito en una cuenta por pagar al restaurante, contra un débito en SHC.

El resto de los movimientos se comportan de forma normal.

  
Como configuramos el sistema para que maneje 2 contabilidades?
Este proceso tiene 2 tipos de configuración que realizar, la primera es desde el sistema y la segunda es muy técnica (se realiza  a nivel de base de datos). Para la primera necesitamos simplemente un usuario con permisos, para la segunda el soporte de personal de Zeus Tecnología para que nos ayude a configurar el sistema (aunque vamos hablar un poco de esto, no vamos a entrar en detalles muy técnicos).

Como lo hacemos:

1.      Configuración de los parámetros del sistema: lo parámetros que debemos cambiar los encontramos en “Parámetros/Procesos/Definición de Parámetros Especiales”. Son:

a.      “Contabilización POS Separada”: debemos cambiar su valor a “S”. Esto indica que se maneja una contabilidad para POS y otra para Hotel

b.      “Código CXC para contabilidades separadas”: ingresamos la cuenta contable correspondiente a la cuenta por cobrar que afectaremos en POS.

c.      “Código CXP para contabilidades separadas”: ingresamos la cuenta contable correspondiente a la cuenta por pagar que afectaremos en Hotel
d.      “NIT CXP para contabilidades separadas”: ingresamos el NIT (del restaurante) que enviaremos al afectar la CXP de Hotel.


2.      Configuración técnica: Parte de esta configuración consisten en modificar los procedimientos encargados de transferir la información a las contabilidades (conocidos como validadores) y las vistas que relacionan Front con contabilidad. Como mencionamos antes esto es a nivel de base de datos y de características muy técnicas. En todo caso lo que hacemos es colocar  para cada caso la ruta correcta de cada base de datos, de forma que POS quede direccionada a la contabilidad de AyB y lo propio para hotel. Las vistas que debemos revisar para este proceso son:

a.      MAECONT_MCA (Hotel)

b.      TERCEROS_MCA  (Hotel)

c.      DOCUMENT_TEMP_MCA  (Hotel)

d.      TRANSAC_TEMP_MCA  (Hotel)

e.      MAECCO_MCA  (Hotel)

f.       PS_MAECONT_MCA (POS)

g.      PS_TERCEROS_MCA (POS)

h.      PS_DOCUMENT_TEMP_MCA (POS)

i.       PS_TRANSAC_TEMP_MCA (POS)

j.       PS_MAECCO_MCA (POS)



 
Cómo realizamos la generación de movimiento contable?
 En este sentido los cambios son pocos, hay dos condiciones necesarias:


1.      Siempre debemos genera el movimiento de Hotel antes que el de POS. Cuando generamos hotel, se generan unas cuentas puentes, y si consultamos los valores podríamos encontrarlo descuadrado. Esto se debe a que falta el cruce con POS.
2.      Siempre debemos generar el movimiento en parejas antes de revisar. Es decir, no debemos iniciar revisión de ningún tipo hasta que los dos movimientos no se hayan generado (uno después del otro). Dado que los dos comprobantes se cruzan información, como explicamos antes, no estarán listos hasta que no generemos los dos. Luego de generados los dos podemos entrar a iniciar la revisión.

El proceso de revisión de los valores de ingresos, impuestos y pagos es igual al estándar, se usan los mismos informes y se validan de la misma forma. El único cambio en el proceso de revisión se presenta en la revisión de los cuentas por cobrar y pagar, la cuales podemos verificar comprobando  que en efecto corresponden a los valores de AyB cargados a huéspedes. En POS Admin podemos usar el listado de pagos por forma de pago para conocer los valores cargados a folios de habitación y de eventos, mientras que en Hotel podemos usar el listado de cargos para verificar que cargos de AyB fueron reportados desde cargos a folios.

De la misma forma la importación del movimiento desde Zeus Contabilidad no tiene variaciones. Podremos importar los comprobantes generados bajo las mismas características.

Si en algún momento se requiere revertir un movimiento en contabilidad para regenerarlo, debemos revertir su pareja, para poder nuevamente generar POS y Hotel juntos para el día que corresponda.

16 de noviembre de 2011

Imágenes en los Pagos Preferidos

A partir de la versión 4 de Zeus POS touch contamos con la opción de definir pagos y productos preferidos, esta nueva característica nos permite cargar productos y registrar pagos con mayor rapidez. Un solo clic es suficiente!

Al igual que todos los botones de productos y pagos estos nuevos botones nos permiten asignar imágenes. Para realizar la parametrización de las imágenes de los productos no hay variación, es decir, deben estar dentro de la carpeta "Imagenes" teniendo como nombre del archivo el código del producto. Para los pagos preferidos debemos realizar lo siguiente:


• En la carpeta donde se encuentra el exe de POSTOUCH, ubicamos una carpeta llamada “Imagenes”.

• Dentro de la carpeta llamada “Imagenes”, ubicamos una carpeta llamada “PagosPreferidos”. Si la carpeta “PagosPreferidos” no existe, entonces procedemos a crearla.

• En la carpeta de “PagosPreferidos”, copiamos las imágenes de las formas de pago, nombrándolas de la siguiente manera:

“1_codigo de forma de pago”, por ejemplo:

▪ para la forma de pago efectivo: 1_efe

▪ para la forma de pago visa: 1_vid


Recordemos que para efectivo podemos además contar con las diferentes denominaciones, en este caso, el nombre de la imagen debe ser:

1_codigo forma de pago efectivo-valor

por ejemplo

• efectivo de 5000: 1_efe-5000

• efectivo de 1000: 1_efe-1000

• efectivo pago completo: 1_EFE-PAGO COMPLETO

Recordemos que en todos los casos la extensión de los archivos de las imágenes deben ser JPG.

15 de noviembre de 2011

Reducir el LOG de una Base de datos SQl 2008

Muchas veces nos ha ocurrido tener un archivo muy grande de transacciones y no poder reducirlo por diferentes problemas:

ñ Espacio en disco no disponible para hacer un backups del log

ñ No tener tiempo suficiente

ñ Fallo al hacer el backup del archivo de transacciones.

ñ No poder para la BD

Existe una forma muy sencilla y que no tardamos nada en hacerlo y además funciona perfecto, solo aseguraté que hayas hecho un backups completo de la base de datos antes de hacer.

 Los pasos son:

1. Ingresar a Microsoft SQL Management Studio
2. En el explorador de Objetos buscar la base de datos que deseamos reducir
3. Hacer Clic derecho sobre la base de datos y seleciona la opción propiedades del menú contextual
4. En la ventana desplegada seleccionamos la pagina Opciones del panel derecho
5. En el campo "Modelo de recuperación" nos aseguramos de seleecionar la opción "Simple"


Habiendo aplicado estos pasos podemos proceder a reducir la base de datos:
1. Clic derecho sobre la base de datos y seleccionamos la opción "Tareas/Reducir/Archivos"
2. Marcamos la opción "Liberar espacio no utilizado"

Ahora el proceso de reducción (shrink) se aplica satisfactoriamente.

Al terminar debemos coloca el "Modelo de Recuperación" en su valor original

Un aporte de Yonnathan Mosquera

5 de noviembre de 2011

Inconsistencias tipo Generación

En términos generales la generación de cargos toma todas las habitaciones registradas, verifica el plan y según el número de personas y el paquete, prepara cada uno de los cargos que serán registrados en la cuenta del huésped. Esta lista de cargos es almacenada por el sistema y mantenida hasta la próxima generación de cargos.

Una inconsistencia comúnmente encontrada durante el proceso de auditoría, son las inconsistencias tipo Generación, se les conoce con este nombre porque todas inician por la palabra “Generación --”. Todas las inconsistencias de este tipo hacen referencia a la información encontrada dentro de la lista de cargos generados, y pueden referirse a incosistencias en valores, números de habitación, folio y otras condiciones relacionadas con estos.

Entre las inconsistencias de este tipo se encuentran: 
  • GENERACION -- FOLIO CON FACTURA GENERADA
  • GENERACION -- FOLIO CON REMISION GENERADA
  • GENERACION -- FOLIO CHECKOUT
  • GENERACION -- FOLIO EN ESTADO SUSPENDIDO

Ante la presencia de estas inconsistencias comúnmente podemos encontrar que por ejemplo el estado actual del folio y el reportado por la inconsistencia no coinciden, o en su lugar no parece haber una solución para aplicar directamente al folio

Estos casos se deben en su mayoría a que los cargos generados no están actualizados con los últimos cambios en los folios. Por ejemplo, suponga hace 1 hora generamos cargos cuando teníamos 50 habitaciones check-in, pero hace unos minutos hicimos check-out a una de ellas. Si se emite las inconsistencias luego del check-out el sistema le informara: "GENERACION -- FOLIO CHECKOUT".

En su mayoría las inconsistencias tipo generación se eliminan de la lista con solo volver a generar cargos. En el módulo Auditoria, seleccionamos el menú "Cargos/Generación de Cargos General" y hacemos clic en el botón "Generar", el sistema nos informará que existen inconsistencias y nos pregunta que si deseamos continuar con la generación, debemos hacer clic en el botón "Si".

El sistema procederá a generar los cargos de forma normal, y nos dará la opción de imprimir los cargos generados mostrándonos una ventana (la verdad no necesitamos verlos, podemos hacer clic en el botón "Salir"). Ahora podemos volver a generar las inconsistencias, podremos verificar que ya no están las inconsistencias tipo "Generación".

1 de noviembre de 2011

Lista de Espera

La lista de espera de Zeus Hoteles tiene varias variaciones en su comportamiento basados en los parámetros definidos.

Por defecto la lista de espera está relacionada con un parámetro del módulo de Parámetros (Procesos/Definición de Parámetros de Hotel) llamado "LISTA DE ESPERA". Este parámetro puede contener dos posibles valores:

a.      S: genera lista de espera automática sin pedir autorización. Es decir que todo lo que se sobrevenda pasa a lista de espera directamente

b.      N: no genera lista de espera automática, en su lugar el sistema solicitará una clave de sobreventa. Si se provee una clave válida se hará la reserva, de otra forma será cancelada automáticamente.

Estos valore de la lista de espera aplican a nivel global, en todos los proceso de reserva e incluso durante el check-in y alargues de estadía  (en caso de sobreventa permite registrar solo si se da la clave). Sin embargo es posible hacer excepciones manejando un nivel inferior en el parámetro, específicamente a nivel de oficina y para el caso específico de las reservas.
En el maestro de oficinas se puede establecer que el manejo de lista de espera no se aplica según lo indicado por el parámetro general y que en su lugar tiene otro comportamiento. Los posibles valores del campo “Lista de Espera” son:
  • Según Parámetro General: respeta la configuración del parámetro general del sistema
  • Con Autorización: siempre pide autorización al sobrevender
  • Sin Autorización: nunca pide autorización y deja sobrevender
  • No pude generar: siempre que se genere sobreventa se cancelará la reserva sin preguntar
 
Con el uso de esta funcionalidad podemos dar flexibilidad al manejo de la sobreventa, especialmente teniendo en cuenta que por defecto podemos asignar una oficina a un usuario y restringirlo para que no pueda cambiarla.
Si a este posibilidad le sumamos que para cada oficina puedo restringir el número de habitaciones disponibles, podemos lograr un control aún mayor de las ventas por oficina.  Para este uso debemos tener en cuenta el campo “RESTRINGE TIPOS DE HABITACION” el cual habilita las opciones para poder ingresar topes de habitación por cada tipo, de tal forma que el sistema controlara las ventas que se generen por encima de la cantidad autorizada, aun cuando en el hotel existan más habitaciones, en otras palabras puede que el hotel tenga 50 habitaciones tipo Suite, pero podemos indicar que la oficina “Satelite” solo puede vender 20 de esas 50.

El control se hace según lo que definen los parámetros para manejo de lista de espera. Al activar esta casilla debe ingresar:
TIPO A RESTRINGIR. Código del tipo de habitación sobre el que se quiere indicar una cantidad de habitaciones para vender menor a la disponible

CANTIDAD A RESTRINGIR. Indica cuantas habitaciones podrá vender del tipo seleccionado

Cambiar Nombre Instancia SQL Server

Luego de haber instalado SQL Server podemos cambiar el nombre de la instancia y evitarnos así la necesidad de reinstalar.

SQL server cuenta con una herramienta que permite hacer el cambio ubicada en la carpeta de instalación de SQL, comunmente en: C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE

El nombre del archivo es ASInstanceRename. Al presionar doble clic se despliega una ventana solicitando el nombre de la instancia que vamos a cambiar, el nuevo nombre, el usuario y la clave que usaremos para el cambio:

TerminoDefinición
Instancia a RenombrarSeleccione la instancia que va a cambiar de nombre.
Nuevo nombre de instanciaEscriba el nombre de la instancia que desee. No incluya el nombre del servidor. Es decir, en lugar de entrar <nombre \ <nombreDeInstancia>, escriba sólo <nombreDeInstancia>.
Si desea que la instancia que está el cambio de nombre a la instancia predeterminada, deje en blanco el nombre.
Nombre de usuarioMuestra la cuenta que el servicio utiliza para iniciar. El nombre de usuario no se puede cambiar.
ContraseñaEscriba la contraseña de la cuenta de servicio.


Este proceso lo debemos ejecutar directamente en el servidor y debemos tener en cuenta que no podemos usar herramientas de SQL 32 para cambiar el nombre de una instancia de 64 bits.

25 de octubre de 2011

Intercalación de SQL Server


Uno de los inconvenientes que se presentan durante la instalación de los sistemas ZEUS® suelen ocurrir en la configuración de la base de datos. Existen varias características importantes que se deben recordar en el proceso de instalación del motor MS-SQL, entre ellas la intercalación.



Que es la intercalación?

Técnicamente hace referencia a la forma como se representa y almacena cada carácter, y en consecuencia también se refiere a las reglas utilizadas para ordenar y comparar caracteres.

Podríamos decir que es una propiedad que define los estilos de ordenación, comparación de texto y la forma como se almacena y leen en la base de datos.  Evidentemente, se trata de un concepto que afecta sólo a los campos de texto.

La intercalación define además si el motor de SQL distingue mayúsculas y minúsculas o si trata las vocales acentuadas igual que las no acentuadas.



Porqué es importante colocar la correcta?

Pensemos inicialmente que la intercalación es como en un mapa de caracteres, donde cada carácter tiene una posición y hay un número de posiciones disponibles. En la intercalación latina una posición puede estar asociada a la ñ mientras que la asiática estar asociado a caracteres chinos lo cual permite que los latinos veamos la ñ mientras los asiáticos sus caracteres sin gastar demasiado espacio. Desde luego si tenemos una base de datos asociada a la latina pero la restauramos en una instancia predefinida como asiática, tendremos problemas.



Como saber que intercalación tenemos instalada?

Empecemos por anotar que la intercalación se da no solo a nivel de instancia de SQL, también a nivel de base de datos e incluso a nivel de columna. La forma clásica de verificar que intercalación tenemos instalada es usando el explorador de objetos del “SQL Management Studio” y hacer clic derecho sobre el nombre del servidor o de la base de datos y seleccionar del menú contextual la opción “Propiedades”, para ver la intercalación del servidor y de la base de datos respectivamente. Sin embargo también podemos hacerlo usando comandos:

Servidor: SELECT SERVERPROPERTY('collation')

Base de datos: SELECT DATABASEPROPERTYEX('Zeus', 'Collation')



La intercalación requerida por Zeus es: “Orden alfabético, no distingue mayúsculas de minúsculas,para utilizar con el juego de caracteres 1252” que en las propiedades se ve como SQL_Latin1_General_CP1_CI_AS



Podemos cambiar la intercalación?

Luego de terminar instalar un servidor SQL podemos encontrar que la intercalación requerida no quedo instalada. Muchos prefieren desinstalar e instalar nuevamente con la intercalación correcta, sin embargo es posible cambiar la intercalación.

Para cambiar la intercalación existen comandos que se ejecutan desde la línea de comandos, o bien usando un archivo .BAT si lo prefieres. Lo siguientes muestran como colocar la intercalación requerida por Zeus

Para SQL Server 2008:

D:\ Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=NombreDeLaInstancia /SQLSYSADMINACCOUNTS= "BUILTIN\ADMINISTRATORS" / SAPWD= ClaveDelsa /SQLCOLLATION= SQL_Latin1_General_Cp1_CI_AS



Para SQL Server 2005:

start /wait D:\setup.exe /qb INSTANCENAME= NombreDeLaInstancia REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD= ClaveDelsa SQLCOLLATION= SQL_Latin1_General_Cp1_CI_AS

* D:\ : hace referencia a la unidad donde se encuentra el instalador de SQL.



Es preferible hacer backup antes de hacer todo este proceso, y tener algunas precuauciones. Para más detalles recomiendo leer este artículo: http://microsoftsqlsecret.fullblog.com.ar/como-modificar-la-intercalacion-collation-en-sql-server.html






24 de octubre de 2011

Planes Comply y House Use

Planes Comply y House Use.


Es común encontrar que en los hoteles existen planes especiales que por su objetivo no suman en las estadísticas de ocupación, el principal motivo es porque no son considerados como una venta y en consecuencia no deben cambiar valores de indicadores como la tarifa promedio o el Revpar.
 

Cuando creamos planes Complimentary y House Uso (uso de casa), debemos asegurarnos que estén relacionados en los parámetros como planes de estos tipos, de esta forma el sistema aplicará los controles necesarios para que las estadísticas se acumulen adecuadamente. Además de no afectar las estadísticas de ocupación, esta parametrización permite que:
 

1.     No se pueda hacer un cargo manual de alojamiento: el sistema tampoco suma los valores por venta de alojamiento de planes comply y HU, asegurar que no se hacen cargos de este tipo evita que se presenten diferencias en los informes.

2.     No se pueda colocar una tarifa: de tal forma que las habitaciones registradas bajo estos planes no carguen durante el proceso de auditoría nocturna. Si se coloca un valor de tarifa habrá una inconsistencia.
 

Desde el módulo Parámetros, en el menú “Proceso/Definición Parámetros Hotel”, podemos ubicar los parámetros “Plan Complimentary” y “Plan House Use”. Estos parámetros son tipo cadena, lo que implica que podemos agregar varios de ellos para armar una lista de planes que queramos incluir para cada parámetro.


19 de octubre de 2011

Comprobante informe diario y pagos

Incorrecto comparar el informe de pagos por forma de pago con el informe comprobante diario.

No son dos informes que se puedan comparar, porque los datos que muestran difieren respecto al objetivo de cada uno.

El informe de pago por forma de pago, muestra todo el dinero recibido para una fecha indicada, sin importar si fue un abono, un pago para una factura o incluso un depósito.

 Por su parte el informe comprobante diario, muestra solo el dinero relacionado con las facturas emitidas, sin importar cuando fue pagado el valor.

En este orden de ideas yo puedo recibir una abono hoy a un folio y no generarle factura, y por tanto No saldrá en el comprobante informe diario. De la misma forma yo puedo generar hoy una factura que hace tres días cuando hizo check-in pago toda la estadía, y ese pago no saldrá en el informe de pagos por forma de pago.

En este mismo sentido tampoco se pude comparar el comprobante informe diario con la contabilización estandar de Zeus, debido a que tanto POS como Hotel suben a contabilidad todo los servicios y productos cargados (con impuesto) hayan o no sido facturados.

18 de octubre de 2011


 Reclasificacion de Terceros


Importante:

Para reclasificar los ingresos generados para un día se debe haber generado y subido a Zeus Contabilidad los movimientos contables de Hoteles y POS. Es igualmente importante que no haya espacios por generar, en otras palabras que todos los días hasta la fecha que está reclasificando estén generados y contabilizados.

El proceso de reclasificación de terceros se basa en los movimientos contables que ya han sido generados en el sistema y en las facturas del día que se está reclasificando, lo que hace es buscar las facturas del día y tomar los cargos allí facturados para verificar, en los movimientos contables de la fecha y día anteriores, con qué número de identificación fueron contabilizados, luego  los compara contra el número de documento con el que fueron facturado. De haber diferencia entre los documentos de causación de ingreso y el de facturación, el sistema genera movimientos contables débitos y créditos a la misma cuenta contable y afectando el tercero correspondiente.

Por ejemplo, si para el día 1º se cargó a la cuenta del cliente identificado con el número 73641757, un servicio por $10.000 de ingreso y $1.600 de IVA, al generar el movimiento contable el resultado será

Cuenta
Tercero
Crédito
Débito
41050501
73641757
10.000

24010501
73641757
1.600

13050501


16.000



Si al facturar los servicios se cambia el documento para la factura y se genera al cliente 800275252, la reclasificación generará el siguiente movimiento

Cuenta
Tercero
Crédito
Débito
41050501
73641757

10.000
24010501
73641757

1.600
41050501
800275252
10.000

24010501
800275252
1.600




Estos movimientos no varían el ingreso o los impuestos, pues su suma es cero, pero si garantiza que los valores queden reflejados al tercero correcto.





Parámetros previos

Para que las opciones de reclasificación estén disponibles es necesario indicar la fuente de reclasificación. Esta fuente debe ser diferente a la fuente para el comprobante estándar, de lo contrario habrá serios inconvenientes.
Indique la fuente para reclasificar desde los parámetros especiales:Modulo Parámetros/Procesos/Definición de Parámetros Especiales, parámetro "Fuente reclasificación terceros"
 

No todos los contabilizadores están habilitados para la reclasificación por tanto  debe tener actualizado el sistema con los últimos contabilizadores (mínimo de noviembre de 2009). Recuerde que normalmente en las actualizaciones no se colocan los contabilizadores, por lo tanto no tome como referencia la última actualización del sistema hotelero.

Desde luego todos los parámetros normales para generación del comprobante deben estar definidos, de hecho el sistema debe estar generando movimiento de forma normal con los nuevos contabilizadores.

Si no tiene los últimos contabilizadores necesitará generar durante varios días con los nuevos antes de poder reclasificar. Cualquier movimiento realizado con contabilizadores anteriores no se reclasificará adecuadamente.



Como generar los movimientos para Reclasificar

La reclasificación sigue los mismos pasos del comprobante de contable estándar; básicamente se genera movimiento, se revisan terceros y se transfiere a contabilidad. Para esta tarea existe un botón en la ventana de Comprobante contable del módulo de auditoría




Cuando este botón se presiona el sistema despliega las opciones disponibles:


Generar: crea el comprobante de reclasificación del día seleccionado

Exportar: envía los movimientos a contabilidad

Informe: Muestra el comprobante de reclasificación en un reporte

Terceros: permite crear los terceros en contabilidad



El proceso que se sigue es:

1.      Generar el movimiento de la reclasificación

2.      Utilizando el informe de la reclasificación realizar la verificación del comprobante. Este proceso consiste en verificar que se haya generado las transacciones para todos los folios facturados en la fecha dada cuyo número de documento sea diferente al utilizado para registrar el ingreso.

3.      Utilizar la opción de creación de terceros

4.      Exportar el movimiento a contabilidad
 

Desde Zeus Contabilidad la importación del movimiento no varía respecto al proceso usado para importar el comprobante estándar,Seleccionar la aplicación Hoteles, solo debe asegurarse de indicar la fuente adecuada, es decir la de reclasificación, en lugar de la del movimiento estandar.