SAC 9.6.8765

Estas son las modificaciones hechas a SAC y/o MCOB, MCAL, IC, realizadas desde el 5/may/2023 hasta el 31/dic/2023.

1. En reportes/prestamos/saldos, las fechas de último capital y último interés pagados, cuando todavía no hay pago, aparece la fecha de entrega, debe aparecer en blanco. En el reporte de saldos tipo SAC, se presenta como 1/1/1900, debido a que toda la columna debe ser tipo fecha para poder ordenar. En los reportes de CNBV, aparece en blanco.
2. Había un error en personas tipo externo al consultar su historial de créditos desde el reporte Reportes/Préstamos/Historial
3. Cuando una inversión está garantizando un crédito el SAC deja de realizar la validación de la garantía liquida necesaria para dicho crédito, para Porvenir necesitamos que siempre se realice esta validación aunque tenga una inversión como garantía. Solo retiré la verificación, mediante la subrutina VerGarantiaCon
4. Actualmente se traen los parámetros globales de una sucursal mediante el proceso TraerParametrosSuc, tales como la tasa de IVA y el nombre de la empresa. Estos parámetros son por sucursal, así que para cada inversión o préstamo, en los reportes se traen los parámetros correspondientes a su sucursal. Para la parte exenta de ISR y tasa de ISR, se traen los valores de la sucursal, pero a la fecha actual de SAC. Se deben traer a la fecha final del reporte. Por ejemplo si es un reporte de contratos de inversión de f1 a f2, se deben traer a la fecha f2.
5. El sobrante de la garantía liquida, no asignarlo al ultimo crédito, sino al último crédito que requiera garantía líquida. Se modifica el proc. AsignaMBPre para que solo tome en cuenta los préstamos con tippre mayor que 0 (los que si deben tener garantía líquida)
6. Al no asignar la garantía líquida sobrante, calculaba mal la estimación preventiva.
7. "La suma total de los montos dispuestos" de todas las personas relacionadas se deben tomar en cuenta para observar que no rebasen el 10% del capital. Es decir al agregar/entregar un nuevo préstamo se debe sumar ese monto mas el saldo a la fecha de todos los préstamos de todas las "personas relacionadas", es decir personas con cargo en la entidad. Tomar en cuenta no el saldo inicial de cada préstamo, sino el saldo de cartera (capital mas interes devengado). También se toman en cuenta los relacionados en 1er grado con personas con CE, así como los préstamos donde estas personas son avales.
8. El reporte de saldo de préstamos / cargo en la entidad, agregarle los saldos de capital e interes (solo aparece el monto inicial). Se agregan 11 columnas relativas al capital, interés ordinario y moratorio de los préstamos.
9. Agregar cobro de apertura, cobro periódico y ahorro voluntario en la impresión del plan de pagos usando CR. En vez de imprimir desde frmPrestamo, imprimir desde frmReportesPlanPagos, donde ya se calculan las columnas para estos datos extra.
10. En la carga masiva de préstamos (en Caja/Pólizas) al capturar la clave de préstamo se podia expresar como sucursal-claveprestamo o como claveprestamo-sub, lo cual causaba confusión y ambigüedad. Ahora se restringe a capturar sucursal-claveprestamo-sub. Igual para el socio al capturar ahorros, se obliga a capturar sucursal-maymen-clavesocio
11. "Desglosar el permiso 41 que es para ""Autorización de op. mayores, op. inusuales, a per. de alto riesgo, bloqueadas (LPB) y PEPs"" en permisos separados. Cambiar PERMISOS.proceso a real (single). Quedan como sigue: 41.1-Autorización de op. mayores, 41.2-Autorización de op. inusuales, 41.3-Autorización de op. a per. de alto riesgo, 41.4-Autorización de op. a LPB, 41.5-Autorización de op. a PEPs, 41.6-Justificar coincidencias de per. en listas
12. También se modifica el reporte de permisos (Reportes / Otros / Permisos) para que muestre correctamente la lista de permisos con sus claves numéricas (que se cambiaron de smallint a real) y descripciones.
13. Se obtiene el error "Maximum number of rows exceeded" al generar un reporte teniendo como soporte el grid de ComponentOne (flexgrid), en los reportes de captación. Agregar opciones de generación en archivos CSV. Se agrega un combo para seleccionar el "destino", que puede ser Grid o CSV. Se obtiene una reducción significativa, de 1273 seg vs 225 seg, es decir casi 6 veces más rápido.
14. hay una socia que era conyuge de una persona con cargo en la entidad, se eliminó la relación pero sigue apareciendo en el reporte de personas relacionadas. En el procedimiento CalcCamposPLD, no se tomaba en cuenta el status cancelado de la tabla SOCIOSDEP.
15. Al tomar el 7% (nivel I) o 5% (nivel II), etc., del capital neto para comparar con un crédito, tomo en cuenta el monto inicial del crédito y debo tomar el saldo de los créditos a la fecha. Se modifica y cambia nombre al procedimiento CalSaldoParentesco, para traer el saldo de los créditos de los relacionados en 1er. grado (Riesgo Común). De la misma forma se modifica el procedimiento CuantosPrestamos, para que regrese el saldo (capital + interés) en vez del monto, de todos los préstamos activos del acreditado.
16. El procedimiento CalcPromEfe, que calcula el promedio de depósitos en efectivo de cada socio, y que a su vez se llama desde CalcCamposPLD, que calcula información relevante del socio para PLD, es muy lento, por lo que llega a marcar que terminó el tiempo de espera de la consulta SQL. Agregar a la tabla MOVPRESTAMO los datos del socio respectivo (sucursal+maymen+clavesocio), para que no tenga que ligar la tabla PRESTOTOR en cada ejecución de CalcPromEfe. Igual para MOVCONTRATO, desde CONTINV. Llenar estos campos cuando tengan valor NULL, en cada ejecución de CalcPromEfe, mediante el procedimiento AsigCamCalcMov. También se agregó la línea "and u.fecha between '" & Format(f1, "d") & "' and '" & Format(f2, "d") & "' " para que se haga la selección de los registros de la tabla MOVUSUARIO, y sea mucho más rápida la consulta SQL.
17. Al aplicar un pago anticipado y crear un nuevo crédito, dar la opción si se reduce el número de abonos a capital o se reduce el monto del abono.
18. Se modifica la sentencia SQL en los formatos de CR para solicitud de préstamo, para ligar la descripción del producto de préstamo desde la tabla TASAS, y poderla mostrar en el formato. El campo se nombra descripciontasa.
19. En SAC, en Reportes / Préstamos / Movimientos / Préstamos vencidos, se llamaba cíclicamente al procedimiento de plan de pagos. Pero al nunca limpiarse este, se acumulaban los datos en el arreglo PP. Se implementa array.clear dentro de PP.
20. En parámetros, al guardar el ISR, PEISR e INFLACION, quedaban como canceladas, quedaban en conflicto con el guardado de la pestaña de VALORES. Se corrigió.
21. Ya existe el permiso 22, cambiar fecha en cancelación de personas. Se agrega el 22.1, cambiar fecha en recalc. Int. Ah. Y 22.2, cambiar fecha en recalc. ISR. Esto para poder lidiar con los contratos de ahorro recurrente o tipo tanda, y poder pagar un interés en una fecha que por ahora se capturará manualmente.
22. Establecer en el producto de crédito la clave del seguro de préstamo por default. Se agrega en Parámetros / Productos de préstamo la columna "seguro", donde se puede teclear el número correspondiente a la clave del seguro, de la lista de seguros establecidas en Parámetros / Valores. Con esto ya no es necesario seleccionar la compañía de seguro al agregar un préstamo, ya queda establecido por default de acuerdo al producto de crédito correspondiente.
23. En IC, al querer agregar una subcuenta a una cuenta afectable, se usaba un procedimiento que convertía la cuenta padre de afectable a acumulación, y creaba la cuenta hija; pasaba todos los saldos y movimiento de la cuenta padre a la hija. Fallaba por restricción de una llave foránea. Se corrige. Se crea la subrutina CambiarAAfectable, que se llama después de haber agregado la cuenta hija.
24. Ahora el procedimiento de cálculo de plan de pagos, PlanPagos2 me regresa el valor de la fecha de vencimiento del préstamo (fechavenpre) y el monto del pagaré (montopagare) que anteriormente tenían que calcularse mediante un for que volvía a recorrer todo el PP.
25. Tanto en el formulario de préstamos, de contratos de inversión y de pasivos recurrentes, al modificar, cancelar, autorizar, entregar, etc., no se limpiaba el formulario, solo se activaba la clave principal con la intención de tener en pantalla el mismo dato anterior (préstamo, inversión, pas. rec.). Sin embargo si manualmente modifico la clave, debo de poder agregar un nuevo dato, no se podía. Se corrigió.
26. En los formularios de contratos de inversión y pas. rec. se agrega la variable booleana bCalcularDatos, que evita estar calculando los diversos datos (intereses netos, ISR, etc.) mientras se van cargando datos en el formulario, y lo hacen más ágil.
27. SOCIOSPASREC. Se añade un formulario al que se accede desde Personas / Pasivos recurrentes, para dar de alta un nuevo contrato de pasivos recurrentes de una persona, o modificar uno existente. Se captura el producto de pasivos, el número de depósitos, el periodo en días de los depósitos y el monto a depositar en cada periodo. Posteriormente en Caja se puede consultar para un socio si tiene contrato de pasivo recurrente y se podrán hacer depósitos a la cuenta de pasivos respectiva.
28. SOCIOSPASREC. Depósitos retirables en dias preestablecidos, "ahorro recurrente", "pasivo recurrente" o tipo "tanda". Que  no se pueda retirar en un periodo predeterminado, y darle una tasa preferencial. Se agrega una tabla hija de SOCIOSPAS, llamada SOCIOSPASREC la cual almacena los sucesivos "contratos" de ahorro retirable en días preestablecidos. En esta tabla se almacena la fecha inicial, monto de abono, periodicidad y número deperiodos, así como las diversas tasas pactadas de acuerdo al nivel de cumplimiento.
29. SOCIOSPASREC. Debido a que el formulario de caja ya está muy saturado de información, y que esto puede provocar confusión y poca eficiencia para el usuario, y de que aún se saturaría más con la incorporación del módulo de pasivos recurrentes, se decide quitar muchos de los elementos de información. Algunos se pasan al combo de saldos, como los saldos de contratos de inversón. Otros se mueven a ventanas pop-up, como son las ventanas de visualización de préstamos y de pasivos recurrentes.
30. SOCIOSPASREC. En la tabla de MOVAHORRO, para movimientos de pasivos, se agrega el campo ClaveContrato, que es la clave del contrato de pasivo recurrente. Para cuando un mov. de ahorro se haya realizado en caja cuando hay un contrato de pasivo recurrente activo. La referencia completa sería SucDes + ClaveContrato. Se modifica GuardaAhorro para que se guarde ClaveContrato.
31. SOCIOSPASREC. Se crea el reporte de saldos de pasivos recurrentes, en Reportes / Pasivos recurrentes / Saldos
32. En la entidad PV tienen SQL Server 2008 por lo que una parte de la sentencia SQL del recibo.rpt no funciona. La instrucción es " iif(m.cheque>0, 'cheque' , iif(m.clavebancotransf>0, 'transferencia', 'depósito')) " y se tuvo que cambiar por un espacio en blanco.
33. Se agrega el campo POLIZA.contra, para indicar si la contracuenta de esta póliza es efectivo, bancos, ninguna, o ambas. Esto se reconoce mediante las tablas ligadas respectivas: MOVUSUARIO, MOVBANCOS. Util en el reporte de pólizas, para mostrar solo las pólizas requeridas. Se crea una subrutina CalcContraCuenta, que asigna este campo a todas aquellas pólizas con valor null. Se llama a esta subrutina antes de generar el reporte de pólizas.
34. En la impresión del reporte de evaluación (Evaluacion.rpt) y de solicitud de préstamo (ReciboPrestamo.rpt) se enviaba el CAT con IVA, se observó que en los reportes se hace referencia al CAT como CAT sin IVA, por tanto ahora se manda éste. También se observó que en otros reportes se envía CAT sin IVA.
35. Candado que impida que en la formalización de préstamos o créditos que se pacten a pago único de principal al vencimiento, el plazo máximo exceda los 18 meses.(CNBV)
36. Alertas y reportes que se generarán, para identificar en forma previa, a aquellos ahorradores menores próximos a cumplir la mayoría de edad. En el Reporte de Personas, ubicado en Reportes / Personas / Personas, formato: SAC, se agrega la respectiva columna.
37. Para evitar modificaciones en los reportes, convertir los archivos CSV (obtenidos desde ComponentOne FlexGrid) a PDF, mediante system.printdocument, con la propiedad PrinterName  en "Microsoft Print to PDF"
38. Se agrega el campo SOCIOS.CIE, que es la clave de convenio CIE para la persona, en el banco BBVA Bancomer
39. Se agrega el parámetro min en todos los formatos de Crystal Reports de contrato de ahorro (contratoahorro.rpt), el cual representa el mínimo aceptable de la cuenta de pasivo
40. En la entidad PV se corrió el comando para tomar en cuenta el monto bloqueado para el calculo de la estimación preventiva en el reporte de Saldos de Créditos; para la estimación preventiva si toma en cuenta el monto bloqueado pero vimos que para el calculo de la estimación preventiva adicional no se toma en cuenta el monto bloqueado. Se corrige.
41. En MCOB formatear los teléfonos de contacto del socio con el mismo formato del formulario personas de SAC (___)-___-____ . Se cambió el tipo de control de textbox a maskedtextbox en el formulario de eventos.
42. Se añaden los campos MOVAHORO.Contra, MOVPRESTAMO.Contra, MOVCONTRATO.Contra y MOVSERVICIOS.Contra, heredados de su póliza respectiva (tabla POLIZA) para identificar a estos movimientos como de efectivo, bancos, ambos o ninguno. Esta asignación se hace en el sub AsigCamCalcMov (asignar campos calculados para movimientos). Esta asignación se hace cada vez que se ejecuta CalcUltMovAhPreCo y CalcUltMovAh, que calculan el último movimiento de cada socio. Se modifican CalcUltMovAhPreCo y CalcUltMovAh para que no tomen en cuenta pólizas tipo 0-ninguna, y solo se tome en cuenta 1-efectivo, 2-bancos, 3-ambas.
43. Modificar el sub CalcContraCuenta para que asimile los movimientos por cheque rec. (CHEQUESREC) como movimientos de bancos
44. Ya existe un campo SOCIOS.fecultmov, agregar un campo SOCIOS.montoultmov para almacenar el monto del último movimiento, ya sea de una cuenta de pasivos en específico en el reporte de captación, o de cualquier movimiento en general del socio (pasivos, préstamos, contratos, servicios), para el reporte de PLD. Calcularlo en el sub CalcUltMovAhPreCo.
45. Se agrega el parámetro GATreal en todos los formatos de Crystal Reports de contrato de ahorro (contratoahorro.rpt), el cual representa el GAT real del producto (GAT neto de la inflación). Se modifica SAC para que envíe este parámetro. El otro parámetro, GAT, de los contratos de ahorro, representa entonces el GAT nominal.
46. Se agrega un nuevo reporte en Reportes / Préstamos / Saldos, el reporte de "Vigente y 2 anteriores", que muestra los créditos vigentes más los datos básicos del crédito anterior y el previo al anterior.
47. Agregar el parámetro GATreal en todos los formatos de Crystal Reports de contratos de inversión (contratodeposito.rtp y contratodeposito1.rpt) y los certificados de aportación (certificadoaportacion2.rpt y certificadoaportacion3.rpt).
48. En el reporte de saldo de préstamo se detectó que varios sabores de reporte no requerían mostrar los saldos de pasivos, distribuir la garantía líquida en los varios préstamos del acreditado, o mostrar los saldos de servicios, por tanto se evitaron estos cálculos. Así se aceleran estos reportes. Se usó la función "contains" de los "array".
49. Al detectar un crédito con riesgo común (que la suma del monto de este crédito mas el saldo de otros créditos del mismo socio, más el saldo de créditos de parientes en primer grado, superen el 5% del capital de la entidad), ahora SAC muestra un mensaje con detalles más específicos sobre los créditos encontrados y la fecha considerada.
50. Al entrar al cuadro de diálogo de la entrega de préstamos (frmEntrega), al parecer se traba o alenta SAC
51. Estimacion adicional: antes de calcular el porcentaje del crédito, le debo restar la parte cubierta (garantía líquida). En vez de calcular la estimación adicional por riesgos operativos (SIC) y la ordenada por la CNBV, sobre el saldo total del préstamo, ahora se calcula sobre la parte descubierta.
52. SMC requiere la impresión en la solicitud de ingreso (solicitudingreso.rpt) de ciertos datos extra de los beneficiarios, se tendrán que agregar a la tabla SOCIOS los siguientes campos: ciudad de nacimiento, código postal, ciudad, municipio, celular
53. Para SMC se agregan también datos generales del cónyuge en la tabla de SOCIOS, como son fecha de nac., teléfono cel., país y lugar de nac., CURP, empresa y puesto
54. En el contrato de ahorro de SMC se encadenó dos veces la tabla VALORES, para recuperar la descripción de la actividad económica y cargo PEP, con la instrucción: SELECT s.*, v1.valor as v_actecocnbv, v2.valor as v_cargopep  FROM  socios s left join valores v1 on v1.sucursal=s.sucursal and v1.propiedad='cargopep' and v1.indice=s.actecocnbv left join valores v2 on v2.sucursal=s.sucursal and v2.propiedad='cargopep' and v2.indice=s.cargopep Where s.ClaveSocio='{?ClaveSocio}' and  s.MayMen={?MayMen} and s.sucursal='{?Sucursal}'
55. SMC reporta que con la nueva versión el sistema "está muy inestable y lento". No se especifica en que procesos, pero se revisa y se observa lo siguiente: al ingresar al sistema, se eliminan registro de BITACORA muy antigüos, es un proceso muy lento que se pasa al cierre de caja. Al generar tablas y campos faltantes, en cada instrucción del tipo UPDATE para cambiar campos nulos por su valor por default, es muy lento en tablas grandes, se eliminan algunas instrucciones de estas, que ya no son requeridas. En caja, al llamar a cajaverpre y cajaverPR, ahora se usa su propia conexión de BD en forma interna, antes se usaba dbSAC. En frmPolizaEsp, al intentar cancelar una póliza, primero se iniciaba una transacción y después aparecía un cuadro de diálogo para que el usuario confirmara, esto resulta en que el sistema se "pare". Al intentar modificar un préstamo, también primero comenzaba la transacción y luego aparecía el cuadro de diálogo. Al entregar un préstamo, ya no se muestra la cuadro de diálogo de denominaciones, a menos que se entregue el dinero en efectivo. Se pusieron una serie de comandos miMostrarStatus al agregar, modificar, entregar y autorizar préstamos, para detectar los procesos lentos.
56. Hace un tiempo la entidad PV pidió que, a pesar de que se agregue un contrato de inversión como garantía de préstamo, que no se considerara como garantía líquida de acuerdo a los tantos. Pero otras entidades si lo requieren. Se agrega la propiedad SelGarCon en la tabla VALORES. Si el valor es 0, no se considerará la garantía de contratos de inversión para solventar un préstamo. El contrato de inversión seguirá bloqueándose de forma que no se pueda liquidar mientras el présamo esté vigente, pero no se considerará como garantía líquida de acuerdo al número de tantos del préstamo (PRESTOTOR.TipPre). Si el valor es 1, si se considerará la garantía de contratos de inversión.
57. Para seguir haciendo más eficiente el sistema SAC, se cambian algunas instrucciones SQL en las que se usa un UPDATE con WHERE y IS NULL. Se modifica estableciendo valores por default en los campos. Los campos POLIZA.contra, MOVAHORRO.contra, MOVPRESTAMO.contra, MOVCONTRATO.contra y MOVSERVICIOS.contra, se declaran como "contra smallint default -1" y donde compara "contra is null" se cambia por "contra=-1". Esto acelera funciones como AsigCamCalcMov y CalcContraCuenta. También para MOVPRESTAMO.clavesocio y MOVCONTRATO.clavesocio, se declaran con un valor por default de '0000000'.
58. En TraerDomicilioCP, que trae la colonia, ciudad y municipio en base al CP seleccionado, se agregó la instrucción mid(campo, 1, 40), puesto que se dio el caso de una colonia que excedía los 40 caracteres, y al querer guardar un socio marcaba error.
59. Seguía habiendo errores al reinvertir automáticamente, porque no se actualizaba el campo clavesocio de MOVCONTRATO en base al valor de CONTINV. Esto porque, a pesar de que se puso una restricción (constraint) para un valor default, esto solo vale para registros nuevos. Para los registros ya existentes hay que usar un UPDATE para cambiar todos los nulos (NULL) al valor por default. Se corrigió para que al generar tablas y campos faltantes se asignen estos valores por default.
60. Se cambió el algoritmo de CalcContraCuenta, que seguía siendo muy lento a pesar de los valores por default. Esta rutina asigna si una póliza es en efvo, bancos, ambas o ninguna. Se usaban instrucciones del tipo "and campo not in" que parecen ser muy lentas. Ahora se asignan primero las pólizas de bancos, después se incrementa +1 para las que también tienen mov. en efvo. Después las que solo son en efvo. y al final las de tipo "ninguno". Esta función es esencial para los reportes de captación, para mostrar el último movimiento del socio, para otros reportes, y para el corte de caja tipo "ampliado".
61. Se observó que al agregar un socio en ocasiones lo agregaba doble. Los mismos datos, solo con diferente clave de socio, una consecutiva de la otra. Se agregó un IF después de abrir la tabla de socio, para, si ya existe, no agregarlo.
62. Siguiendo con el proceso de hacer más eficiente SAC,  al cancelar un socio, ya no se muestra el cuadro de diálogo de denominaciones, a menos que se entregue el dinero en efectivo. El cuadro de diálogo de denominaciones se muestra dentro de una transacción, lo cual ocasiona que el sistema se "pare" mientras se capturan las denominaciones.
63. Para diversos reportes de PAP, se requiere mostrar el saldo promedio. Se usa dentro del reporte de personas PLD una clase CalcIntAho para calcular dinámicamente el saldo promedio mientras se va recorriendo la tabla de socios, y mostrarla en el reporte.
64. Se cambio la instrucción TRIM de SQL Server que se usa en el reporte de movimiento de bancos por LTRIM(RTRIM(campo)) puesto que PAP usa una versión muy anterior de SQL Server, muy probablemente la 2008, y no es compatible con la instrucción TRIM.
65. Había un error en el reporte de movimientos de bancos, al traer los nombres de los bancos mediante el sub TraerBancos, en una hashtable, debido a que había claves de cuenta bancaria repetidas entre sucursales, y la hashtable no admite duplicados
66. Agregar en la tabla SOCIOS los campos SaldoProm y FecUltSaldoProm, para calcular para cada socio el saldo promedio de determinadas cuentas, agregado (pasivos, contratos) y almacenarlo como dato temporal, y para guardar la fecha en que se calculó. Si la fecha de cálculo es anterior al día de hoy, recalcular. La primera vez que se llama a un reporte se hace el cálculo de saldo promedio, las veces sucesivas que se llame ese u otros reportes ya no se hace el cálculo, se toma el valor ya calculado, lo cual hace más rápido el desplegado.