Envíenos su duda o comentario Lista con los nombres de agencias de turismo en Argentina Página con información para los usuarios del sistema Información del sistema, incluyendo características, lista de usuarios y precios Página inicial
versión 5.6.00 -iva al transporte-

introducción

La disposición de agregar el Iva al transporte de pasajeros nos presenta un desafío con consecuencias todavía dificiles de medir.

Desde la versión 3.99 (circa 1994) en donde introducimos la planilla de precios y rentabilidad el sistema efectuaba la siguiente discriminación de importes tanto en venta como en costo:

A partir del agregado del iva al transporte tomamos conocimiento que éste no tan solo se aplica a la tarifa sino también al QN que es la denominación que se le da a los ingresos brutos. Ya unos meses antes, en octubre del 99, se empezó a aplicar el iva sobre la tasa de aeropuerto, pero este no se discriminaba porque no tenemos comprobante de compra. El esquema de discriminación anteriormente expuesto hubiera sido medianamente sostenible si el iva hubiera sido del 21% pero, ¿para que hacerlo fácil?. Además y como para hechar leña al fuego los sistemas de reservas aplican el 14.04% (que en realidad es 14,036 redondeado) a la tarifa y el resultado lo redondean a cero decimal (¡bingo!). ¿La consecuencia?, como se pierden los decimales jamas se puede reconstruir la composición de ese QN con iva incluido.

El análisis de esta información nos llevó a ampliar un concepto que estaba implícito y oculto dentro de aquel esquema: lo "no comisionable" dentro de un mismo servicio. Los impuestos eran lo no comisionable del exento y de la base no imponible, entonces, si ahora tenemos iva sobre el QN quiere decir que tenemos no comisionable con iva. Como tenemos dos tasas diferentes tendremos "no comisionable" a la tasa general de iva y otro "no comisionable" a la tasa diferencial (y por las dudas ya quedamos cubiertos cuando se discrimine el iva de las tasas).

Bien, un paso adelante, pero ¿que hacemos con los redondeos?. Sencillo, vamos acumulando los "no comisionable" con el iva incluido de manera de perder la menor cantidad de decimales y la discriminación la efectuamos al final, cuando calculamos el iva total de la operación.

Para resumir, los campos que agregamos al esquema anterior de discriminación son:

En las siguientes líneas encontrará una planilla de rentabilidad con el ejemplo de un boleto.

Una vez que tuvimos en claro el concepto pasamos a la fase 2, incorporarlo en el sistema. Aquí el tema es aún mas complejo. VSTOUR no es un sistema por módulos separados. No tiene por ejemplo un programa que facture tickets por un lado y otros servicios por el otro. Por el contrario la integración es muy fuerte: el registro de un boleto pasa por un lado a la lista de emitidos, de ahí a la rendición, de ahí a fondos con el pago al BSP y de ahí finalmente a la cuenta corriente con BSP por otro lado la misma registración de un ticket genera un pedido, que afecta a un expediente, que generará una factura que finalmente generará la cuenta corriente con el cliente.

No hubo mas remedio que meter cuchillo y modificar todo el código en aras de mantener la integridad. Pero esto tiene su lado positivo, cuando se tiene el programa totalmente desarmado se pueden revisar rutinas y hacer agregados que de otra manera sería imposible, así es que va a encontrar varias novedades.

Un último comentario, este informe es preliminar, en primer lugar porque la versión no está totalmente terminada, faltan los listados y además sufrirá modificaciones conforme vayamos instalando y surgan errores (esperemos que pocos) y otras modificaciones.

planilla de precios y rentabilidad
Es una de las que reflejan los mayores cambios, note en la siguiente figura los nuevos campos mencionados en la introducción (recuadrados en rojo).

La operatoria se mantiene tal cual como hasta ahora.

fórmulas de iva
Las fórmulas de Iva son utilizadas por las agencias que tienen operatoria mayorista en su mayoría con manejo de cupos. Se agregan tanto para la venta como para el costo los nuevos campos. Véalos en la siguiente figura, recuadrados en rojo:
Ya que cada caso requiere consideraciones especiales no vamos a abundar en precisiones. Las fórmulas que toman la discriminación directamente desde el servicio deberían quedar como en la figura precedente y habría que crear una fórmula para el Iva al 10,5 exactamente igual a la de "todo gravado" pero en el campo adecuado.

Note que hay dos nuevas variables que se pueden utilizar V_RI que contiene como valor 1.21 y V_RIT que contiene como valor 1.105, estas reducen la cantidad de bytes utilizados para escribir.

Atención: estamos en el límite de nuestro evaluador interno de expresiones por lo que las fórmulas son las primeras que lo sienten: la suma total de palabras en las fórmulas escritas no debe pasar nunca los 700 bytes o al cargarlas enviará un error y el sistema cancelará. Agregamos un mensaje de alerta en caso que al modificar una fórmula se presente ese caso. Estamos trabajando en el tema y ya recibimos de uno de nuestros proveedores una nueva versión que aparentemente corrige esta limitación, lamentablemente la implementación requiere que modifiquemos otras que no serían compatibles por lo que lo vamos a dejar hasta que finalizamos las modificaciones operativas pendientes. Este problema también tiene que ver con un error de memoria (5333) que se presenta en la versión Windows aleatoriamente luego de dar de alta un cliente o un proveedor.

servicios
No tiene modificaciones con respecto a la versión 5.5 salvo en la discriminación de precios:

Note que con la modificación sugerida de fórmulas no haría falta discriminar en la compra los campos de no comisionable con Iva y no comisionable con Iva a la tasa diferencial.

proveedores
En este archivo se originan dos cambios importantes: la omisión de control de stock y la definición de valores por omisión.

Se elimina por razones de espacio la nota en la pantalla de edición que sigue accesible desde la lista de proveedores.

Los detalles de las modificaciones se explican en Ticketing y Lista de Emitidos.

datos de configuración
VSTOUR posee un lugar donde se graban los datos generales del sistema, como ser el nombre de la agencia, los porcentajes de Iva, la leyenda de los recibos, etc.. Se configuran a través del utilitario gPatch, en la opción 3, "revisar memory files". En esta oportunidad se agregaron las siguientes variables:

niveles de seguridad
A partir de esta versión empezamos a implementar niveles de seguridad al acceso de la información. Es una combinación de la información que se carga cuando se define una clave (G_InfoC) y el nuevo campo V_SECURE agregado a los datos de configuración. La idea es utilizarlo junto a las claves de acceso a los programas.

Al definir una clave y los programas a los que accede, el programa configurador solicita información adicional:

PROGRM CLAVE INFO
------ ----- --------------
VSTOUR ANYU. 2
VSTOUR GURU. 2A
VSTOUR SUPE. 2!

El campo "INFO" (G_InfoC) da el siguiente significado a las letras ingresadas:

Se implementa por ahora en los siguientes programas: En el futuro formaremos con los clientes del seguro de actualización un grupo que nos vaya definiendo políticas.

ticketing y lista de emitidos
Estos dos puntos del sistema son los que mas sufrieron cambios aunque en pantalla los cambios son mínimos:

Cambios en la visualización de Ticketing: al ingresar al sistema se lo posiciona en los últimos registros (total de registros-10) y en la ventana se lo muestra con orden 0 es decir en el orden en que se fueron grabando con la posibilidad de cambiar al orden de comprobante con F9.

Se implementa en ticketing, en registro de emitidos, anulación de emitidos y marcar void la actualización del pedido del expediente de la siguiente manera:

CUIDADO: si implementa un método diferente de 0 (el que estaba vigente hasta la versión 5.5.xx) al anular un ticket grabado con un método 0 puede encontrar diferencias en el expediente.

Se implementa en ticketing y en registro de emitidos la actualización del over en el pedido cuando se hace una grabación. Si V_OVR210 (agregado a los datos de configuración) tiene un valor de .F. no se graba en el pedido y en consecuencia no se lo toma en el costo del expediente.

CUIDADO: si se anula un ticket grabado con over en el pedido y ahora V_OVR210 es .T. los importes del pedido quedaran mal actualizados. Esto es cierto también para la anulación de facturas con tickets asignados.

Se implementa en ticketin y registro de emitidos la sugerencia de valores particulares para cada compañía. A partir del agregado en el archivo de Proveedores del valor por omisión para comisión, over, porcentaje de over e IT, tanto para cabotaje como para internacional el sistema los presentará si estos estan cargados. Si no están cargados los toma -como ya lo venia haciendo- de parámetros, ítem = CMS, códigos "CAB" para cabotaje e "INT" para internacional.

Se implementa en registro de emitidos hasta 5 ticktes en una sola registración (1 ticket + 4 conectados). Especial para los que emiten Buquebus.

Se implementa en registro de emitidos la omisión del control de stock. Se agregó una campo en Proveedores con el título "omite control stock" que por default está en .F. (no) de manera que si este campo aparece en .T. (si) cuando se registra un ticket en registro de emitidos no hace falta hacer la carga previa del stock. Este proceso esta pensado para las agencias que no tienen stock y en consecuencia compran los tickets a terceros, directamente a la compañía o a su representante. De esta manera se facilita la carga de los tickets que de otra manera se tienen que cargar a través de un pedido y hacer la discriminación manual de precios.

Se amplió la capacidad del programa de anulación de emitidos al permitir la anulación de un ticket void. Esto es especialmente útil cuando por equivocación al querer volver a registrar un ticket se lo voidea en vez de anular y devolverlo al stock como no emitido.

varios
Se mejoró el procedimiento para anular facturas. Ahora el sistema al detectar tikects asociados a la misma pregunta si se los quiere anular y devolver al stock. Si se responde que no se elimina la asignación del ticket a la factura.

Se agregó en la generación de la factura la fecha del vuelo de los tickets asociados al expediente.

Se eliminó la restricción a la consulta de cuentas contables desde ingresos/egresos de fondo para el modelo light.

Se modificó en la versión Windows el comportamiento de los campos de texto multilínea (notas). Ahora si se digita escape se pasa al campo siguiente pero con el texto original restaurado, es decir se anula lo modificado. Esto es especialmente válido en la consulta o modificación de la nota interna (F8) de los pedidos que no funcionaba correctamente en la mencionada versión.

cobranza semi-automática
A los efectos de dotar de mayor agilidad al sistema se implementa la cobranza semi-automática.

Funciona de la siguiente manera: seleccionando dentro de la lista de expedientes el menú Individual/ efectuar Cobranza (tecla rápida Alt-Cero) o desde la pantalla de registro de emitidos o ticketin marcando en "si" el campo "cobra?" el sistema genera una solicitud de movimiento de fondos y llama al programa de ingresos/egresos de fondos donde se deberá completar los valores si no es efectivo.

Se recuerda que el sistema al detectar la cobranza por el total del expediente solicitará emitir la factura (si así está definido en el comprobante "REC" de fondos).

Por ejemplo, una vez emitido el ticket en el sistema de reservas se ingresa en VSTOUR a ticketin se completa el código de cliente, se marca "cobra?" y al aceptar el recibo se acepta también la generación de la factura (esto implica que se creó automáticamente el expediente, el pedido, el pasajero con su asignación al expediente, el ticket para rendir, la baja del stock, la carga de la cuenta corriente deudora, el subdiario de ventas y por último el expediente queda con la marca de cerrado).

-- o --
Fin de esta nota.

Todas las marcas mencionadas en esta página pertenecen a sus respectivos propietarios.
Copyright 2000 by SoftMagic S.R.L.