Generalidades:
La Disposición normativa Serie B numero 32/06 emitida por ARBA indica que, bajo ciertas condiciones, el traslado de mercadería en el territorio de la Provincia de Buenos Aires, debe estar amparada por un número otorgado por dicha Agencia.
Dicho número es valido para una serie de remitos o bien para un remito en particular, y puede ser obtenido por distintos medios.
A través del aplicativo SIAP, y mediante el modulo OPTTB, a través de la pagina de ARBA, cargando una serie de datos o bien transfiriendo un archivo de textos, o finalmente de manera electrónica, donde en esta ultima se produce una comunicación entre la máquina que esta emitiendo el remito, y los servidores de ARBA encargados de asignarles el numero COT, algo similar, pero mucho mas sencillo que lo que se realiza para facturación electrónica A,B y E.
Igualmente es importante tener en cuenta que, a diferencia de la facturación electrónica Afip, para la obtención del COT se informan una serie bastante mas amplia de datos.
Estos datos surgen del remito u orden de carga, o bien de tablas anexas ya existentes en el sistema como ser la de transportes o parámetros.
El detalle de los datos que se deben enviar electrónicamente, puede ser consultado en el siguiente link :
http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110823-TB-RemitoElectronicoDiseño.pdf
A partir de la revisión 111223, Datacomsys cuenta con la posibilidad de obtención del COT de manera automática, en forma similar a como se obtiene el CAE para una factura electrónica.
A tales efectos, se deben realizar ciertas instalaciones, parametrizaciones y validaciones, y comprender ciertos conceptos que el presente documento intentara explicar.
Diferencias entre la obtención del CAE de facturación y el COT del remito.
La factura electrónica es una factura, a partir que afip otorga el CAE.
El numero COT se obtiene sobre un remito que ya esta realizado.
La factura electrónica sin CAE no es valida, en cambio puede haber, bajo ciertas circunstancias, remitos sin COT, por ejemplo los de otra provincia, o los que valorizados estén por debajo de la cota mínima.
O sea, el COT es a nivel Provincial o de Agencia, el CAE de una factura es a nivel nacional.
(Si bien otras provincias están optando por el mismo método de verificación)
La obtención del CAE requiere de ciertos pasos de habilitación y certificación en AFIP, el COT solo requiere de un usuario y contraseña obtenidos en la Web de ARBA.
La factura con CAE se llama Factura electrónica, al remito con COT lo llaman Remito electrónico, pero en realidad mas que remito electrónico es un remito autorizado electrónicamente.
El numero CAE es único para cada comprobante, el numero COT puede ser el mismo para un lote de remitos.
Que tipos de remitos Datacomsys pueden ser informados:
Los remitos por venta (VTA), los remitos por consignación a clientes (CSG), los remitos por devoluciones a proveedores (DEV), los remitos por envío de Fasón (FSN) y los remitos por transferencias entre depósitos (TRF).
No esta previsto para los tipos de remitos manuales (MAN), las ordenes de entrega asociadas a los contado (OEN) y los remitos por uso interno (USO).
Que tablas Datacomsys hay que tener parametrizadas correctamente.
Catalogo de provincias:
Tener bien parametrizado los datos de código ARBA y código RNPA.
Catalogo unidades de medida:
Tener bien parametrizado los datos de código ARBA
Catalogo de productos:
Tener bien parametrizado los códigos en el campo “Nomenclador”
(Tener en cuenta que no es un código particular para cada producto singular, sino que según la codificación de Arba, es muy posible que todo un rubro lleve el mismo código)
Transportes:
Tener bien parametrizado el cuit del transporte y la patente del mismo.
Sucursales, clientes, proveedores:
Tener correctamente indicados los domicilios, localidades, códigos postales y códigos de provincia.
Los códigos ARBA pueden ser obtenidos del siguiente link :
http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110818-TB-Tablas%20de%20validacion.pdf
Que tramitación se debe hacer en ARBA:
Se debe obtener una clave de acceso y password, según lo que se explica en : www.rentas.gba.gov.ar
Ingresos brutos
Código de operaciones de traslado (COT)
Clave de transporte
Instalación en cada maquina que solicitara el COT:
Se debe instalar la interfase phytom que se obtiene desde el link :
http://www.datacomsys.com.ar/bkps/xpws/electronicas/pythom/201111/instalador-COT-1.01c-full.exe
En la ubicación c:\COT, y siendo esta instalación realizada por nosotros y con un costo adicional.
Debe existir la carpeta c:\datacomsys\cot, donde ser guardarán los distintos archivos de transferencia entre Datacomsys y ARBA.
Parametrizacion de punto de venta:
Se debe acceder a Parámetros, menú superior Parámetros, marcando el punto de venta que se desea habilitar y clickeando en (Parámetros), se debe verificar que este bien parametrizado domicilio, localidad, código postal y provincia.
Habiendo marcado la sucursal que se desea habilitar, se debe clickear en (Impresoras), y luego acceder a la solapa “Remito Electrónico”
En el campo con rotulo “Servidor autentificación”, se debe ingresar:
https://cot.ec.gba.gov.ar/TransporteBienes/SeguridadCliente/presentarRemitos.do
Usuario y contraseña deben ser aquellos tramitados en la Web de ARBA, como se explico anteriormente.
Que se informa y de donde se obtiene:
En función de lo que se menciono en “Generalidades”, los datos que se informan por cada tipo de remito son los siguientes:
VTA Remito de venta:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del cliente.
Si el cliente es consumidor final, asume que es el tenedor final.
Asume que se envían productos terminados.
Asume que el solicitante del COT es el emisor del remito.
CSG Remito por consignación:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del cliente.
Si el cliente es consumidor final, asume que es el tenedor final.
Asume que se envían productos terminados.
Asume que el solicitante es el emisor del remito.
DEV Remito por devolución:
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del proveedor asociado, obligatoriamente se debe informar que los productos NO son terminados por mas que lo estén.
Asume que el solicitante del COT es el emisor del remito.
FSN Remito por fason :
Obtiene Cuit destino, razón social, domicilio, código postal, localidad y provincia del legajo del proveedor asociado, obligatoriamente se debe informar que los productos NO son terminados.
Asume que el solicitante del COT es el emisor del remito.
TRS Remito por transferencia entre depósitos:
El cuit de destino es similar al cuit emisor.
Domicilio, código postal, localidad y provincia de destino se obtienen del depósito receptor.
Asume obligatoriamente que se trata de productos NO terminados por mas que lo estén.
Asume que el solicitante del COT es el destinatario de la mercadería.
Otros datos generales que se informan:
Cuit del emisor del remito, fecha y hora de comienzo del traslado de la mercadería, dirección, localidad, código postal y provincia del punto de venta emisor del remito u orden de carga, cuit y chapa patente del transportista asociado a la orden de carga o remito, código ARBA de los productos informados, código propio, descripción, cantidad remitida, e importe total del remito.
Utilización:
Puede utilizarse de dos maneras, obteniendo el numero COT remito por remito, o bien mediante la utilización de una Orden de carga, en este ultimo caso, el numero COT obtenido es el mismo para la orden de carga y los respectivos remitos que la componen.
Sugerimos que la obtención del COT se realice a través de una orden de carga, debiendo estar la misma con el estado “C” cerrada.
En ambos casos, al obtener el cot desde un remito o bien desde una orden de carga, se genera en la dirección c:\datacomsys\cot, un archivo de transferencia con la estructura que se referencia en “Generalidades” y que tiene como nombre la siguiente estructura:
TB_{cuit emisor}_001001_{año mes dia}_{últimos seis dígitos de la OCG o RTO}.TXT
Este archivo es el que se utiliza, automáticamente, para la obtención del cot.
Este archivo no se destruye con la obtención del COT, sino que queda guardado en la dirección referenciada.
Mas detalles sobre este archivo de transferencia, se pueden consultar en el siguiente link: http://www.arba.gov.ar/bajadas/Fiscalizacion/Operativos/TransporteBienes/Documentacion/20110818-TB-RemitoElectronicoAplicacionCliente.pdf
Obtener el número COT desde un remito:
Para obtener el numero COT desde un remito emitido, se debe acceder al acceso AFIP, ingresando con el numero de sucursal acorde a los remitos emitidos y a declarar, y clickear en el botón (COT ARBA).
Una vez accedido, se despliegan los remitos ordenados inversamente, se debe localizar el remito a obtener el COT y clickear en (Obtener COT).
Si no hay errores, se genera el mencionado archivo de transferencia con los datos del remito en particular, se lo envía para su autorización, y se obtiene automáticamente el numero COT que quedará asociado al remito y se podrá visualizar en la consulta del mismo, así como en la grilla de remitos en las columnas COT numero y COT integridad.
Obtener el numero COT desde una orden de carga.
Para obtener el numero COT desde una orden de carga, se debe acceder al acceso DESPACHO, (ordenes de carga), y localizar la orden de carga a autorizar, la que debe estar con estado “C”cerrada.
Una vez localizada la orden de carga, se deberá clickear en (Obtener COT)
Si no hay errores, se genera el archivo de transferencia con los datos de los remitos incorporados en la orden de carga, se lo envía para su autorización, y se obtiene automáticamente el numero COT que quedará asociado a la orden de carga y a todos sus remitos, pudiendo ser consultado tanto en la consulta de ordenes de carga como en cada remito en particular.
Validaciones Datacomsys que se realizan antes de solicitar el COT:
Que este parametrizado el servidor de autentificación en el legajo de la sucursal solicitante.
Que el o los remitos asociados a la orden de carga de origen no tengan número de cot asignado anteriormente.
Que el o los remitos asociados a la orden de carga de origen sean de los tipos de remitos validos para la obtención del COT
Validaciones que realiza ARBA con el archivo de transferencia informado:
Los posibles errores que encuentre ARBA se desplegaran al momento de solicitar el COTS, e igualmente se pueden visualizar desde el acceso Parámetros, menú superior parámetros, opción Motivos de rechazo COT.
Mayores detalles solicitarlos a informes@carlosherrero.com.ar o bien visitando www.datacomsys.com.ar / www.datacomsys.blogspot.com
Ch 16-12-2011
miércoles, 21 de diciembre de 2011
Datacomsys 7.4 / 8.0 Revision 111223
Modificaciones importantes en Datacomsys Revisión 111223
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
Informe de valores emitidos
Alarma por cambios de precios
Fraccionamientos dinámicos
Ordenes de compra nacionales en moneda extranjera
Clave de Operaciones de transporte (COT)
IMPORTANTE: Facturación electrónica, error de certificados:
En las instalaciones Datacomsys que están utilizando la facilidad de facturación electrónica, A,B y E, se esta presentando un error con cierta periodicidad que imposibilita la obtención del cae.
El mensaje de error dice textualmente:
“El CEE ya posee un TA valido para el acceso al WSN solicitado”
Este mensaje, que envía afip, básicamente quiere decir que el cuit informante, o sea, quien esta intentando emitir la factura (CEE), ya esta habilitado(TA) para la utilización del servicio(WSN) de obtención del CAE.
En definitiva, que no hace falta que se presente de nuevo con su certificado.
Cuando explicamos en su momento el procedimiento de facturación electrónica por Internet, comentamos que constaba de dos pasos, el primero era la presentación del certificado en una especie de ventanilla electrónica, lo que nos habilitaba para presentar, en otra ventanilla electrónica, el comprobante que se quiere autorizar y así obtener el cae.
Para acelerar los tiempos de obtención del cae, afip brinda la posibilidad que la presentación del certificado, en la primer ventanilla, se pueda hacer cada veinticuatro horas, de esa manera se presentaría una sola vez y luego durante esas veinticuatro horas se puede solicitar directamente la obtención del CAE para uno o mas comprobantes, en la segunda ventanilla.
El mensaje de error que mencionamos, nos dice de una manera no muy amigable, que no hace falta que nos presentemos en la primer ventanilla por cada comprobante que emitimos.
Esta posibilidad va a estar disponible en Datacomsys, para la versión del mes de enero 2012.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Todas las versiones (7.4 / 8.0):
Informe de valores emitidos:
Se ha agregado al menú de informes del modulo de ingresos y egresos, uno nuevo que permite emitir uno desplegando los distintos valores emitidos, el uso es similar al ya existente que informa valores en cartera.
Alarma por cambios de precios:
Se ha agregado una nueva alarma Data-Agent que permite enviar un email, a varios usuarios, informando que hubo cambios de precios o costos de productos de venta.
Fraccionamientos dinámicos:
El modulo de fraccionamiento que se encuentra en el acceso de Producción, cuenta con una nueva posibilidad que denominamos fraccionamientos dinámicos.
Lo dinámico resulta precisamente por no tener que cargar obligatoriamente los resultados de todos los subproductos asociados a un método, sino que bien pueden algunos ignorarse y otros no.
Esta posibilidad se define precisamente en cada método de fraccionamiento.
Otra particularidad es que los productos terminados calculan su óptimo en base a un factor, y que el desperdicio o ganancia se aplica al insumo, siendo que actualmente se aplican al producto terminado.
En caso de ser necesario, y a solicitud, se envía un documento específico para este tema en particular.
Ordenes de compra nacionales en moneda extranjera:
A partir de esta revisión se pueden emitir órdenes de compra en moneda extranjera, anteriormente esta posibilidad estaba restringida a que en el legajo del proveedor se le haya definido un país distinto que 0-Argentina.
Con esta nueva posibilidad, al indicar una moneda distinta que 1-Pesos, la actividad se comporta de manera similar que si se trabajara con un proveedor del exterior.
Clave de Operaciones de transporte (COT) :
Disposición normativa Serie B numero 32/06
http://www.arba.gov.ar/Intranet/Legislacion/Normas/Disposiciones/2006/DispB/B032-06.htm
La normativa de referencia establece, bajo ciertas condiciones, que para el traslado de mercadería, y estando el domicilio emisor del remito dentro de la Provincia de Buenos Aires, se debe tramitar un numero de autorización que se denomina COT.
A partir de esta versión se puede obtener dicho numero de autorización en forma automática, de forma similar a como se tramita el CAE de una factura electrónica.
Esto se logra a través de una interfase desarrollada por terceros, y que deberá ser instalada en cada una de las maquinas que tramiten el COT.
El procedimiento esta disponible para se efectuado remito por remito, o bien a través de una orden de carga.
En caso de solicitarse, se envía un documento especial sobre este tema.
Mas información sobre COT en http://www.rentas.gba.gov.ar/, ingresos brutos, código de operaciones de traslado.
Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com
Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.
Ch 23-12-2011
Títulos correspondientes a modificaciones y agregados realizados para esta revisión.
Aplicado a todas las versiones (7.4 / 8.0):
Informe de valores emitidos
Alarma por cambios de precios
Fraccionamientos dinámicos
Ordenes de compra nacionales en moneda extranjera
Clave de Operaciones de transporte (COT)
IMPORTANTE: Facturación electrónica, error de certificados:
En las instalaciones Datacomsys que están utilizando la facilidad de facturación electrónica, A,B y E, se esta presentando un error con cierta periodicidad que imposibilita la obtención del cae.
El mensaje de error dice textualmente:
“El CEE ya posee un TA valido para el acceso al WSN solicitado”
Este mensaje, que envía afip, básicamente quiere decir que el cuit informante, o sea, quien esta intentando emitir la factura (CEE), ya esta habilitado(TA) para la utilización del servicio(WSN) de obtención del CAE.
En definitiva, que no hace falta que se presente de nuevo con su certificado.
Cuando explicamos en su momento el procedimiento de facturación electrónica por Internet, comentamos que constaba de dos pasos, el primero era la presentación del certificado en una especie de ventanilla electrónica, lo que nos habilitaba para presentar, en otra ventanilla electrónica, el comprobante que se quiere autorizar y así obtener el cae.
Para acelerar los tiempos de obtención del cae, afip brinda la posibilidad que la presentación del certificado, en la primer ventanilla, se pueda hacer cada veinticuatro horas, de esa manera se presentaría una sola vez y luego durante esas veinticuatro horas se puede solicitar directamente la obtención del CAE para uno o mas comprobantes, en la segunda ventanilla.
El mensaje de error que mencionamos, nos dice de una manera no muy amigable, que no hace falta que nos presentemos en la primer ventanilla por cada comprobante que emitimos.
Esta posibilidad va a estar disponible en Datacomsys, para la versión del mes de enero 2012.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Todas las versiones (7.4 / 8.0):
Informe de valores emitidos:
Se ha agregado al menú de informes del modulo de ingresos y egresos, uno nuevo que permite emitir uno desplegando los distintos valores emitidos, el uso es similar al ya existente que informa valores en cartera.
Alarma por cambios de precios:
Se ha agregado una nueva alarma Data-Agent que permite enviar un email, a varios usuarios, informando que hubo cambios de precios o costos de productos de venta.
Fraccionamientos dinámicos:
El modulo de fraccionamiento que se encuentra en el acceso de Producción, cuenta con una nueva posibilidad que denominamos fraccionamientos dinámicos.
Lo dinámico resulta precisamente por no tener que cargar obligatoriamente los resultados de todos los subproductos asociados a un método, sino que bien pueden algunos ignorarse y otros no.
Esta posibilidad se define precisamente en cada método de fraccionamiento.
Otra particularidad es que los productos terminados calculan su óptimo en base a un factor, y que el desperdicio o ganancia se aplica al insumo, siendo que actualmente se aplican al producto terminado.
En caso de ser necesario, y a solicitud, se envía un documento específico para este tema en particular.
Ordenes de compra nacionales en moneda extranjera:
A partir de esta revisión se pueden emitir órdenes de compra en moneda extranjera, anteriormente esta posibilidad estaba restringida a que en el legajo del proveedor se le haya definido un país distinto que 0-Argentina.
Con esta nueva posibilidad, al indicar una moneda distinta que 1-Pesos, la actividad se comporta de manera similar que si se trabajara con un proveedor del exterior.
Clave de Operaciones de transporte (COT) :
Disposición normativa Serie B numero 32/06
http://www.arba.gov.ar/Intranet/Legislacion/Normas/Disposiciones/2006/DispB/B032-06.htm
La normativa de referencia establece, bajo ciertas condiciones, que para el traslado de mercadería, y estando el domicilio emisor del remito dentro de la Provincia de Buenos Aires, se debe tramitar un numero de autorización que se denomina COT.
A partir de esta versión se puede obtener dicho numero de autorización en forma automática, de forma similar a como se tramita el CAE de una factura electrónica.
Esto se logra a través de una interfase desarrollada por terceros, y que deberá ser instalada en cada una de las maquinas que tramiten el COT.
El procedimiento esta disponible para se efectuado remito por remito, o bien a través de una orden de carga.
En caso de solicitarse, se envía un documento especial sobre este tema.
Mas información sobre COT en http://www.rentas.gba.gov.ar/, ingresos brutos, código de operaciones de traslado.
Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com
Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.
Ch 23-12-2011
viernes, 27 de mayo de 2011
Costo de ultima compra
Ordenes de compra en distinta moneda que la correspondiente al costo del producto
Detalle:
Se ha detectado un error que se produce al realizar una orden de compra, expresada por ejemplo en pesos; conteniendo productos costeados por ejemplo en dólares.
El error se visualiza en la forma de archivar lo que el sistema denomina como “costo de última compra”.
Datacomsys mantiene, para cada producto y lista de precios, la posibilidad de indicar la moneda en la que se expresa el costo.
En casos en que el producto se compra a un proveedor del exterior, la orden de compra solicita la moneda y la cotización, debiendo dicha moneda ser coincidente con la que se expresa como moneda de costo para cada uno de los productos; pero puede darse que en el legajo del producto y lista de precios, el costo se expresa por ejemplo en dólares, y la orden de compra se realiza a un proveedor de plaza, que por comodidad cotiza en dólares.
En este último caso, el costo de última compra queda archivado en forma errónea.
Explicación:
Al momento de hacer una orden de compra, el costo sugerido es el costo de reposición pesificado según la moneda que se haya indicado, en caso de ser pesos no habrá cálculo, pero en caso de ser otra moneda dicho costo se pesificara utilizando la cotización de la fecha.
Ahora bien, para guardar el costo de ultima compra se realiza el proceso inverso, el costo que se haya sugerido y aceptado, o bien modificado por otro nuevo, se vuelve a la moneda de costo utilizando la cotización indicada en la orden de compra, pero si la orden de compra es en plaza no hay cotización, la cotización será 1.000, o sea, guardará como costo de ultima compra el pesificado, ocasionando el error en los informes de valuación de inventario a costo de ultima compra, ya que dicho informe lo pesificará nuevamente.
Ejemplo:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 1.0000
Al hacer la orden de compra en plaza, se desplegara como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 1.000) = 4.293, lo que NO es correcto.
Solución:
A partir de la versión 110624 (24-06-2011), la orden de compra, por mas que sea realizada a un proveedor en plaza, solicitará moneda y cotización, de manera que aquellos proveedores cuyos costos son mantenidos en el sistema en otra moneda que pesos, se les pueda hacer una orden de compra indicando la moneda de origen.
Según el ejemplo anterior, se procedería así:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 4.05
Al hacer la orden de compra en plaza, se podrá modificar la moneda y la cotización correspondiente, entonces se desplegará como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 4.05) = 1.06, lo que SI es correcto.
Carlos A.L.Herrero
Análisis de Sistemas
Córdoba 93 (B1640GUA) Martínez - Bs.As.
República Argentina
Tel: 4792-2053 15-4473-6865
www.datacomsys.com.ar
www.datacomsys.blogspot.com
Detalle:
Se ha detectado un error que se produce al realizar una orden de compra, expresada por ejemplo en pesos; conteniendo productos costeados por ejemplo en dólares.
El error se visualiza en la forma de archivar lo que el sistema denomina como “costo de última compra”.
Datacomsys mantiene, para cada producto y lista de precios, la posibilidad de indicar la moneda en la que se expresa el costo.
En casos en que el producto se compra a un proveedor del exterior, la orden de compra solicita la moneda y la cotización, debiendo dicha moneda ser coincidente con la que se expresa como moneda de costo para cada uno de los productos; pero puede darse que en el legajo del producto y lista de precios, el costo se expresa por ejemplo en dólares, y la orden de compra se realiza a un proveedor de plaza, que por comodidad cotiza en dólares.
En este último caso, el costo de última compra queda archivado en forma errónea.
Explicación:
Al momento de hacer una orden de compra, el costo sugerido es el costo de reposición pesificado según la moneda que se haya indicado, en caso de ser pesos no habrá cálculo, pero en caso de ser otra moneda dicho costo se pesificara utilizando la cotización de la fecha.
Ahora bien, para guardar el costo de ultima compra se realiza el proceso inverso, el costo que se haya sugerido y aceptado, o bien modificado por otro nuevo, se vuelve a la moneda de costo utilizando la cotización indicada en la orden de compra, pero si la orden de compra es en plaza no hay cotización, la cotización será 1.000, o sea, guardará como costo de ultima compra el pesificado, ocasionando el error en los informes de valuación de inventario a costo de ultima compra, ya que dicho informe lo pesificará nuevamente.
Ejemplo:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 1.0000
Al hacer la orden de compra en plaza, se desplegara como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 1.000) = 4.293, lo que NO es correcto.
Solución:
A partir de la versión 110624 (24-06-2011), la orden de compra, por mas que sea realizada a un proveedor en plaza, solicitará moneda y cotización, de manera que aquellos proveedores cuyos costos son mantenidos en el sistema en otra moneda que pesos, se les pueda hacer una orden de compra indicando la moneda de origen.
Según el ejemplo anterior, se procedería así:
Producto X, moneda de costo dólares, costo 1.06, cotización dólar en sistema 4.05, cotización dólar en orden de compra 4.05
Al hacer la orden de compra en plaza, se podrá modificar la moneda y la cotización correspondiente, entonces se desplegará como costo (1.06 * 4.05) = 4.293, que es correcto.
Al guardar el costo de ultima compra se calculara (4.293 / 4.05) = 1.06, lo que SI es correcto.
Carlos A.L.Herrero
Análisis de Sistemas
Córdoba 93 (B1640GUA) Martínez - Bs.As.
República Argentina
Tel: 4792-2053 15-4473-6865
www.datacomsys.com.ar
www.datacomsys.blogspot.com
miércoles, 25 de mayo de 2011
Datacomsys version 110520
Modificaciones importantes en Datacomsys 7.4 Versión 110520
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Ventas
Facturación electrónica
Adaptación a webservices facturación electrónica versión 1.
Topes de crédito
Actualización automática evaluando volumen de venta.
Compras
Trabajar órdenes de compra pendientes
Explosión por código de producto.
Ingresos y egresos
Conciliaciones bancarias
Comparación de resumen Excel emitido por el banco, contra el sistema.
Afip
Trabajar cuits vencidos
Actualización automática de fecha de vencimiento.
Arciba
Incorporación en registro exportación, de retenciones hechas a proveedores.
Administracion de personal
Liquidaciones
Posibilidad de incorporar un texto, manualmente, en un recibo.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Adaptación a webservices facturación electrónica versión 1
Según se informó en un documento especifico, a partir del día 01-07-2011 y a nuestro entender, afip cambia el método de obtención del CAE para comprobantes electrónicos.
A partir de la versión 110520 el sistema esta adaptado para esta nueva modalidad.
La instalación de esta modificación NO es automática, tratándose de un tema impositivo y notificado por afip en una resolución especifica, la instalación de esta modificación debe ser solicitada por cada instalación.
Nuevamente sugerimos que cada responsable contacte a su respectivo estudio contable para conocer mas detalles, y tomar una decisión respecto a la instalación, en el menor tiempo posible.
Actualización automática de topes de crédito, evaluando volumen de venta
Se trata de un proceso automático, que al ejecutarse con cierta periodicidad, tiene le capacidad de evaluar en forma particular para cada instalación, el tope de crédito en cuenta corriente y valores para cada cliente.
Explosión por código de producto en panel trabajar ordenes de compra pendientes
El panel de trabajo de órdenes de compras pendientes, cuanta ahora con un botón inferior que permite explotar dichas ordenes, por código de producto.
Comparación de resumen Excel emitido por el banco contra el sistema
Se trata de un panel de trabajo, que cuenta con diversos controles que permiten incorporar un Excel generado por el banco correspondiente, y que cuente con los datos de movimientos bancarios; para luego compararlo contra el libro de bancos del sistema.
Finalmente se obtiene un panel con aquellos movimientos que no se han encontrado en el libro de bancos comparado.
Actualización automática de fecha de vencimiento de cuits clientes y proveedores
El panel de trabajo de cuits vencidos, al que se accede por el modulo de afip, cuenta con dos botones específicos que permiten cambiar, en forma automática, las fechas de vencimientos de cuits en legajos de clientes y proveedores, postergándolos a 180 días posteriores.
El procedimiento advierte sobre el riesgo jurídico que ocasiona postergar dicho vencimiento, ya que permitiría comerciar con un cliente o proveedor que no este en condiciones de hacerlo, según su condición en afip.
Incorporación en registro arciba de retenciones hechas a proveedores
El panel de trabajo Arciba, al que se accede desde el modulo afip, cuenta ahora con la posibilidad de incorporar en el registro de migración, a las retenciones que se han realizado en pagos a proveedores, correspondientes a la jurisdicción de C.A.B.A.
Posibilidad de incorporar un texto aleatorio en un recibo de sueldos
A efectos de poder agregar un texto manual y único en un recibo de sueldos, el procedimiento de modificación de liquidaciones cuenta con el agregado de un campo especial.
La impresión de dicho campo en el recibo correspondiente, deberá ser solicitada particularmente.
Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com
Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.
Ch 20-05-2011
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Ventas
Facturación electrónica
Adaptación a webservices facturación electrónica versión 1.
Topes de crédito
Actualización automática evaluando volumen de venta.
Compras
Trabajar órdenes de compra pendientes
Explosión por código de producto.
Ingresos y egresos
Conciliaciones bancarias
Comparación de resumen Excel emitido por el banco, contra el sistema.
Afip
Trabajar cuits vencidos
Actualización automática de fecha de vencimiento.
Arciba
Incorporación en registro exportación, de retenciones hechas a proveedores.
Administracion de personal
Liquidaciones
Posibilidad de incorporar un texto, manualmente, en un recibo.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Adaptación a webservices facturación electrónica versión 1
Según se informó en un documento especifico, a partir del día 01-07-2011 y a nuestro entender, afip cambia el método de obtención del CAE para comprobantes electrónicos.
A partir de la versión 110520 el sistema esta adaptado para esta nueva modalidad.
La instalación de esta modificación NO es automática, tratándose de un tema impositivo y notificado por afip en una resolución especifica, la instalación de esta modificación debe ser solicitada por cada instalación.
Nuevamente sugerimos que cada responsable contacte a su respectivo estudio contable para conocer mas detalles, y tomar una decisión respecto a la instalación, en el menor tiempo posible.
Actualización automática de topes de crédito, evaluando volumen de venta
Se trata de un proceso automático, que al ejecutarse con cierta periodicidad, tiene le capacidad de evaluar en forma particular para cada instalación, el tope de crédito en cuenta corriente y valores para cada cliente.
Explosión por código de producto en panel trabajar ordenes de compra pendientes
El panel de trabajo de órdenes de compras pendientes, cuanta ahora con un botón inferior que permite explotar dichas ordenes, por código de producto.
Comparación de resumen Excel emitido por el banco contra el sistema
Se trata de un panel de trabajo, que cuenta con diversos controles que permiten incorporar un Excel generado por el banco correspondiente, y que cuente con los datos de movimientos bancarios; para luego compararlo contra el libro de bancos del sistema.
Finalmente se obtiene un panel con aquellos movimientos que no se han encontrado en el libro de bancos comparado.
Actualización automática de fecha de vencimiento de cuits clientes y proveedores
El panel de trabajo de cuits vencidos, al que se accede por el modulo de afip, cuenta con dos botones específicos que permiten cambiar, en forma automática, las fechas de vencimientos de cuits en legajos de clientes y proveedores, postergándolos a 180 días posteriores.
El procedimiento advierte sobre el riesgo jurídico que ocasiona postergar dicho vencimiento, ya que permitiría comerciar con un cliente o proveedor que no este en condiciones de hacerlo, según su condición en afip.
Incorporación en registro arciba de retenciones hechas a proveedores
El panel de trabajo Arciba, al que se accede desde el modulo afip, cuenta ahora con la posibilidad de incorporar en el registro de migración, a las retenciones que se han realizado en pagos a proveedores, correspondientes a la jurisdicción de C.A.B.A.
Posibilidad de incorporar un texto aleatorio en un recibo de sueldos
A efectos de poder agregar un texto manual y único en un recibo de sueldos, el procedimiento de modificación de liquidaciones cuenta con el agregado de un campo especial.
La impresión de dicho campo en el recibo correspondiente, deberá ser solicitada particularmente.
Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com
Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.
Ch 20-05-2011
jueves, 3 de marzo de 2011
Datacomsys version 110225
Modificaciones importantes en Datacomsys 7.4 Versión 110225
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Comisiones por venta
Políticas de cálculo
Posibilidad de liquidar comisiones por un monto fijo
Inventario
Marbetes
Inicialización de marbetes
Posibilidad de inicializar marbetes para un solo punto de venta
Stock
Definición de rubros
Habilitaciones
Posibilidad de deshabilitar un rubro solamente para la venta
Ventas
Clientes
Legajo del cliente
Tilde para permitir o impedir el envió de SMS al celular del cliente
Incidentes
Contactos
Legajo del contacto
Tilde para permitir o impedir el envió de SMS al celular del contacto
Tipos de acciones
Legajos de tipos de acciones
Acción a tomar
Se incorpora una nueva acción a tomar, que emite un SMS.
Administracion de personal
Sicoss
Parámetros sicoss
Se incorpora un tilde para informar al aplicativo Sicoss, si se tiene o no seguro obligatorio.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Posibilidad de liquidar comisiones por un monto fijo
El módulo de comisiones utiliza políticas definidas para realizar los cálculos correspondientes.
Estas políticas finalmente determinan que porcentaje de comisión se aplicaba; ahora existe la posibilidad que lo que se aplique como comisión no sea un porcentaje sobre el neto del comprobante analizado sino un importe fijo.
Posibilidad de inicializar marbetes para un solo punto de venta
La inicialización de marbetes consiste en el borrado de los marbetes anteriores, a efectos de generar nuevos ante un próximo inventario.
La inicialización anterior eliminaba todos los marbetes que se hayan generado, independientemente del estado en que se encuentren y el punto de venta asociado.
Ante la necesidad de realizar inventarios parciales, se habilita la posibilidad de eliminar los marbetes anteriores de manera selectiva.
Si se ingresa como sucursal administrativa 9999, se eliminan todos los marbetes existentes, en cambio si se ingresa con una sucursal distinta, solamente se eliminan los marbetes de dicha sucursal. Todo esto previa confirmación por parte del operador.
Posibilidad de deshabilitar un rubro solamente para la venta
A la actividad de mantenimiento de códigos de rubros, se le agregó la posibilidad de definición si dicho rubro esta habilitado para la venta o no.
Anteriormente existía un tilde que inhabilitaba el rubro tanto para la venta como para la compra.
Ante la necesidad de tener rubros que por ejemplo contengan productos que no se venden, sean insumos o de uso interno, se agregó esta posibilidad.
Al momento de la instalación, el valor que se tomo por defecto es el que tiene la habilitación anterior.
Tilde para permitir o impedir el envió de SMS al celular del cliente
Siendo el envió de SMS un procedimiento que tiene cierto costo para el que lo recibe, se incorporo un tilde en el legajo del cliente que permite indicar si el mismo acepta o no el envió de SMS automáticos.
El contacto asociado, si es que lo hubiere, al cliente, heredara el valor de dicho tilde.
A la instalación, el valor que se determino automáticamente es No.
Tilde para permitir o impedir el envió de SMS al celular del contacto
Al igual que en el legajo del cliente, se incorpora un tilde que permite indicar si el contacto permite o no la recepción de SMS en su teléfono celular.
A la instalación, el valor que se determino automáticamente es No.
Tipo de acción SMS.
A los tipos de acciones a realizar en un incidente, se le agrega la posibilidad que dicha acción sea el envió de un SMS.
Es importante tener en cuenta que, para que se realice dicho envió, la instalación debe contar con un hardware denominado SMS Gateway, el que obviamente no es provisto por nosotros.
La modificación general de envió de SMS solamente consiste en agregar la posibilidad de administracion del envió del mismo en el sistema; siendo útil este procedimiento para confirmación de servicios terminados, alerta temprana de vencimientos, alarmas internas en general y otros.
Seguro obligatorio en SICOSS
A partir de la declaración jurada del mes de Enero 2011, el seguro obligatorio debe ser informado mediante el aplicativo SIAP / SICOSS.
Para tales efectos se debe indicar mediante un tilde en Administracion de personal, Liquidaciones, Parámetros sicoss, si se tiene o no un seguro obligatorio.
Pareciendo un absurdo, pero puede darse el caso que no se declare un seguro obligatorio.
Este valor se traslada al archivo de transferencia que se utiliza para la declaración automática de liquidaciones en el mencionado aplicativo.
Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com
Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.
Ch 25-02-2011
Títulos correspondientes a modificaciones y agregados realizados para esta versión.
Comisiones por venta
Políticas de cálculo
Posibilidad de liquidar comisiones por un monto fijo
Inventario
Marbetes
Inicialización de marbetes
Posibilidad de inicializar marbetes para un solo punto de venta
Stock
Definición de rubros
Habilitaciones
Posibilidad de deshabilitar un rubro solamente para la venta
Ventas
Clientes
Legajo del cliente
Tilde para permitir o impedir el envió de SMS al celular del cliente
Incidentes
Contactos
Legajo del contacto
Tilde para permitir o impedir el envió de SMS al celular del contacto
Tipos de acciones
Legajos de tipos de acciones
Acción a tomar
Se incorpora una nueva acción a tomar, que emite un SMS.
Administracion de personal
Sicoss
Parámetros sicoss
Se incorpora un tilde para informar al aplicativo Sicoss, si se tiene o no seguro obligatorio.
Detalles correspondientes a modificaciones y agregados realizados para esta versión
Posibilidad de liquidar comisiones por un monto fijo
El módulo de comisiones utiliza políticas definidas para realizar los cálculos correspondientes.
Estas políticas finalmente determinan que porcentaje de comisión se aplicaba; ahora existe la posibilidad que lo que se aplique como comisión no sea un porcentaje sobre el neto del comprobante analizado sino un importe fijo.
Posibilidad de inicializar marbetes para un solo punto de venta
La inicialización de marbetes consiste en el borrado de los marbetes anteriores, a efectos de generar nuevos ante un próximo inventario.
La inicialización anterior eliminaba todos los marbetes que se hayan generado, independientemente del estado en que se encuentren y el punto de venta asociado.
Ante la necesidad de realizar inventarios parciales, se habilita la posibilidad de eliminar los marbetes anteriores de manera selectiva.
Si se ingresa como sucursal administrativa 9999, se eliminan todos los marbetes existentes, en cambio si se ingresa con una sucursal distinta, solamente se eliminan los marbetes de dicha sucursal. Todo esto previa confirmación por parte del operador.
Posibilidad de deshabilitar un rubro solamente para la venta
A la actividad de mantenimiento de códigos de rubros, se le agregó la posibilidad de definición si dicho rubro esta habilitado para la venta o no.
Anteriormente existía un tilde que inhabilitaba el rubro tanto para la venta como para la compra.
Ante la necesidad de tener rubros que por ejemplo contengan productos que no se venden, sean insumos o de uso interno, se agregó esta posibilidad.
Al momento de la instalación, el valor que se tomo por defecto es el que tiene la habilitación anterior.
Tilde para permitir o impedir el envió de SMS al celular del cliente
Siendo el envió de SMS un procedimiento que tiene cierto costo para el que lo recibe, se incorporo un tilde en el legajo del cliente que permite indicar si el mismo acepta o no el envió de SMS automáticos.
El contacto asociado, si es que lo hubiere, al cliente, heredara el valor de dicho tilde.
A la instalación, el valor que se determino automáticamente es No.
Tilde para permitir o impedir el envió de SMS al celular del contacto
Al igual que en el legajo del cliente, se incorpora un tilde que permite indicar si el contacto permite o no la recepción de SMS en su teléfono celular.
A la instalación, el valor que se determino automáticamente es No.
Tipo de acción SMS.
A los tipos de acciones a realizar en un incidente, se le agrega la posibilidad que dicha acción sea el envió de un SMS.
Es importante tener en cuenta que, para que se realice dicho envió, la instalación debe contar con un hardware denominado SMS Gateway, el que obviamente no es provisto por nosotros.
La modificación general de envió de SMS solamente consiste en agregar la posibilidad de administracion del envió del mismo en el sistema; siendo útil este procedimiento para confirmación de servicios terminados, alerta temprana de vencimientos, alarmas internas en general y otros.
Seguro obligatorio en SICOSS
A partir de la declaración jurada del mes de Enero 2011, el seguro obligatorio debe ser informado mediante el aplicativo SIAP / SICOSS.
Para tales efectos se debe indicar mediante un tilde en Administracion de personal, Liquidaciones, Parámetros sicoss, si se tiene o no un seguro obligatorio.
Pareciendo un absurdo, pero puede darse el caso que no se declare un seguro obligatorio.
Este valor se traslada al archivo de transferencia que se utiliza para la declaración automática de liquidaciones en el mencionado aplicativo.
Las consultas que surjan sobre estos u otros temas relacionados al sistema, por favor enviarlas a informes@carlosherrero.com.ar o consultar www.datacomsys.blogspot.com
Verifique si su instalación ha podido ser actualizada ingresando en Parámetros y clickeando en “Acerca de Datacomsys”, en caso que el numero de versión no coincida con la de este informe solicitamos que lo reporte por correo electrónico.
Recordamos la necesidad de respaldar en CD, DVD o en otro equipo, el archivo .bck generado automáticamente por el proceso de backup diario.
Ch 25-02-2011
domingo, 3 de octubre de 2010
Vacaciones
Administracion de personal
Procedimiento para Liquidación de vacaciones
Generalidades:
El sistema mantiene los días de vacaciones que correspondan en forma de cuenta corriente.
Dicha cuenta corriente se genera en base a la cantidad de días que el empleado tiene asignados según su antigüedad y convenio, a los que se le aplica los días que se va tomando en base a las liquidaciones de vacaciones realizadas.
A tales efectos existe un procedimiento de mantenimiento de datos parametrizados, referentes a los convenios y la cantidad de días por año trabajado, así como la información al sistema de los días que efectivamente el empleado se toma.
Luego, la liquidación de vacaciones, mediante un concepto con una formula especial, se encarga de incorporar estos días en la liquidación, para que finalmente al confirmarla, se descuenten efectivamente estos días de la cuenta corriente por vacaciones del empleado.
Este documento se complementa con el que corresponde a Incidentes en general, ya que el sistema toma a las vacaciones como un incidente mas.
Parametrizacion inicial:
Definir la cantidad de días por año trabajado según convenio
Para poder establecer la cantidad de días que un empleado tiene asignados según su antigüedad, es necesario establecer los parámetros correspondientes a la relación de convenio y días trabajados.
A tales efectos, se deben incorporar estos datos accediendo por (Personal), botón lateral (Convenios), seleccionar el convenio que se quiere definir y clickear en (días / Vacaciones).
En esta actividad se debe definir: Año desde, Año hasta, y cantidad de días.
Ejemplo para Empleados de comercio:
1 a 4 años, corresponde 14 días
5 a 9 años, corresponden 21 días
10 a 19 años, corresponden 28 días
20 a 99 años, corresponden 35 días
Atención: para cualquier convenio el sistema adopta como año completo al legajo con fecha de apertura entre el primero de enero y el treinta de junio, para ingresos posteriores se asume un día por cada veinte trabajados.
Cálculo automático de días según convenio y años trabajados
Este proceso permite calcular en base a la fecha de ingreso en el legajo, y una fecha base o de cálculo, la cantidad de días que corresponden por vacaciones.
El cálculo obtenido se incorpora como movimiento en la cuenta corriente de vacaciones asociada al legajo.
Para utilizar este proceso, se accede por (Personal), botón superior (Vacaciones) y luego botón central (Calculo por convenio).
Una vez ingresado se debe indicar la fecha de calculo, ejemplo 31-12-2010, y si calcula para todos los legajos activos o no.
Al confirmar se procederá a evaluar en función de la fecha de ingreso en el legajo, y el convenio asociado, la cantidad de días que le corresponden al empleado.
El cálculo obtenido se incorporará como movimiento en la cuenta corriente por vacaciones de cada legajo.
Se lo visualizara como un Debito, por la cantidad de días que corresponda, y con leyenda “Calculo automático vacaciones base: DD/MM/AAAA.
En casos especiales donde esta relación entre convenio y años de trabajo no se respeta, por ejemplo por reconocimiento de antigüedad en empleos anteriores, se deberá proceder a realizar un ajuste manual en la cuenta corriente de vacaciones relacionada.
Tipo de incidente para vacaciones:
Para que el procedimiento de cálculo obtenga los días de vacaciones que un empleado se toma, es necesario indicar estos días en forma de incidente.
Cada incidente tiene asociado un tipo, por lo que se debe definir un tipo de incidente especial para esta operatoria.
Los tipos de incidentes se definen desde (Personal), botón superior (Incidentes), botón lateral (Tipos incidentes).
Una vez accedidos a la aplicación se le deberá dar un código y diversos datos según este ejemplo:
Código : LVAC
Descripción: Licencia por vacaciones
Tildar en “Queda pendiente de liquidar y se liquida como”
Tipo de liquidación asociada: 5-Liquidación de vacaciones
Tildar en “Modifica situación de revista como”
Situación de revista 12-Licencia vacaciones
Tildar en “Implica ausencia”
Tildar en “Requiere cerrar el incidente”
Tildar en “Evalúa cantidad de días contra cuenta corriente vacaciones”
Rango máximo en días: 35
Una vez confirmado el tipo de incidente, el mismo esta disponible para ser utilizado y liquidado.
Concepto de liquidación especial:
Para que la cantidad de días incidentados sean evaluada en una liquidación, se debe dar de alta un concepto especial.
Dicho concepto se da de alta desde (Conceptos) y luego (Nuevo concepto)
Una vez en la actividad se debe dar de alta un concepto especial según el siguiente ejemplo:
Código 000089
Tildar en “Habilitado”
Descripción: VACACIONES
Tipo: H-haber
Se utiliza como: A-Concepto fijo o novedad
Tildar en “Se le aplican descuentos”
Formula:
La formula utiliza la palabra clave INCIDE, que se utiliza para realizar la evaluación de un incidente dado, en este caso vacaciones; así como otros argumentos para obtener el sueldo del empleado.
Básicamente para una empresa que utiliza escalafones la formula podría ser:
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LICVAC;ULT )
O expresado en forma textual:
( ( ( Escalafón JF evaluado por categoría en legajo) / 25 ) * Cantidad de días ultima Licencia por vacaciones )
De esta manera el proceso de liquidación obtendría la cantidad de días localizando en los incidentes del legajo, el último con tipo de incidente LICVAC, dentro del rango de fechas definidas como Periodo de la liquidación .
Procedimiento de liquidación :
Generar el incidente de vacaciones
Antes de proceder a la liquidación de vacaciones se debe generar el incidente que, en definitiva, indicará al sistema la cantidad de días que el empleado se toma.
Los días indicados en el incidente se validarán contra el saldo de la cuenta corriente de vacaciones asociada al legajo, y contra la cantidad máxima de días corridos que la empresa otorga, esto ultimo definido en el tipo de incidente asociado.
Para proceder a cargar el incidente, se debe acceder desde (Personal), localizando el legajo que se quiere incidentar, y luego clickear en (Incidentes), para finalmente clickear en (Nuevo).
Como tipo de incidente se debe indicar el que corresponda a licencia por vacaciones, LVAC según el ejemplo anteriormente descrito.
Como fecha se debe aceptar la que se sugiere, ya que no tiene relevancia para las vacaciones, siendo solamente la fecha de generación del incidente.
Como fecha de inicio se debe indicar la que corresponda al primer día de vacaciones otorgadas.
Como fecha final se debe indicar la última que corresponda al periodo de vacaciones otorgadas.
La cantidad de días que media entre ambas fechas es validada contra el saldo de la cuenta corriente de vacaciones, así como contra la cantidad máxima de días corridos que la empresa permita.
Luego se pueden indicar datos de referencia o detalle, pero básicamente no son obligatorios para este tipo de incidente, según lo que se parametrizó en el tipo de incidente LVAC.
Al confirmar el incidente, el mismo se numerará y se desplegará en la grilla de incidentes por legajo.
El incidente quedará con estado “Abierto”, y puede ser modificado o anulado hasta que sea incorporado en una liquidación y la misma este en estado “Cerrada”.
Si un incidente es modificado habiendo sido incorporado en una liquidación, esta última deberá ser reprocesada.
Si la liquidación se encuentra en estado 4 o 5 , el incidente ya no podrá ser modificado.
Liquidar el incidente de vacaciones:
Una vez generado el incidente, y teniendo el concepto de liquidación definido como se explico en el ejemplo anterior, bastará incorporarlo como novedad, y proceder a calcular la liquidación para que la cantidad de días que median en el incidente sea tomada como la cantidad de días de vacaciones.
Los incidentes a liquidar se incorporan evaluándolos de manera que sus fechas de inicio y final estén dentro de las fechas definidas como “Periodo inicial” y “Periodo final”, de la definición de la liquidación.
Luego de procesar la liquidación se podrá ver en (Ver liquidación), que el concepto asociado evaluó la formula.
Según el ejemplo anterior, este concepto habrá obtenido el sueldo por el escalafón y luego de dividirlo por 25, lo multiplico por la cantidad de días que median entre la fecha de inicio y final del ultimo incidente LVAC.
Confirmar liquidación de vacaciones:
El procedimiento de confirmación de la liquidación de vacaciones es similar a cualquier otra, lo que si se produce es una actualización en los incidentes de vacaciones asociados, así como en la cuenta corriente de vacaciones por legajo.
En el caso de los incidentes, se verá que el incidente de vacaciones, LVAC en el ejemplo que estamos trabajando, quedará con estado “Cerrado”, y con un número de liquidación asociada.
Una vez en este estado el incidente solo podrá ser consultado.
Para la cuenta corriente de vacaciones, se habrá generado un crédito con la fecha de la liquidación, por la cantidad de días que se hayan liquidado, y con leyenda “Confirmación liquidación nnnnn”, donde nnnnn es el numero de liquidación asociada.
Dicho crédito modificará el saldo de días asociado al legajo.
Ajustes y Nuevo periodo de vacaciones:
Para incrementar el saldo de vacaciones, por ejemplo al cambiar el año, o bien se puede realizar un ajuste manual en la cuenta corriente, o bien correr nuevamente el proceso “Calcular por convenio”, indicando como fecha base la que corresponda al final del nuevo año.
Este proceso calculará nuevamente en función del convenio y fecha de ingreso, e incrementará el saldo de vacaciones en función de los días calculados.
Si se desea hacer el ajuste manual, se procede desde (Personal), localizando el legajo asociado y clickeando en (Vacaciones), para finalmente en (Nuevo registro).
Se solicita la fecha de registro y la cantidad de días que se ajustan, pudiendo ser con signo negativo para el caso de restar días.
Ch 20-09-2010
Procedimiento para Liquidación de vacaciones
Generalidades:
El sistema mantiene los días de vacaciones que correspondan en forma de cuenta corriente.
Dicha cuenta corriente se genera en base a la cantidad de días que el empleado tiene asignados según su antigüedad y convenio, a los que se le aplica los días que se va tomando en base a las liquidaciones de vacaciones realizadas.
A tales efectos existe un procedimiento de mantenimiento de datos parametrizados, referentes a los convenios y la cantidad de días por año trabajado, así como la información al sistema de los días que efectivamente el empleado se toma.
Luego, la liquidación de vacaciones, mediante un concepto con una formula especial, se encarga de incorporar estos días en la liquidación, para que finalmente al confirmarla, se descuenten efectivamente estos días de la cuenta corriente por vacaciones del empleado.
Este documento se complementa con el que corresponde a Incidentes en general, ya que el sistema toma a las vacaciones como un incidente mas.
Parametrizacion inicial:
Definir la cantidad de días por año trabajado según convenio
Para poder establecer la cantidad de días que un empleado tiene asignados según su antigüedad, es necesario establecer los parámetros correspondientes a la relación de convenio y días trabajados.
A tales efectos, se deben incorporar estos datos accediendo por (Personal), botón lateral (Convenios), seleccionar el convenio que se quiere definir y clickear en (días / Vacaciones).
En esta actividad se debe definir: Año desde, Año hasta, y cantidad de días.
Ejemplo para Empleados de comercio:
1 a 4 años, corresponde 14 días
5 a 9 años, corresponden 21 días
10 a 19 años, corresponden 28 días
20 a 99 años, corresponden 35 días
Atención: para cualquier convenio el sistema adopta como año completo al legajo con fecha de apertura entre el primero de enero y el treinta de junio, para ingresos posteriores se asume un día por cada veinte trabajados.
Cálculo automático de días según convenio y años trabajados
Este proceso permite calcular en base a la fecha de ingreso en el legajo, y una fecha base o de cálculo, la cantidad de días que corresponden por vacaciones.
El cálculo obtenido se incorpora como movimiento en la cuenta corriente de vacaciones asociada al legajo.
Para utilizar este proceso, se accede por (Personal), botón superior (Vacaciones) y luego botón central (Calculo por convenio).
Una vez ingresado se debe indicar la fecha de calculo, ejemplo 31-12-2010, y si calcula para todos los legajos activos o no.
Al confirmar se procederá a evaluar en función de la fecha de ingreso en el legajo, y el convenio asociado, la cantidad de días que le corresponden al empleado.
El cálculo obtenido se incorporará como movimiento en la cuenta corriente por vacaciones de cada legajo.
Se lo visualizara como un Debito, por la cantidad de días que corresponda, y con leyenda “Calculo automático vacaciones base: DD/MM/AAAA.
En casos especiales donde esta relación entre convenio y años de trabajo no se respeta, por ejemplo por reconocimiento de antigüedad en empleos anteriores, se deberá proceder a realizar un ajuste manual en la cuenta corriente de vacaciones relacionada.
Tipo de incidente para vacaciones:
Para que el procedimiento de cálculo obtenga los días de vacaciones que un empleado se toma, es necesario indicar estos días en forma de incidente.
Cada incidente tiene asociado un tipo, por lo que se debe definir un tipo de incidente especial para esta operatoria.
Los tipos de incidentes se definen desde (Personal), botón superior (Incidentes), botón lateral (Tipos incidentes).
Una vez accedidos a la aplicación se le deberá dar un código y diversos datos según este ejemplo:
Código : LVAC
Descripción: Licencia por vacaciones
Tildar en “Queda pendiente de liquidar y se liquida como”
Tipo de liquidación asociada: 5-Liquidación de vacaciones
Tildar en “Modifica situación de revista como”
Situación de revista 12-Licencia vacaciones
Tildar en “Implica ausencia”
Tildar en “Requiere cerrar el incidente”
Tildar en “Evalúa cantidad de días contra cuenta corriente vacaciones”
Rango máximo en días: 35
Una vez confirmado el tipo de incidente, el mismo esta disponible para ser utilizado y liquidado.
Concepto de liquidación especial:
Para que la cantidad de días incidentados sean evaluada en una liquidación, se debe dar de alta un concepto especial.
Dicho concepto se da de alta desde (Conceptos) y luego (Nuevo concepto)
Una vez en la actividad se debe dar de alta un concepto especial según el siguiente ejemplo:
Código 000089
Tildar en “Habilitado”
Descripción: VACACIONES
Tipo: H-haber
Se utiliza como: A-Concepto fijo o novedad
Tildar en “Se le aplican descuentos”
Formula:
La formula utiliza la palabra clave INCIDE, que se utiliza para realizar la evaluación de un incidente dado, en este caso vacaciones; así como otros argumentos para obtener el sueldo del empleado.
Básicamente para una empresa que utiliza escalafones la formula podría ser:
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LICVAC;ULT )
O expresado en forma textual:
( ( ( Escalafón JF evaluado por categoría en legajo) / 25 ) * Cantidad de días ultima Licencia por vacaciones )
De esta manera el proceso de liquidación obtendría la cantidad de días localizando en los incidentes del legajo, el último con tipo de incidente LICVAC, dentro del rango de fechas definidas como Periodo de la liquidación .
Procedimiento de liquidación :
Generar el incidente de vacaciones
Antes de proceder a la liquidación de vacaciones se debe generar el incidente que, en definitiva, indicará al sistema la cantidad de días que el empleado se toma.
Los días indicados en el incidente se validarán contra el saldo de la cuenta corriente de vacaciones asociada al legajo, y contra la cantidad máxima de días corridos que la empresa otorga, esto ultimo definido en el tipo de incidente asociado.
Para proceder a cargar el incidente, se debe acceder desde (Personal), localizando el legajo que se quiere incidentar, y luego clickear en (Incidentes), para finalmente clickear en (Nuevo).
Como tipo de incidente se debe indicar el que corresponda a licencia por vacaciones, LVAC según el ejemplo anteriormente descrito.
Como fecha se debe aceptar la que se sugiere, ya que no tiene relevancia para las vacaciones, siendo solamente la fecha de generación del incidente.
Como fecha de inicio se debe indicar la que corresponda al primer día de vacaciones otorgadas.
Como fecha final se debe indicar la última que corresponda al periodo de vacaciones otorgadas.
La cantidad de días que media entre ambas fechas es validada contra el saldo de la cuenta corriente de vacaciones, así como contra la cantidad máxima de días corridos que la empresa permita.
Luego se pueden indicar datos de referencia o detalle, pero básicamente no son obligatorios para este tipo de incidente, según lo que se parametrizó en el tipo de incidente LVAC.
Al confirmar el incidente, el mismo se numerará y se desplegará en la grilla de incidentes por legajo.
El incidente quedará con estado “Abierto”, y puede ser modificado o anulado hasta que sea incorporado en una liquidación y la misma este en estado “Cerrada”.
Si un incidente es modificado habiendo sido incorporado en una liquidación, esta última deberá ser reprocesada.
Si la liquidación se encuentra en estado 4 o 5 , el incidente ya no podrá ser modificado.
Liquidar el incidente de vacaciones:
Una vez generado el incidente, y teniendo el concepto de liquidación definido como se explico en el ejemplo anterior, bastará incorporarlo como novedad, y proceder a calcular la liquidación para que la cantidad de días que median en el incidente sea tomada como la cantidad de días de vacaciones.
Los incidentes a liquidar se incorporan evaluándolos de manera que sus fechas de inicio y final estén dentro de las fechas definidas como “Periodo inicial” y “Periodo final”, de la definición de la liquidación.
Luego de procesar la liquidación se podrá ver en (Ver liquidación), que el concepto asociado evaluó la formula.
Según el ejemplo anterior, este concepto habrá obtenido el sueldo por el escalafón y luego de dividirlo por 25, lo multiplico por la cantidad de días que median entre la fecha de inicio y final del ultimo incidente LVAC.
Confirmar liquidación de vacaciones:
El procedimiento de confirmación de la liquidación de vacaciones es similar a cualquier otra, lo que si se produce es una actualización en los incidentes de vacaciones asociados, así como en la cuenta corriente de vacaciones por legajo.
En el caso de los incidentes, se verá que el incidente de vacaciones, LVAC en el ejemplo que estamos trabajando, quedará con estado “Cerrado”, y con un número de liquidación asociada.
Una vez en este estado el incidente solo podrá ser consultado.
Para la cuenta corriente de vacaciones, se habrá generado un crédito con la fecha de la liquidación, por la cantidad de días que se hayan liquidado, y con leyenda “Confirmación liquidación nnnnn”, donde nnnnn es el numero de liquidación asociada.
Dicho crédito modificará el saldo de días asociado al legajo.
Ajustes y Nuevo periodo de vacaciones:
Para incrementar el saldo de vacaciones, por ejemplo al cambiar el año, o bien se puede realizar un ajuste manual en la cuenta corriente, o bien correr nuevamente el proceso “Calcular por convenio”, indicando como fecha base la que corresponda al final del nuevo año.
Este proceso calculará nuevamente en función del convenio y fecha de ingreso, e incrementará el saldo de vacaciones en función de los días calculados.
Si se desea hacer el ajuste manual, se procede desde (Personal), localizando el legajo asociado y clickeando en (Vacaciones), para finalmente en (Nuevo registro).
Se solicita la fecha de registro y la cantidad de días que se ajustan, pudiendo ser con signo negativo para el caso de restar días.
Ch 20-09-2010
Incidentes en legajos empleados
Administracion de personal
Incidentes sobre legajos
Generalidades:
A efectos de poder realizar un control y seguimiento de las distintas situaciones que hacen a un legajo, el sistema permite definir y mantener ciertos datos en forma de incidentes.
Estos incidentes se relacionan al legajo de un empleado y son visualizados en forma de grilla.
Los incidentes se tipifican mediante un código de tipo de incidente, y son numerados en forma automática y secuencial.
Los incidentes sobre legajos no tienen relación alguna con el modulo de incidentes del sistema administrativo.
Parametrizacion inicial:
Tipos de incidentes:
La parametrizacion de los tipos de incidentes permite definir distintos códigos que actúan de una manera u otra, a efectos que, al ingresar el incidente asociado a un legajo, se solicitan ciertos datos y acciones de manera obligatoria.
Para definir los tipos de incidentes se accede desde (Personal), botón superior (Incidentes), y finalmente botón lateral (Tipos incidentes).
Se desplegará un panel de trabajo con todos los tipos de incidentes definidos.
Una vez clickeado en (Nuevo), y ya en la actividad se solicitan diversos datos :
Código : Se refiere al código que identificará al tipo de incidente.
Descripción: Es la descripción del tipo de incidente.
Queda pendiente de liquidar y se liquida como: Es un tilde que internamente actúa por si o por no.
Si el incidente queda pendiente de liquidar, podrá ser utilizado en una liquidación del tipo asociado.
Modifica situación de revista como : Es un tilde que internamente actúa por si o por no.
Si el incidente modifica la situación de revista, podrá ser utilizado desde el panel de trabajo de incidentes para proceder a modificar la situación de revista de un legajo.
Implica ausencia : Es un tilde que internamente actúa por si o por no.
Requiere certificado / Justificación : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitará o no cierta información al ingresar o cerrar el incidente.
Requiere visita a domicilio : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitara o no cierta información al ingresar o cerrar el incidente.
Requiere cerrar el incidente : Es un tilde por si o por no, y que permitirá dejar al incidente como pendiente de cierre, para un posterior cierre manual o a través de una liquidación, o bien dejará al incidente como cerrado en el mismo ingreso.
Referencia obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto de referencia.
Detalle Obligatorio : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto detallando el mismo.
Dar aviso a ART: Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingresen los datos asociados a la ART.
Solución obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto en el campo de solución.
Evalúa cantidad de días contra cuenta corriente de vacaciones : Es un tilde por si o por no, y que permite que, al momento de ingresar un incidente, las fechas de inicio y final del mismo sean evaluadas en su cantidad contra el saldo de la cuenta corriente de vacaciones asociada al legajo.
Para una mejor explicación se provee un documento especial para liquidación de vacaciones.
Rango máximo de días : Es la cantidad de días máxima que puede mediar entre la fecha inicial y final de un incidente, y solo a efectos que, al momento de ingresar un incidente, la cantidad de días que media entre la fecha inicial y final, no supere dicho numero.
Como ejemplos de tipos de incidentes, podemos aplicar que :
Un accidente laboral, implica ausencia, no queda pendiente de liquidar, modifica la situación de revista, requiere una visita al domicilio por parte del medico, requiere cerrar el incidente, tiene referencia y detalle obligatorio, se debe dar aviso a la ART y no tiene un rango máximo de días.
Una ausencia con aviso, no queda pendiente de liquidar, no modifica la situación de revista, implica una ausencia, requiere un certificado o justificación, no requiere visita a domicilio, requiere cerrar el incidente, requiere una referencia y detalle, no da aviso a la ART, no requiere de una solución, no evalúa la cantidad de días de vacaciones, y tiene un rango máximo de 1 día.
Una licencia por vacaciones queda pendiente de liquidar, modifica la situación de revista, implica una ausencia, no requiere certificado, no requiere visita a domicilio, requiere cerrar el incidente, no tiene referencia, detalle ni solución, evalúa la cantidad de días contra la cuenta corriente de vacaciones, y tiene un máximo de 35 días.
Y así las distintas combinaciones posibles o necesarias.
Dar de alta un incidente :
Para dar de alta un incidente, se debe acceder desde (Personal), seleccionar en la grilla el legajo que se asociara al incidente y clickear en (Incidentes), se desplegará una grilla con los incidentes asociados al legajo en forma inversa, el mas cercano primero, la grilla podrá ser filtrada para obtener solamente los vigentes, los anulados o todos, también se podrá filtrar por tipo de incidente.
Para dar de alta un nuevo incidente, se deberá clickear en (Nuevo).
Lo primero que se debe indicar es el tipo de incidente a ingresar, debido a que precisamente el tipo de incidente determinará que datos son obligatorios y cuales no.
Luego se sugiere la fecha del día, que indica básicamente la fecha del incidente.
Fecha de inicio y fecha final se refieren al comienzo y finalización del incidente, en el caso de una licencia por maternidad será la fecha de comienzo y finalización de dicha licencia, lo mismo para el caso de vacaciones; en el caso de una ausencia será la misma fecha en ambos datos.
La cantidad de días que media entre una fecha y otra será validada contra la cantidad máxima de días que tiene definido el tipo de incidente.
La solapa “Incidente” permite dejar constancia del incidente en si.
Referencia es un titulo o descripción corta del incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Detalle es un texto donde se debería explicar el incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Resolución es un texto donde se debería explicar la solución del incidente, y será obligatorio su ingreso si así se ha definido en el tipo de incidente asociado.
Adjunto permite ingresar o buscar un documento externo al sistema, ejemplo una amonestación o suspensión hecha en un procesador de texto, y dejarla asociada al incidente para su consulta o seguimiento.
La solapa “Médico” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha y hora de visita se refiere al momento en que el médico efectuó la visita en el domicilio del
Paciente.
Nombre del profesional se refiere al nombre del médico que ha visitado al paciente.
Resultado / Observaciones es un texto que sirve de aclaración al incidente.
Los datos médicos son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “Certificados” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha de certificado se refiere precisamente a la fecha que consta en el certificado presentado
Observaciones es un texto que puede servir de aclaración al incidente
Los datos sobre certificados son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “ART” permite dejar constancia del aviso del siniestro a la ART que corresponda.
Fecha y hora de aviso se refiere precisamente al momento en que el incidente es declarado a la ART
Atendió / Contacto / Nombre se refiere a la persona de la ART que nos ha relevado el incidente .
Número de siniestro es el número que otorga la ART al incidente y servirá para referencias posteriores.
Observaciones es un texto que sirve de aclaración a la denuncia del incidente a la ART
Los datos de fecha, contacto y número de siniestro son obligatorios si así se ha definido en el tipo de incidente y se pretende cerrar el mismo.
La solapa “Abogados” permite dejar constancia sobre datos asociados a situaciones que requieran la intervención de un abogado.
Nombre profesional se refiere precisamente al nombre del abogado asociado.
Observaciones es un texto que sirve de aclaración.
La solapa “Situación de revista” permite establecer que tipo de situación de revista esta asociada al incidente.
Situación de revista se refiere a la situación en que el empleado ingresa a partir de la incorporación del incidente, la misma es sugerida en base a lo definido en tipos de incidente, pudiendo también ser modificada por el operador que esta ingresando el incidente.
Si el tipo de incidente no tiene indicado que modifica la situación de revista, este dato no será tenido en cuenta.
La aplicación de estas situaciones de revista a cada legajo, para su migración al aplicativo Sicoss, se explica en documento aparte.
La solapa “Liquidación” permite establecer en que tipo de liquidación se ha de procesar el incidente.
Tipo de liquidación asociada se refiere precisamente al tipo de liquidación en que el incidente será evaluado e incorporado.
El tipo de liquidación sugerido se obtiene de lo que se haya parametrizado en la definición del tipo de incidente.
Si el tipo de incidente no tiene indicado que es liquidable, este dato no será tenido en cuenta.
La solapa “Cierre” mantiene datos asociados al cierre del incidente.
Marca el incidente como cerrado se refiere precisamente al hecho de cerrar el incidente y que el mismo no pueda ser modificado.
Al pretender cerrar el incidente se evaluarán los contenidos de ciertos datos según lo parametrizado en el tipo de incidente asociado.
Los incidentes que son liquidables se cerrarán automáticamente al confirmar la liquidación asociada sin necesidad de cerrarlos en forma manual.
Al confirmar el incidente el mismo quedará archivado asociado al legajo, y podrá ser visualizado en la grilla asociada al legajo o bien en la general de incidentes.
Modificar un incidente :
Para modificar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Modificar)
No se podrá modificar un incidente cerrado o anulado.
Anular un incidente:
Para anular un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Anular).
No se podrá anular un incidente cerrado o ya anulado con anterioridad.
Los incidentes anulados no serán tenidos en cuenta en una liquidación
Consultar un incidente
Para consultar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Consultar)
Liquidar un incidente :
Los incidentes que en su tipo hayan sido definidos como Liquidables, podrán ser utilizados en una liquidación mediante la utilización de un tipo de formula especial.
Dicho tipo de formula tiene la particularidad de localizar el incidente y obtener la cantidad de días que median entre la fecha de inicio del mismo y la fecha final.
Estas fechas deben estar dentro del rango de aquellas definidas en la liquidación que los va a utilizar.
O sea, al momento de definir una liquidación se solicita el periodo inicial y el periodo final, dichas fechas sirven, entre otras cosas, para obtener incidentes pendientes de liquidación , con fecha de inicio y final dentro de dicho rango.
Formulas utilizando incidentes:
Para poder utilizar días de un incidente en una formula, se utiliza la palabra clave INCIDE
INCIDE es la palabra clave que permite ser incorporada como argumento dentro de una formula de un concepto de liquidación.
INCIDE va seguido del código del tipo de incidente a evaluar y un modificador respecto a que es lo que debe hacer en lo referente a : localizar el último incidente y tipo, localizar el primer incidente y tipo, o bien realizar la sumatoria de días de dicho incidente dentro del periodo de la liquidación.
Sintaxis :
INCIDE;{TIPO DE INCIDENTE};{modificador}
INCIDE es la palabra clave
TIPO DE INCIDENTE se refiere a un código de tipo de incidente definido.
Modificador se refiere a la forma de evaluar el incidente, pudiendo ser :
ULT : cantidad de días del ultimo incidente del tipo indicado.
PRI : cantidad de días del primer incidente del tipo indicado
SUM: sumatoria de días de todos los incidentes del tipo indicado.
Ejemplos:
Vacaciones
Suponiendo que el tipo de incidente para licencia por vacaciones sea LICVAC
INCIDE;LICVAC;ULT
Devolverá la cantidad de días del último incidente LICVAC
Entonces podría ser utilizado de esta manera
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LVAC;ULT )
Calculando el valor de las vacaciones obteniendo el sueldo según escalafón “JF”, evaluado por categoría en legajo y dividido 25 multiplicado por la cantidad de días del ultimo incidente LVAC asociado al legajo
Ausencias sin aviso
Suponiendo que el tipo de incidente para ausencias sin aviso sea AUSEN1
INCIDE:AUSEN1;SUM
Devolverá la sumatoria de los días de todos los incidentes del tipo AUSEN1 en el periodo que abarque la liquidación.
Entonces podría ser utilizado de esta manera
( ( ( ( ESCALA;”JF”;CATEGO ) / 30 * INCIDE;AUSEN1;SUM ) * - 1 )
Calculando el valor a restar obteniendo el sueldo del escalafón JF evaluado por categoría, dividiéndolo por 30 y multiplicándolo por la cantidad de ausencias dentro del periodo.
Ch 20-09-2010
Incidentes sobre legajos
Generalidades:
A efectos de poder realizar un control y seguimiento de las distintas situaciones que hacen a un legajo, el sistema permite definir y mantener ciertos datos en forma de incidentes.
Estos incidentes se relacionan al legajo de un empleado y son visualizados en forma de grilla.
Los incidentes se tipifican mediante un código de tipo de incidente, y son numerados en forma automática y secuencial.
Los incidentes sobre legajos no tienen relación alguna con el modulo de incidentes del sistema administrativo.
Parametrizacion inicial:
Tipos de incidentes:
La parametrizacion de los tipos de incidentes permite definir distintos códigos que actúan de una manera u otra, a efectos que, al ingresar el incidente asociado a un legajo, se solicitan ciertos datos y acciones de manera obligatoria.
Para definir los tipos de incidentes se accede desde (Personal), botón superior (Incidentes), y finalmente botón lateral (Tipos incidentes).
Se desplegará un panel de trabajo con todos los tipos de incidentes definidos.
Una vez clickeado en (Nuevo), y ya en la actividad se solicitan diversos datos :
Código : Se refiere al código que identificará al tipo de incidente.
Descripción: Es la descripción del tipo de incidente.
Queda pendiente de liquidar y se liquida como: Es un tilde que internamente actúa por si o por no.
Si el incidente queda pendiente de liquidar, podrá ser utilizado en una liquidación del tipo asociado.
Modifica situación de revista como : Es un tilde que internamente actúa por si o por no.
Si el incidente modifica la situación de revista, podrá ser utilizado desde el panel de trabajo de incidentes para proceder a modificar la situación de revista de un legajo.
Implica ausencia : Es un tilde que internamente actúa por si o por no.
Requiere certificado / Justificación : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitará o no cierta información al ingresar o cerrar el incidente.
Requiere visita a domicilio : Es un tilde que internamente actúa por si o por no, y en función de este tilde se solicitara o no cierta información al ingresar o cerrar el incidente.
Requiere cerrar el incidente : Es un tilde por si o por no, y que permitirá dejar al incidente como pendiente de cierre, para un posterior cierre manual o a través de una liquidación, o bien dejará al incidente como cerrado en el mismo ingreso.
Referencia obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto de referencia.
Detalle Obligatorio : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto detallando el mismo.
Dar aviso a ART: Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingresen los datos asociados a la ART.
Solución obligatoria : Es un tilde por si o por no, y que permitirá definir si al momento de ingresar un incidente, es obligatorio o no que se ingrese un texto en el campo de solución.
Evalúa cantidad de días contra cuenta corriente de vacaciones : Es un tilde por si o por no, y que permite que, al momento de ingresar un incidente, las fechas de inicio y final del mismo sean evaluadas en su cantidad contra el saldo de la cuenta corriente de vacaciones asociada al legajo.
Para una mejor explicación se provee un documento especial para liquidación de vacaciones.
Rango máximo de días : Es la cantidad de días máxima que puede mediar entre la fecha inicial y final de un incidente, y solo a efectos que, al momento de ingresar un incidente, la cantidad de días que media entre la fecha inicial y final, no supere dicho numero.
Como ejemplos de tipos de incidentes, podemos aplicar que :
Un accidente laboral, implica ausencia, no queda pendiente de liquidar, modifica la situación de revista, requiere una visita al domicilio por parte del medico, requiere cerrar el incidente, tiene referencia y detalle obligatorio, se debe dar aviso a la ART y no tiene un rango máximo de días.
Una ausencia con aviso, no queda pendiente de liquidar, no modifica la situación de revista, implica una ausencia, requiere un certificado o justificación, no requiere visita a domicilio, requiere cerrar el incidente, requiere una referencia y detalle, no da aviso a la ART, no requiere de una solución, no evalúa la cantidad de días de vacaciones, y tiene un rango máximo de 1 día.
Una licencia por vacaciones queda pendiente de liquidar, modifica la situación de revista, implica una ausencia, no requiere certificado, no requiere visita a domicilio, requiere cerrar el incidente, no tiene referencia, detalle ni solución, evalúa la cantidad de días contra la cuenta corriente de vacaciones, y tiene un máximo de 35 días.
Y así las distintas combinaciones posibles o necesarias.
Dar de alta un incidente :
Para dar de alta un incidente, se debe acceder desde (Personal), seleccionar en la grilla el legajo que se asociara al incidente y clickear en (Incidentes), se desplegará una grilla con los incidentes asociados al legajo en forma inversa, el mas cercano primero, la grilla podrá ser filtrada para obtener solamente los vigentes, los anulados o todos, también se podrá filtrar por tipo de incidente.
Para dar de alta un nuevo incidente, se deberá clickear en (Nuevo).
Lo primero que se debe indicar es el tipo de incidente a ingresar, debido a que precisamente el tipo de incidente determinará que datos son obligatorios y cuales no.
Luego se sugiere la fecha del día, que indica básicamente la fecha del incidente.
Fecha de inicio y fecha final se refieren al comienzo y finalización del incidente, en el caso de una licencia por maternidad será la fecha de comienzo y finalización de dicha licencia, lo mismo para el caso de vacaciones; en el caso de una ausencia será la misma fecha en ambos datos.
La cantidad de días que media entre una fecha y otra será validada contra la cantidad máxima de días que tiene definido el tipo de incidente.
La solapa “Incidente” permite dejar constancia del incidente en si.
Referencia es un titulo o descripción corta del incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Detalle es un texto donde se debería explicar el incidente, y será obligatorio su ingreso si se ha definido así en el tipo de incidente asociado.
Resolución es un texto donde se debería explicar la solución del incidente, y será obligatorio su ingreso si así se ha definido en el tipo de incidente asociado.
Adjunto permite ingresar o buscar un documento externo al sistema, ejemplo una amonestación o suspensión hecha en un procesador de texto, y dejarla asociada al incidente para su consulta o seguimiento.
La solapa “Médico” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha y hora de visita se refiere al momento en que el médico efectuó la visita en el domicilio del
Paciente.
Nombre del profesional se refiere al nombre del médico que ha visitado al paciente.
Resultado / Observaciones es un texto que sirve de aclaración al incidente.
Los datos médicos son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “Certificados” permite dejar constancia de ciertos datos que pueden estar asociados al incidente.
Fecha de certificado se refiere precisamente a la fecha que consta en el certificado presentado
Observaciones es un texto que puede servir de aclaración al incidente
Los datos sobre certificados son obligatorios si se ha definido así en el tipo de incidente y el mismo quiere cerrarse.
La solapa “ART” permite dejar constancia del aviso del siniestro a la ART que corresponda.
Fecha y hora de aviso se refiere precisamente al momento en que el incidente es declarado a la ART
Atendió / Contacto / Nombre se refiere a la persona de la ART que nos ha relevado el incidente .
Número de siniestro es el número que otorga la ART al incidente y servirá para referencias posteriores.
Observaciones es un texto que sirve de aclaración a la denuncia del incidente a la ART
Los datos de fecha, contacto y número de siniestro son obligatorios si así se ha definido en el tipo de incidente y se pretende cerrar el mismo.
La solapa “Abogados” permite dejar constancia sobre datos asociados a situaciones que requieran la intervención de un abogado.
Nombre profesional se refiere precisamente al nombre del abogado asociado.
Observaciones es un texto que sirve de aclaración.
La solapa “Situación de revista” permite establecer que tipo de situación de revista esta asociada al incidente.
Situación de revista se refiere a la situación en que el empleado ingresa a partir de la incorporación del incidente, la misma es sugerida en base a lo definido en tipos de incidente, pudiendo también ser modificada por el operador que esta ingresando el incidente.
Si el tipo de incidente no tiene indicado que modifica la situación de revista, este dato no será tenido en cuenta.
La aplicación de estas situaciones de revista a cada legajo, para su migración al aplicativo Sicoss, se explica en documento aparte.
La solapa “Liquidación” permite establecer en que tipo de liquidación se ha de procesar el incidente.
Tipo de liquidación asociada se refiere precisamente al tipo de liquidación en que el incidente será evaluado e incorporado.
El tipo de liquidación sugerido se obtiene de lo que se haya parametrizado en la definición del tipo de incidente.
Si el tipo de incidente no tiene indicado que es liquidable, este dato no será tenido en cuenta.
La solapa “Cierre” mantiene datos asociados al cierre del incidente.
Marca el incidente como cerrado se refiere precisamente al hecho de cerrar el incidente y que el mismo no pueda ser modificado.
Al pretender cerrar el incidente se evaluarán los contenidos de ciertos datos según lo parametrizado en el tipo de incidente asociado.
Los incidentes que son liquidables se cerrarán automáticamente al confirmar la liquidación asociada sin necesidad de cerrarlos en forma manual.
Al confirmar el incidente el mismo quedará archivado asociado al legajo, y podrá ser visualizado en la grilla asociada al legajo o bien en la general de incidentes.
Modificar un incidente :
Para modificar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Modificar)
No se podrá modificar un incidente cerrado o anulado.
Anular un incidente:
Para anular un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Anular).
No se podrá anular un incidente cerrado o ya anulado con anterioridad.
Los incidentes anulados no serán tenidos en cuenta en una liquidación
Consultar un incidente
Para consultar un incidente bastará con seleccionarlo en la grilla correspondiente y clickear en (Consultar)
Liquidar un incidente :
Los incidentes que en su tipo hayan sido definidos como Liquidables, podrán ser utilizados en una liquidación mediante la utilización de un tipo de formula especial.
Dicho tipo de formula tiene la particularidad de localizar el incidente y obtener la cantidad de días que median entre la fecha de inicio del mismo y la fecha final.
Estas fechas deben estar dentro del rango de aquellas definidas en la liquidación que los va a utilizar.
O sea, al momento de definir una liquidación se solicita el periodo inicial y el periodo final, dichas fechas sirven, entre otras cosas, para obtener incidentes pendientes de liquidación , con fecha de inicio y final dentro de dicho rango.
Formulas utilizando incidentes:
Para poder utilizar días de un incidente en una formula, se utiliza la palabra clave INCIDE
INCIDE es la palabra clave que permite ser incorporada como argumento dentro de una formula de un concepto de liquidación.
INCIDE va seguido del código del tipo de incidente a evaluar y un modificador respecto a que es lo que debe hacer en lo referente a : localizar el último incidente y tipo, localizar el primer incidente y tipo, o bien realizar la sumatoria de días de dicho incidente dentro del periodo de la liquidación.
Sintaxis :
INCIDE;{TIPO DE INCIDENTE};{modificador}
INCIDE es la palabra clave
TIPO DE INCIDENTE se refiere a un código de tipo de incidente definido.
Modificador se refiere a la forma de evaluar el incidente, pudiendo ser :
ULT : cantidad de días del ultimo incidente del tipo indicado.
PRI : cantidad de días del primer incidente del tipo indicado
SUM: sumatoria de días de todos los incidentes del tipo indicado.
Ejemplos:
Vacaciones
Suponiendo que el tipo de incidente para licencia por vacaciones sea LICVAC
INCIDE;LICVAC;ULT
Devolverá la cantidad de días del último incidente LICVAC
Entonces podría ser utilizado de esta manera
( ( ( ESCALA;”JF”;CATEGO ) / 25 ) * INCIDE;LVAC;ULT )
Calculando el valor de las vacaciones obteniendo el sueldo según escalafón “JF”, evaluado por categoría en legajo y dividido 25 multiplicado por la cantidad de días del ultimo incidente LVAC asociado al legajo
Ausencias sin aviso
Suponiendo que el tipo de incidente para ausencias sin aviso sea AUSEN1
INCIDE:AUSEN1;SUM
Devolverá la sumatoria de los días de todos los incidentes del tipo AUSEN1 en el periodo que abarque la liquidación.
Entonces podría ser utilizado de esta manera
( ( ( ( ESCALA;”JF”;CATEGO ) / 30 * INCIDE;AUSEN1;SUM ) * - 1 )
Calculando el valor a restar obteniendo el sueldo del escalafón JF evaluado por categoría, dividiéndolo por 30 y multiplicándolo por la cantidad de ausencias dentro del periodo.
Ch 20-09-2010
Suscribirse a:
Entradas (Atom)
