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.
