|
Evalúe Su Sistema de Impuesto Predial |
|
A continuación se enumeran los aspectos principales donde el
sistema de facturación y recaudo de Impuesto Predial usado en su municipio
podría estar presentando deficiencias. |
|
? |
Problema |
|
El peor caso: No se posee software especializado para la liquidación y gestión del recaudo de Impuesto Predial. Se realizan liquidaciones simples en hojas electrónicas, no se registran cambios históricos para las mutaciones de predios o se limita a un registro manual en tarjetas para cada predio a modo de Kardex. |
|
|
Existe dependencia de la información física (kardex) de tarjetas prediales, el sistema informático si existe no esta actualizado en un 100% con respecto a la información en papel original. Las consultas realizadas e incluso algunas liquidaciones deben apoyarse en algún tipo de labor manual o de verificación del archivo en papel. |
|
|
El sistema no genera liquidaciones en las que se discrimine el valor de capital e intereses por cada vigencia y concepto de deuda. Sin este tipo de liquidación detallada es imposible validar la correcta operación del proceso de liquidación y muy probablemente se este trabajando con valores de liquidación aproximados e incluso completamente errados. |
|
|
El sistema no permite el pago parcial de vigencias, el pago de abonos a deuda o el pago de solo deuda. |
|
|
El sistema no permite definir tipos de predio diferentes a los tipos urbano y rural. Esta es una limitación grave pues no tienen cabida ningún tipo de casos especiales (exentos, excenciones por UMATA, predios no productivos, etc.) |
|
|
El sistema no considera posibles cambios de tipo de predio para un mismo predio entre una vigencia y otra |
|
|
El código manejado por el sistema en cuanto a los predios difiere del código manejado por el IGAC, esto genera múltiples inconvenientes ya que la fuente principal de información para el sistema de liquidación y recaudo del impuesto predial son las bases del IGAC. En la medida que su manejo este unificado se evitan muchos problemas y se agiliza los procesos inherentes a la actividad. En otras palabras se requiere el uso de una codificación estándar de la información. |
|
|
Los parámetros de liquidación están restringidos para operar en un único periodo de trabajo (trimestre o meses), esto crea grandes traumatismos pues se requiere cerrar cada periodo para iniciar el procesamiento del siguiente. No es posible trabajar simultáneamente en más de un periodo de liquidación. Esto tiene como consecuencia la generación de tiempos muertos, durante los cuales no es posible generar nuevas facturas de cobro con el correspondiente perjuicio a los niveles de recaudo. |
|
|
No es un proceso en línea, se requiere su operación en tandas. Por ejemplo, hay que terminar con el registro de pagos de un periodo para poder iniciar con la facturación del siguiente. |
|
|
La liquidación de intereses no es fácilmente parametrizable de tal manera que se pueda adecuar a los requerimientos legales actuales como son su liquidación diaria. |
|
|
No presenta un adecuado manejo a los recibos entregados por las entidades recaudadoras como los bancos. Este proceso implica tener que parar hasta en varios días el recaudo del impuesto. |
|
|
No es un sistema multiusuario, es decir no se pueden tener en línea cuantas terminales se requieran instalar por parte de la administración. El procesamiento de datos, generación de reportes, y en general toda la información esta confinada a la dependencia de Impuesto Predial, específicamente al funcionario encargado. Esto limita en gran forma todos los procesos administrativos, de gestión y de control por parte de la Secretaria de Hacienda y otras dependencias que deberían acceder a la información de manera descentralizada y poder contar con los reportes y herramientas para el análisis de la información. Se requiere contar con los elementos para la toma de decisiones y gestión ejecutiva requerida para un eficiente proceso de recaudación de impuestos. |
|
|
La parametrización del programa es cerrada, lo cual implica que se requiere del creador de la aplicación para la parametrización de los nuevos periodos de liquidación o cuando se requiera de alguna prestación adicional de liquidación. De tal manera que muchos de los nuevos esquemas de liquidación tienen que ser contratadas y desarrolladas para ser realizadas por personal externo. |
|
|
La generación de reportes esta limitada a los incluidos en el sistema y no cuenta con un generador propio de reportes con el fin de no depender del proveedor de la aplicación para nuevos reportes y brindar la suficiente flexibilidad de operación a los usuarios. |
|
|
La aplicación se limita al proceso de liquidación normal del impuesto, no maneja casos especiales de liquidación requeridos para cruces de cuentas o proyecciones de liquidación, las cuales deben ser realizadas de manera manual. |
|
|
El sistema actual esta construido para satisfacer los requerimientos básicos de liquidación, sin cubrir manejos esenciales para una eficaz gestión del recaudo, como por ejemplo la carencia de un modulo de soporte para la gestión de cobros jurídicos (ejecuciones fiscales), la inexistencia de un modulo para la definición y seguimiento de acuerdos de pago con los deudores morosos, etc. |
|
|
El sistema no cuenta con las herramientas adecuadas para la generación de resoluciones administrativas de cobro y el seguimiento de las mismas, por ello no es posible implementar un proceso continuado de cobro jurídico, permitiendo que se dejen de recaudar importantes sumas de dinero por efecto de prescripción de vigencias no pagadas. |
|
|
No se cuenta con un sistema de auditoria para registro y seguimiento de las operaciones realizadas en el sistema. Sin esta herramienta no es posible comprobar la fiabilidad del sistema y su capacidad para auditar los manejos que se realicen sobre el mismo. Es decir no se puede saber que usuario ejecuto determinada actividad, la hora en que la llevo a cabo, el equipo desde donde se llevo a cabo, y la acción detallada. |
|
|
No se almacenan la totalidad de los registros históricos de información. Por ejemplo: propietarios anteriores, tipo de predio por vigencia, resoluciones aplicadas, etc. |
|
|
No es posible levantar de forma automática la información de las resoluciones del IGAC entregadas en medios magnéticos. Esto se debe a que el sistema no procesa la totalidad de las variantes de información reportadas por el IGAC y por que no tiene un manejo consistente en la aplicación de las novedades. Esto requiere de una verificación manual de la información a subir. |
|
|
El sistema actual esta montado sobre una obsoleta plataforma de sistema operativo, requiriendo que su operación se realice a través de la emulación de terminales texto. Se requiere de un sistema que se integre a las restantes herramientas de oficina usadas por las dependencias (procesador de textos, hojas electrónicas) y que opere de manera nativa sobre una moderna interfaz grafica. |
|
|
El sistema no tiene integrado un sistema automático de copias de seguridad como mecanismo de respaldo de la información. |
|
Volver a SysPredial Para solicitudes de información adicional: informacion@aabcomp.com |
| Todos los Derechos Reservados. Aabcomp (c) 2017 |