En el buscador, ingresar el nombre o parte del nombre “Procesos de liquidación”. El sistema presentará todas las opciones disponibles.
Seleccionar la carpeta Procesos de Liquidación.
Generar un nuevo proceso de liquidación, con la herramienta agregar (+):
Se abrirá un formulario. Completar los campos de la cabecera utilizando las siguientes referencias:
Descripción: escribir el nombre del proceso a realizar, por ejemplo “Libro IVA”.
Definición de proceso de liquidación: seleccionar el formato del archivo a generar, entre las opciones que ofrece el sistema. En este caso: “Libro de IVA”.
Desde fecha: indicar desde qué fecha deben ser los comprobantes a incluir en el archivo.
Hasta fecha: indicar hasta qué fecha deben ser los comprobantes a incluir en el archivo.
Esquema Operativo: seleccionar la organización a la cual pertenecen los comprobantes a ser incluidos.
6. Al aceptar, el proceso se creará en estado Abierto.
7. Una vez creado el proceso: posicionar el cursor sobre el mismo > hacer click botón derecho > en Acciones seleccionar Generar proceso de liquidación.
8. Al ejecutar esta acción, aparecerá un aviso informando que recibirá una notificación cuando el proceso haya finalizado. Aceptar.
9. Una vez que el proceso haya finalizado: posicionar el cursor sobre el mismo > hacer click botón derecho > en Acciones seleccionar Obtener TXTs.
10. Al ejecutar esta acción, se descargará automáticamente un archivo .ZIP con los archivos del Libro IVA.
Desde la vista compromisos de pagos (pagos), realizamos dos filtros:
Primer filtro: por operador comercial (filtramos el Proveedor)
Segundo filtro: fecha de “Emisión” menor o igual a => fecha en la cual se consulta el saldo del Proveedor.
2. Luego generamos el “Cubo” colocando en las medidas “Total” y algunas dimensiones como: operador comercial; fecha; tipo de transacción; etc.
De esta forma podremos visualizar todos los comprobantes de fecha igual o menor a la indicada, brindando como información final el saldo que el Proveedor tenía en la fecha consultada.
Desde la vista compromisos de pagos (cobranzas), realizamos dos filtros:
Primer filtro: por operador comercial (filtramos el cliente)
Segundo filtro: fecha de “Emisión” menor o igual a => fecha en la cual se consulta el saldo del cliente.
2. Luego generamos el “Cubo” colocando en las medidas “Total” y algunas dimensiones como: operador comercial; fecha; tipo de transacción; etc.
De esta forma podremos visualizar todos los comprobantes de fecha igual o menor a la indicada, brindando como información final el saldo que el cliente tenía en la fecha consultada.
Los circuitos tienen transacción Origen y transacción destino.
Ejemplo :
Recepción de Mercadería :
Su transacción de origen es la ORDEN DE COMPRA y la transacción destino FACTURA DE COMPRA (esta información se puede chequear haciendo botón derecho sobre la transacción, grafo de trazabilidad). Ninguna transacción se puede anular cuando su transacción DESTINO ya se generó.
Para anularla hay que hacer el camino inverso:
Arrancar anulando desde la última transacción generada. Dicho esto LA ORDEN DE PAGO TIENE COMO TRANSACCIÓN DESTINO EGRESO DE VALORES.
NO SE PUEDE ANULAR LA ORDEN DE PAGO SI EL EGRESO YA SE GENERÓ.
Entonces la solución es posible mediante: 1. ANULAR EL EGRESO DE VALORES 2. ANULAR LA ORDEN DE PAGO
Esta explicación es válida para todos los circuitos.
La seguridad de los permisos funcionales nos permite incorporar al sistema quién puede realizar cambios en los estados de la transacción.
Vamos a todos los elementos y buscamos Objetos Especializados:
Elegimos la transacción a la cual queremos definir la seguridad, en el ejemplo utilizare Orden de Compra:
Ingresamos a la transacción Orden de Compra donde definimos todos los estados por los cuales puede pasar esta transacción y quienes son los autorizados para realizar cada uno de los cambios.
En el ejemplo la Orden de Compra de Pendiente puede pasar a:
Rechazada
Autorizada
Anulada
de Autorizada puede pasar a:
Anulada
Para cada uno de estos cambios se define qué grupo o usuario puede realizarlo.
Tomando el ejemplo, debemos ingresar a la transición, por ejemplo Autorizar, haciendo doble click:
Elegimos el grupo que vemos que grupo / grupos podría hacer esta transición.
Vemos que el Grupo todos puede realizar esta transición, es decir cualquier usuario que pertenezca al grupo Todos está habilitado.
Vemos que también podemos colocarle un importe, si se ingresa un importe se verificará que el total de la Orden de Compra en este caso sea inferior al importe registrado en la seguridad para poder realizar la transición.
En los permisos de los flag si el campo moneda se completa se entiende que el campo Importe está expresado en la moneda seleccionada, por lo que el valor de la transacción busca la equivalencia a esa moneda según las cotizaciones de moneda y se evalúa si se puede autorizar o no.
Por ejemplo:
En la transición definí que el usuario “test” puede autorizar hasta Dólares 100 y el grupo “Todos” hasta 100 (sin moneda). Todos los usuarios pueden autorizar transacciones de hasta un importe de 100 (sin importar la moneda ), menos “test” que puede autorizar comprobantes con un importe equivalente hasta 100 Dólares.
También podemos ingresar a los usuarios:
Tenemos la lista de usuarios que pueden realizar la transición de autorización con varias particularidades:
Se puede colocar fecha de vigencia en la cual este usuario puede realizar esta tarea con este fin tenemos desde fecha hasta fecha.
Hasta importe: indica hasta qué valor del total de la transacción puede habilitar este usuario.
A diferencia de la moneda INDEX , MONEDA es la moneda de emisión de la transacción que se enviara a AFIP .
La MONEDA INDEX es si estamos indexando los importes en alguna otra moneda, esta moneda es interna sirve solamente para calcular el total en la moneda local como por ejemplo :
Si en la MONEDA INDEX colocamos que es DÓLARES ESE CAMPO SOLO NOS SERVIRA PARA CALCULAR LOS PRECIOS TOTALES tomando en cuenta la cotización del momento pero no se enviara a AFIP , en AFIP se enviaran solo los importes en pesos.
La cotización para el «TOTAL EN DÓLAR « se toma de las cotizaciones cargadas en el sistema , y se usa la inmediata inferior a la fecha del comprobante .
La idea de la MODENA INDEX es poder conocer el importe del comprobante o los ítems del comprobante en otra moneda.
Por ejemplo el campo Precio Unitario aparece en solo lectura cuando se usa MONEDA INDEX, porque se esta obligado a cargar el precio en esa moneda. Si quiero cargar precios en pesos tengo que usar MONEDA INDEX en pesos.
En el menú superior derecho ACCESOS – CLIENTE DELGADO
El Usuario y Password para ingresar debe gestionarse con el área Comercial de Calipso.
Una vez dentro del Sistema de Tickets, dependiendo del grado de acceso con que se cuente, debe accederse a la siguiente ruta:
Clientes Internos
Clientes Externos
Nota: Esta ruta la pueden visualizar dentro del Sistema de Tickets en una banda que se ubica por debajo de los botones de navegación y por sobre la banda que muestra el usuario actualmente logueado, los botones de Cambio de Contraseña, Preferencias de Usuario, Cerrar Sesión y Mostrar Navegación, y hacia la derecha la versión de Biframe Web Client.
En la solapa «Principal»
La numeración es automática.
La fecha de carga la propone automáticamente el Sistema de Tickets y es la del día de carga.
En el atributo Cliente cada Cliente final logueado debe seleccionar su nombre de la lista. En el caso de los Partners de Calipso deben seleccionar el Cliente para el cuál están cargando el Ticket.
En el campo Tema, se necesita que se describa en forma concisa el requerimiento y que incluya las palabras más representativas para luego poder hacer una búsqueda por un tema particular y porque además el tema se incluye en el e-mail automático que se envía a los suscriptores cuando el Ticket pasa del flag “Pendiente Soporte” a “A Controlar”.
El tipo de Ticket puede ser:
Problema: Para el caso de un bug del Producto o de la Implementación.
Mejora: Para obtener una funcionalidad que actualmente el Sistema no abarca.
Instalación: Para el caso de necesitar la Instalación del Producto.
Consulta: En el caso que el Ticket refiera simplemente a una consulta y no a una modificación del Sistema.
Pedido de Versión: Para la solicitud de una nueva versión del Producto.
El Producto puede ser: (según el Producto de Calipso adquirido)
Corporate.
Wan.
La Versión del Producto a la que se refiere el requerimiento. Por ejemplo en el caso que el Producto sea Corporate, un valor válido puede ser: “2010.257.5037”
La Clave de Soporte es proporcionada por el área Comercial de Calipso. Esta clave habilita al Cliente a utilizar el Sistema de Tickets de Soporte.
La Fecha Estimada de Finalización por el momento no se utiliza. Actualmente se puede trabajar con las fechas de los Ítems del Ticket que inician la ocurrencia de distintos eventos, como la carga inicial del Ticket y las sucesivas conversaciones entre las partes, cada una con sus fechas.
Criticidad:
Alta: Para el caso de errores que detienen gran parte de la actividad del cliente final.
Media: Errores que no detienen la actividad del cliente final pero es conveniente corregirlos a mediano plazo.
Es Bloqueante ? por el momento no se utiliza. Actualmente se puede establecer este dato utilizando el atributo Criticidad.
El Mail para Respuesta por el momento no se utiliza. Actualmente se puede indicar en el atributo Solicitante, la persona que hace el requerimiento. En el Sistema de Tickets, las personas que realizarán requerimientos, deben registrarse previamente, indicando su nombre completo y dirección de e-mail. El alta de estos datos pueden solicitarse en el área Comercial de Calipso.
El Tipo de Soporte es un dato interno de sólo lectura utilizado por Calipso para identificar el tipo de contratación de Soporte que cada Cliente tiene.
El Solicitante identifica a la Persona que realiza el requerimiento a través del Sistema de Tickets. En el Sistema de Tickets, las personas que realizarán requerimientos, deben registrarse previamente, indicando su nombre completo y dirección de e-mail. El alta de estos datos pueden solicitarse en el área Comercial de Calipso. Las notificaciones automáticas que genere el Ticket serán comunicadas a la/las dirección/es de e-mail registradas para el Solicitante.
El atributo Asignado a es un dato interno de sólo lectura utilizado por Calipso para administrar la asignación de trabajo sobre los Tickets. En el caso que el Ticket requiera información adicional por parte de personal de Calipso hacia el Solicitante, en el atributo Asignado a aparecerá el Solicitante, hasta tanto realice la ampliación de la información requerida.
En la carga de Items
El atributo Tipo del primer Ítem debe estar relacionado al Tipo del Ticket cargado en el encabezado del Ticket, a saber: «Problema», «Mejora», “Consulta”, “Cambio de Versión” o «Instalación», en el detalle se describe el requerimiento.
Nota: Opcionalmente pueden incluirse archivos adjuntos que aclaren el requerimiento o bien que definan el alcance de una Mejora. Esto puede hacerse accediendo a la solapa de detalle “Documentos Asociados”. El Sistema de Tickets los guiará para poder adjuntar un documento, planilla, imagen, etc. al Ticket.
El siguiente Ítem del diálogo puede ser de tipo «De Soporte», en el caso que el Personal de Calipso dé una respuesta que intenta satisfacer el requerimiento. También puede ser de tipo “Solicitud de Información” en el caso que el Personal de Calipso requiera más datos para poder dar una respuesta sobre el Requerimiento. En este caso, el Ticket queda automáticamente asignado al Solicitante y a la espera de la información solicitada.
Nota: Dependiendo del Requerimiento, el personal de Calipso también puede contactarse directamente con el Solicitante (vía telefónica, chat, etc.).
Cuando el Solicitante brinda la información requerida por el personal de Calipso, debe ingresar un Ítem de Tipo “Ampliación de la Información” incluyendo en el campo “Detalle” todos los datos que le fueron solicitados. A partir de la inclusión de un Ítem de este tipo, el Ticket vuelve a quedar asignado automáticamente a la persona de Calipso que requirió la información.
Nota: Este ciclo puede repetirse las veces que sean necesarias.
Una vez que el personal de Calipso brinda la respuesta al requerimiento, el Solicitante tendrá 30 días para verificar que la respuesta satisfaga el requerimiento. Posteriormente el Ticket se finalizará y será necesario iniciar un nuevo Ticket si el problema persiste una vez vencidos estos plazos.
Como resultado de la verificación, si el requerimiento es satisfecho, el Solicitante puede incluir un Ítem de tipo “Testing OK” detallando las pruebas realizadas y datos del contexto en donde se hicieron las mismas. Por ejemplo puede indicar los siguientes datos en donde verificó la respuesta del Personal de Calipso:
Base de datos donde se realizó la prueba
Unidad Operativa (si correspondiera)
OTE (si correspondiera)- Proceso
Cualquier otro dato que pueda ser útil a fin de poder verificar el testing.
En el caso que el requerimiento no quede satisfecho con la respuesta brindada por el Personal de Calipso, el Solicitante puede incluir un nuevo Ítem de tipo “Problema” detallando por qué la respuesta obtenida no satisface su requerimiento.
Transiciones de flags
Cuando se carga un Ticket, automáticamente ingresa al Sistema de Tickets con el flag «Para Aceptacion». Una vez analizado por personal de Calipso, el Ticket puede ser:
Anulado, rechazado: por ejemplo en el caso que el Ticket se encuentre repetido o cargado con el texto del detalle vacío. Esta situación se informará en un nuevo Ítem de tipo “De Soporte”.
Conservado, modificado, recategorizado y transferido al siguiente flag que es “Para análisis comercial”.
Cuando el área Comercial verifica que las condiciones comerciales del Cliente que carga el Ticket están cumplidas, el Ticket pasa al flag “Pendiente Soporte” y queda disponible para que el Personal de Soporte de Calipso trabaje en el Ticket.
Cuando el Personal de Soporte trabaja y genera una respuesta al Ticket el mismo pasa al flag «A Controlar» avisando por e-mail a los suscriptores del Ticket sobre este cambio de estado.
Nota: Los involucrados en el Ticket (Solicitante, Responsable, Asignado) quedan automáticamente suscriptos a las notificaciones del Ticket. Opcionalmente pueden incluirse Suscriptores al Ticket. Esto puede hacerse accediendo a la solapa de detalle “Suscriptores”. El Sistema de Tickets mostrará una lista de Personas que pueden ser incluidas como Suscriptores del mismo.
En correspondencia con el proceso descripto en la carga de Ítems de Tickets el Solicitante puede efectuar ciertas transiciones de flags:
“Como resultado de la verificación, si el requerimiento es satisfecho, el Solicitante puede incluir un Ítem de tipo “Testing OK” detallando las pruebas realizadas y datos del contexto en donde se hicieron las mismas.”
En este caso, que indica que el requerimiento fue satisfecho por la respuesta del Personal de Calipso, el Solicitante, además de poder agregar el Ítem de tipo “Testing OK”, puede transicionar desde el flag “A Controlar” al flag “Ticket Finalizado”.
Nota: Esta transición, vencido un plazo de 30 días la efectuará el Sistema de Tickets en forma automática, previo aviso al Solicitante.
“En el caso que el requerimiento no quede satisfecho con la respuesta brindada el Solicitante puede incluir un nuevo Ítem de tipo “Problema” detallando por qué la respuesta obtenida del Personal de Calipso no satisface su requerimiento.”
En este caso, que indica que el requerimiento no fue satisfecho por la respuesta del Personal de Calipso, el Solicitante, además de poder agregar el Ítem de tipo “Problema”, debe transicionar desde el flag “A Controlar” al flag “Pendiente Soporte” para reiniciar el ciclo.
Situaciones especiales
En el caso que el Requerimiento sea extremadamente urgente (por paralización de actividades del Sistema, por ejemplo) el procedimiento a seguir debe ser el mismo en cuanto a la carga del Ticket, pero deberá informarse sobre esta situación después de la carga del Ticket, al área Comercial de Calipso, indicando desde ya el número del Ticket en cuestión para agilizar la respuesta sobre el mismo
Para realizar el Cierra Contable se deberá realizar la siguiente configuración :
Configuración del Ejercicio Contable
Se deberá ingresar al ejercicio contable y completar los siguientes campos:
Cuenta de Resultado del Ejercicio: Seleccionar la Cuenta correspondiente del Plan de Cuentas.
Genera un solo Asiento de Cierre: Seleccionar Si o No. Si está en “No”, genera un asiento de Resultado y otro asiento para cuentas Patrimoniales, en el caso que este en “Si” generará un solo asiento para los dos.
Generara asiento de cierre en estado (ABIERTO).
Unidad Operativa para Cierre Contable: Seleccionar la Unidad Operativa de Contabilidad donde se generan los asientos (CONTABILIDAD).
Cuenta de Resultado del Ejercicio Anterior: Seleccionar la Cuenta correspondiente del Plan de Cuentas.
Tipo de Transacción para Cierre Contable: Seleccionar la transacción Contable que se utilizará para generar el asiento correspondiente ( ASIENTO MANUAL).
Por otro lado las cuentas que se indiquen en alguno de los campos “Cuenta de Resultado” deberán tener en su configuración dicha tipificación.
Para realizar el cierre contable tiene que estar el próximo ejercicio creado y seleccionarlo como ejercicio corriente en el Esquema operativo, es importante tener en cuenta que el último período del ejercicio a cerrar debe estar en estado activo y el primer período del nuevo ejercicio también debe encontrarse en estado activo y debe ser el siguiente período al último período del ejercicio anterior.
Allí aparecen los campos a completar para el cierre del anterior y el verbo cierre contable:
1. Crear el nuevo Ejercicio.
2. Ir al Esquema Operativo, en Ejercicio Anterior seleccionar el Ejercicio que se quiere cerrar y en Ejercicio Corriente seleccionar el nuevo Ejercicio donde se creará el Asiento de Apertura:
3. El Ejercicio de Cierre y el Periodo donde debe contabilizarse el asiento de Cierre deben estar en estado Activo para que permita contabilizarse.
4. El Ejercicio de Apertura y el Periodo donde debe contabilizarse el asiento de Apertura deben estar en estado Activo para que permita contabilizarse.
Proceso de Cierre Contable
Se deberá posicionar en el ejercicio que quiere cerrar, hacer click derecho y posteriormente seleccionar Cierre Contable, como se observa a continuación:
