Sobre este proyecto
it-programming / others-5
Abierto
Contexto general del proyecto
Actualmente se cuenta con la versión uno de la solución por lo que algunos de los siguientes requerimientos no requieren un desarrollo desde cero: 1. Permitir la creación de solicitudes de descarga de todo tipo de CFDI: emisor, receptor; ingreso, egreso, nomina, pagos, en base a estas selecciones podría cambiar el formulario. Esto deberá ser paramietrizable a nivel unidad de negocio. Parametros a nivel unidad de negocio. 2. Pantallas de consulta de documentos, deberá mostrar un formulario de filtros por tipo de cfdi, y algunos campos clave de la tabla de datos, como son: rfc emisor, rfc receptor, fecha emisión, etc. El resultado de la consulta deberá mostrar una tabla que permita: mostrar u ocultar columnas, reorganizar columnas, ordenar columnas (order by), aplicar filtros sobre la misma tabla y descargar datos a Excel. También deberá mostrar columnas de estatus de cancelación y listas negras (ver mockup para mejor entendimiento). En la vista de resultados de la consulta se debe mostrar tres botones 1. "Ver" que permita la consulta del xml a través de un formato de impresión (xslt, podrá existir uno por tipo de cfdi), 2. Pdf. Permite convertir y descargar la vista de impresión en formato pdf (nota importante, el pdf se genera solo bajo demanda por temas de almacenamiento), y 3. Xml deberá permitir la descarga del xml en su formato original. En la vista de resultados de la consulta se debe permitir seleccionar uno o varios registros y habilitar la opción de descarga masiva en los formatos xml y pdf (nota importante, el pdf se genera solo bajo demanda por temas de almacenamiento), cuando se quieran descarga más de dos documentos se deberá generar un archivo zip el cual deberá estar protegido por una contraseña generada aleatoriamente misma que será enviada en automatico al usuario que lo genera vía correo electrónico. 3. Módulo de Facturas para Pago, deberá exisitir un apartado donde se permita Marcar Facturas Pagadas, donde se presentará el listado de las facturas recibidas, aquí el usuario podrá seleccionar solo de manera individual y a través de una acción de usuario marcarlas como pagadas, los datos que le solicitará el portal son: fecha de pago, monto pagado, referencia de pago (valor unico). (Contamplar agregar una tabla para la gestión de los pagos, ya que como lo veremos más adelante podrían existir N pagos para 1 factura), aplica solo para CFDI de tipo ingreso donde el receptor es el cliente. Esta sección deberá permitir realizar una carga masiva por medio un layout de texto (UUID, Fecha de Pago, monto pagado, referencia de pago), no se puede actualizar una factura si su estatus SAT es diferente a vigente, si el monto pagado acumulado es igual o menor a 0, si la referencia de pago ya existe para esa factura) 4. El portal deberá contar con un dashboard de Estatus de Pago. Los datos del dashboard (tabla) deberán ser descargable a formato Excel, este reporte debera mostrarse por rango de fecha y en el se visualizaran las facturas recibidas que de acuerdo a la regla de negocio (se detallará posteriormente) sean suseptibles de recibir un complemento de pago, los datos de control a mostrar son: Factura pagada/pendiente de pago, factura con complemento de pago/sin complemento de pago, campo calculado de días restantes para recibir complemento de pago (se detallará posteriormente), el grid de datos debe ser colapsable agrupando por factura sus complementos de pago y diferentes estatus, existen por lo menos 4 escenarios identificados: Factura pagada con complemento recibido, factura pagada sin complemento recibido, factura recibida pero no pagada, factura parcialmente pagada con/sin complementos recibidos. 5. Módulo Conciliación de Pago, deberá exisitir una vista que haga mostrará las facturas vs complementos de pago, funcionará con tres tablas: 1. Facturas pagadas, 2. Datos factura, 3. Complementos de Pago. Mostrará todas a quellas facturas marcadas como pagadas, asi como su información y relación de pagos (ver mockup para mejor entendimiento), esta vista deberá heredad las funcionalidades de ver, pdf, xml, descarga de datos (este archivo llevará dos niveles de agrupación) y descarga masiva de archivos. 6. Pantallas de consulta de documentos Nomina, deberá mostrar un formulario de filtros acorde al tipo de documento, y algunos campos clave de la tabla de datos, como son: rfc emisor, rfc receptor, fecha emisión, etc. Deberá heredar todas la funcionalidad de consulta de documentos. Usuarios. Amplir alcance de permisos de usuarios, se debe contemplar asignación de usuarios a nivel empresa, unidad de negocio (una o varias) y acceso por funcionalidad y tipo de comprobantes. 7. Notificaciones Opertativas y Administrativas. Exisitirá una tabla de notificaciones donde se podrán parametrizar, si se activan o desactivan, el cuerpo del correo, el asunto, el receptor (pudiera ser obtenido de otra tabla). 8. Personalización de colores y logotipo. Existirá un parametro a nivel unidad de negocio que habilitará una sección de personalización de logotipo y color de cabecera del portal, así como el uso de un stylesheet por tipo de comprobante (igual a nivel unidad de negocio).
Categoría Programación y Tecnología
Subcategoría Otros
Tamaño del proyecto Medio
¿Es un proyecto o una posición? Un proyecto
Actualmente tengo Tengo las especificaciones
Disponibilidad requerida Según se necesite
Roles necesarios Programador
Plazo de Entrega: No definido
Habilidades necesarias