SAC 9.2.7165

Mejoras y correcciones en SAC y sus utilerías, hasta la versión 9.2.7165

1. En la base de datos de IC de una entidad, a junio 2017 la tabla SALDOS guarda saldos iniciales, aunque el mes anterior, mayo, no tiene pólizas. Esto es irregular. Para solventar este tipo de problemas, hacer 3 cosas. Cambiar el funcionamiento de SCINI, que regresa el saldo inicial de cierto periodo, tomandolo de SALDOS.saldoini del periodo correspondiente, en vez de SALDOS.saldo del periodo anterior. Evitar que se pueda entrar a un periodo anterior a la fecha de instalación de IC, PARAMETROS.fechainstalacion. Hacer un proceso especial que emita alertas cuando no corresponda el saldo final de un periodo con el saldo inicial del siguiente, esto para todas las cuentas contables.
2. En el reporte de saldos promedio de IC, las cuentas deudoras aparecían como negativas
3. Ahora se respetan los textos para el parámetro MayMen que se capturan en los valores de los parámetros de SAC. Anteriormente los textos eran fijos, por ejemplo 0-Socio Mayor, 1-Menor, etc. Ahora se pueden teclear otros textos y estos aparecerán en todos los formularios de SAC. También se meten estos valores en un SortedList, el cual se consulta constantemente en vez de consultar a la base de datos, lo cual es mucho más eficiente.
4. En el procedimiento especial de detectar inconsistencias de IC, agregar la detección de pólizas que tienen claves de cuenta vacía (tabla DETALLEPOLIZA con clavecuenta vacía)
5. Se modifica el procedimiento de SAC Personas/Bloqueadas/Acciones/Leer RIPE separado por comas y Leer RIPE separado por tabuladores. Al parecer el servicio RIPE Consultores cambió el tamaño de campos y estructura del archivo de texto en general. Ahora tiene 47 columnas en vez de las 27 que tenía antes. También se agrega el campo SOCIOSBLOQ.Institucion, que almacena el proveedor original de la persona bloqueada o PEP, como puede ser PGR, BID, OFAC, FBI, etc. Se amplía SOCIOSBLOQ.nota a 100 caracteres, para guardar la descripción del cargo en caso de que sea PEP.
6. Al imprimir un contrato de préstamo, la subrutina ImprimirContratoPre llama a la función que calcula el plan de pagos. A esta le envía la tasa de IVA de la sucursal actual, en vez de ello debe enviar un cero, si el préstamo actual no causa IVA, es decir IIf(Val("" & tblPrestotor.Fields("CausaIVA").Value) = 0, vTasaIVA, 0) . Lo mismo sucedía en ImprimirSolPrestamo.
7. Definí las constantes formFecha, formFechaHM y formFechaHMS para formatear fechas, en el módulo de Utilerias. Anteriormente estaban definidas, impropiamente, en UtileriasADO, y determinados los valores en frmSAC.
8. Implementar en la base de datos CP.BAK algunos cambios en los países que son regímenes de alto riesgo, como Bahamas, Botswana, Ghana, Pakistan y Serbia. Se quitan de la lista a Iraq, Vanuatu y Bosnia Herzegovina.
9. Cuando se entrega un préstamo en efectivo, mostrar la ventana de denominaciones
10. No considerar los depósitos en efectivo cuando se abona al préstamo. Según la LISR, Artículo 95: Para efectos del artículo 55, fracción IV de la Ley, también se entenderán como depósitos en efectivo, las cantidades en efectivo destinadas al pago de un crédito, préstamo o financiamiento otorgado por una institución del sistema financiero a una persona física o moral, que excedan del monto adeudado por tales conceptos.
11. Se hace una ligera modificación al cálculo de la localidad de 8 digitos (SOCIOS.localidad8 y SOCIOS.localidad8tra) para que si no la encuentra en la base de datos CP por el nombre de ciudad, busque por el nombre del municipio. Para asignar estas claves de localidad a los socios que no la tienen, correr de nuevo Especiales/Asignar localidades CNBV en base al domicilio actual.
12. Se arregló una diferencia en el corte de caja tipo "cd maiz" que tenía que ver con considerar 2 veces los movimientos de servicios
13. Reporte de historial detallado de crédito, agregar 3 columnas, abono vencido, monto del préstamo cuando se otorga, y el saldo del préstamo
14. En MBATCH, se agregan las etiquetas d fecha promesa y monto promesa al XML de visitas, <visit>
15. Agregar al reporte de eventos de MCOB una columna que indique si se cumplió con la fecha y monto prometido. Si se cumplió con la fecha, pero no con el monto, pintar amarillo, si no se cumplió con la fecha, pintar rojo, si se cumplió con monto y fecha, pintar verde. Mostrar ultima fecha de abono o interes, ultimo monto pagado (abono o interes). Para cumplir con la fecha, ver si hay un abono con fecha >=  mcobeventos.fecha, fecha <= mcobeventos.fechapromesa, y fecha <= fecha final del reporte. Si se cumplió con la fecha, y además el monto (cap+int+iva+pagper) >= mcobeventos.montopromesa, entonces pintar verde.
16. Ordenar la tabla temporal #mocbtmp para mostrar siempre primero los vencimientos, luego los eventos, y luego los pagos reales, en el reporte de historial de préstamos de MCOB
17. En el reporte de préstamos de CNBV, aparecían varios créditos con "tipo de acreditado" 13, lo cual indica que un aval del crédito tenía una relación de 1er grado con alguien con cargo en la entidad. En algunas ocasiones resulta que esta relación de 1er grado era el mismo acreditado, es decir, el acreditado era el del cargo en la entidad y el aval era su papa, mama o hermano. Tratar de evitar esta refencia circular. Por lo pronto CalcCargoEnt ya regresa el valor respectivo del cargo en la entidad del acreditado, en vez del valor 13.
18. Agregar en SAC e IC un botón para acceder a la calculadora de los accesorios de Windows
19. Modificar el reporte de buró de crédito tipo CSV según la versión 14
20. El reporte de historial de préstamos de MCOB no presenta correctamente el saldo del capital de préstamos en cada renglon del reporte, cuando hay mas de 1 préstamo activo en la fecha correspondiente
21. En el  reporte de operaciones relevantes se mostraba el código 09 para abono a crédito y el 41 para liquidación de crédito. Según el documento "formato oficial para el reporte de operaciones relevantes…" solo se maneja el código 09.
22. En el reporte de desagregado de depósitos del socio, R08-D-0841, faltaba redondear con cero decimales una de las columnas, monto del certificado excedente o voluntario, cuando estas cantidades correspondían a contratos de inversión.
23. Se corrigió la detección de op. excesivas de préstamo. Si se especifica un valor 0 en el porcentaje de op. inusuales para prestamo, o en monto mínimo, no se detectan estas operaciones. También en operaciones inusuales, si no se especifica el mínimo o el porcentaje, no se detectan.
24. Se corrigieron los reportes de productos de inversion y de préstamos, para tomar en cuenta los periodos en dias estipulados en parámetros, y si no se especifica monto, poner un monto arbitrario, esto con el propósito de calcular el CAT o GAT.
25. Cuando se castiga un crédito, en el reporte de colecta los abonos correspondientes al crédito castigado efectuados en el mes en que se castiga el crédito, los pasa a la columna de Castigo, esto es incorrecto, porque cuando se realizaron estos abonos se efectuaron cuando el crédito no estaba castigado. Esto ocasiona que los totales de la colecta no cuadren con el concentrado de préstamos, los totales del concentrado si nos da correcto el monto del abono a castigo. Se modificó el sub fusion para que comparara correctamente la fecha de castigo del préstamo y la fecha del movimiento.
26. En la versión nueva, cuando se pide la hoja colecta en un rango de fecha repite días. Se cambió un order by clavepoliza por un order by fecha, clavepoliza.
27. Cuando renovamos un crédito el sistema de forma automática nos lo manda a cartera tipo 2 y tiene que ser cartera tipo 1 ya que el préstamo renovado apenas se entregó y está vigente. Según Anexo C de la CUSOCAP. Se asigna la fecha de paso a cartera tipo 2, FecTipoCartera, si corresponde a un préstamo reest/renov que inicie como cartera vencida, en el formulario de entrega de préstamos, frmEntPrest, en vez de al guardar el préstamo en frmPrestamos.
28. Revisar el cálculo de monto bloqueado al entregar un préstamo (frmEntPrest) para préstamos reest/renov. Aparentemente no considera el monto bloqueado que ya había del préstamo anterior. La solución consiste en volver a calcular saldos de ahorro y monto bloqueado después de pagar el préstamo anterior en la reestructuración, puesto que este pago afecta esos saldos.
29. Al buscar un formulario entre los formularios abiertos, con "for each forma", usar un exit for inmediatamente después de encontrarlo, para hacer más eficiente la búsqueda
30. MBATCH ahora acepta guiones además de números en el nombre de los archivos recibidos, tal como visit-5b62b76c-3880-4b34-bc1c-4acb39241581.xml
31. Se modifica la URL de consulta a QeQ, cambiando qeq.mx por qeq.com.mx
32. Visitas en MBATCH: yo solo recibo la clave del socio, pero no el préstamo por el que se hizo la visita, se cambia el XML correspondiente para recibir la clave de préstamo
33. Prorrateo de montos bloqueados de préstamos, cuando hay 2 o más préstamos: la entidad puede permitir que se vaya liberando mb cuando va bajando el saldo del préstamo. Por tanto, al calcular reportes, prorratear en base al saldo de los préstamos a la fecha, y no en base al capital de los préstamos, como se hace ahora. Se agrega el campo PARAMETROS.CalcProrMB, que determina el tipo de cálculo de prorrateo, 0-sobre saldo inicial, 1-sobre saldo insoluto.
34. Reporte 451 CNBV, tipo de acreditado relacionado, aparece 0 y debe ser 1-no relacionado, según el catálogo
35. Reporte de operaciones inusuales, mostrar el ingreso neto y no el ingreso bruto, es decir de la suma de los ingresos restar todos los gastos
36. Para el reporte de operaciones inusuales, para los menores que tengan más de 1500 UDIS, considerar los ingresos/egresos del tutor.
37. En el formulario de póliza, poner un botón para ver las denominaciones correspondientes de los movimientos en efectivo
38. Nueva consulta de MBATCH en la cual yo regrese el estado de cuenta del socio. Se usaría la funcionalidad que ya existe en SAC del estado de cuenta formado en HTML.
39. Reporte de préstamos/seguros, agregar columna de sexo. Se refiere al reporte de servicios, donde tienen un servicio de seguro de préstamo. Se agregó el campo en los 2 "sabores" del reporte.
40. Formato solicitud de ingreso, en referencia al propietario real, en caso de no haber propietario real de los recursos para este socio, que aparezca el mismo nombre del socio. Se usa una compleja consulta SQL con UNION y DERIVEDTBL, además de un campo de fórmula NombreRealOpc.
41. Se ajusta la propiedad DropDownWidth en algunos combos. Esta propiedad establece el ancho de la lista desplegable de los combos. Se establece en el doble del tamaño del combo, para que muestre correctamente valores con muchos caracteres, como nombres de países, etc.
42. D841: RFC y CURP, cuando está vacío, poner ND. Ya quedó listo.
43. D841: Número de certificados de aportación ordinarios, monto de certificados de aportación ordinarios, excedentes también, dice el manual oficial, en caso de informar datos de menores de edad, reportar en ceros. Dice la entidad, en inversiones, también reportar en ceros. Listo.
44. D841: Pide PAP que en el número de contrato aparezca la misma clave del socio. Listo.
45. D841: Tipo de producto, los correctos son: 5-exigibilidad inmediata, depósitos de ahorro, libres de gravamen, y 6-exigibilidad inmediata. Listo.
46. D841: Saldos: Reporta PAP que hay errores en los saldos (iniciales, depósitos, retiros, finales) Aquí la observación es que se redondea el saldo de cada socio al peso mas cercano, por requerimientos del formato oficial del reporte; por ello, en cada cuenta hay diferencias de centavos, que en el total del reporte ya representan algunos pesos.
47. Ampliar el catálogo por default del campo PRESTOTOR.finalidad, del tradicional que incluye consumo, comercio, microcréditos y vivienda, al ampliado con 7 subcuentas para consumo, 6 para comercio, 3 para microcrédito y 2 para vivienda. El catálogo mínimo no indica las 3 subcuentas para microcrédito, pero algunos reportes regulatorios si: con pago semanal, quincenal y mensual. Los créditos ya clasificados como consumo, comercio o vivienda pueden seguir así, pero se admite la posibilidad de cambiarlos con alguna sentencia SQL. Préstamos nuevos también pueden clasificarse con cualquiera de las nueva finalidades. En algunos reportes, se "normaliza" a las 4 clasificaciones básicas. En el reporte R04-C451, mostrar la clasificación de crédito respectiva al nuevo catálogo de finalidades. P. ej. 131103000000 corresponde a Consumo-Personales.
48. En el reporte de buró de crédito INTF, eliminar campos opcionales que no tengan dato, es decir datos tipo "00"
49. En el reporte de BC INTF, no enviar domicilio del empleador, si no está completo, porque es rechazado
50. Checar que  no se pueden cancelar socios porque tienen servicios ligados, aunque ya este en ceros el saldo
51. En ocasiones se duplicaban los nombres de las personas relacionadas en la lista en Personas/Actualizaciones/Personas relacionadas. En BD no existe tal duplicidad. Al hacer la consulta Tsql, tampoco se duplican. Se pudo reproducir el error y luego ya no. De cualquier forma se limpia el grid en TraerDep. GroupBox1.Leave llama a Traer_Socio que llama a TraerDep.
52. Se detectan algunos problemas en el reporte de historial de préstamo de MCOB, posiblemente cuando hay cobro de servicio (no hay préstamo relacionado) y al crear un nuevo evento (visita) de un préstamo que a la fecha ya estaba pagado. También calculaba mal el saldo inicial de los préstamos del socio bajo ciertas condiciones.
53. En calcprestamo4, por eficiencia, se puede recibir como parámetro un recordset con varios préstamos, cada uno con sus movimientos. Se busca el préstamo deseado para calcular sus valores desde la posición en que ya estaba el recordset. Si no se encontraba el préstamo, se cerraba el recordset (.close). Es indebido que este sub cierre una tabla que se recibe como parámetro. Daba errores en el reporte de historial de préstamos de MCOB.
54. Ver la posibilidad de eliminar los registros de la tabla SOCIOSPAS para los que no haya movimientos. select * from sociospas where sucursal+cast(maymen as nvarchar(2))+clavesocio not in (select sucursal+cast(maymen as nvarchar(2))+ClaveSocio from movahorro). Para todas las sucursales. Hacerlo dentro de especiales/eliminar mov. cancelados.
55. En MCOB/reporte de historial de préstamos, evito que salgan los vencimientos según el Plan de Pagos, después de que el préstamo haya sido pagado
56. En el procedimiento ManError, que despliega los errores en pantalla y los guarda en BITACORA, guarda una fecha usando el formato dd/MMM/yyyy, lo cual es inadecuado, porque MMM regresa una descripción de mes; en algunos s.o. esta descripción es con punto, por ejemplo ene., lo cual ocasiona errores. Un formato correcto sería dd/MM/yyyy, es decir, según formFecha, o sin formato, simplemente CDate(FechaUso & " " & TimeOfDay)
57. Reporte de op. inusuales, vuelven a aparecer movimientos de liquidación anticipada y no efectivo. Al parecer estaba el valor PolPagAnt
58. INTF buró de crédito: el segmento TL debe comenzar con TL02TL01, a pesar de lo que dice el manual correspondiente emitido por BC
59. Implementar una nueva consulta XML llamada UPDATE, que MBATCH recibe para actualizar la colonia, teléfono fijo, teléfono celular y domicilio del socio
60. INTF buró de crédito: quitar el elemento 20, garantía del crédito, que la entidad usa para otras cosas
61. INTF buró de crédito: préstamos que ya estan pagados, pero se reportan a una fecha anterior, aparecen con clave de observación CC, lo cual no debe ser porque aún no estaban pagados. Lo mismo para reporte de BC tipo CSV y para el reporte de circulo de crédito.
62. Al modificar un préstamo, verificar que la fecha de entrega del mismo corresponda con la fecha de la póliza
63. Envolví todo el código del ManError en un try-catch, para evitar que este proceso, que recibe y maneja errores, genere un nuevo error, lo cual es problemático de manejar
64. En MBATCH, agrego la etiqueta <fecha> al regresar un XML tipo loans get, loans retrieve, person-loans retrieve, payment get, payment post y savings post. Es decir, al regresar o registrar los datos de un préstamo o ahorro, regreso la fecha a la que son válidos los saldos o fecha del registro de movimientos (equivalente a la fecha de uso del sistema).
65. MCOB marcaba error al intentar cargar la librería de Crystal Reports. Hay que cambiar la configuración de 64 bits a 32 bits. Aparentemente las librerías de CR solo funcionan con esta configuración. Entrar a las propiedades del proyecto/compile/target CPU/x86. Hacer esto para el resto de las aplicaciones, incluido QLab.
66. MCAL: la estructura 2-riesgo persona PLD, calculaba incorrectamente el valor para los productos financieros a utilizar, en algunos casos no sumaba todos los valores de cada tipo de producto para obtener la suma final (error en la fórmula de mcalCuenta)
67. En IC, se agrega el campo PARAMETROS.CarpetaCFDI, que corresponde a la carpeta donde el usuario almacena los comprobantes CFDI, de los cuales se detectará cual no se ha importado a IC, mediante su UUID, para poderlos importar automáticamente
68. En IC, agregar un formulario para leer los comprobantes CFDI de la carpeta PARAMETROS.CarpetaCFDI, detectar si  no han sido importados a IC, seleccionarlos con un checkbox y poderlos importar. El campo POLIZA.TipoGen ahora puede tomar el valor 2-lectura de CFDI. Estas SI se pueden modificar por el usuario, a diferencia de TipoGen=1, generadas desde SAC.
69. Crear un nuevo formulario, frmConsultaPEP, que permita consultar masivamente personas mediante un proveedor externo de consulta de PEPs. Por lo pronto funciona con Quien es Quien. Ya se había retirado la funcionalidad, se vuelve a incorporar.
70. Agregar una versión del reporte de captación, R08 D 0841, donde se agreguen 2 columnas al final, con la fecha de cancelación del socio (en su caso) y su status (EsCancelado), activo o cancelado
71. QLAB: en los formularios que tengan un C1FlexGrid, si yo utilizo el Enter para seleccionar una opción de un combo dentro del grid, pongo para el formulario AcceptButton=none
72. La entidad SMC desea un nuevo formato de impresión para préstamos, recibo de garantía, se llama ReciboGarantia.rpt y está basado en AutorizacionSIC.rpt
73. SMC desea un nuevo contrato de ahorro, ContratoAhorro2.rpt, además de los 2 ya existentes
74. No se podía crear nueva sucursal desde SAC, se hacía referencia al campo TASAS.zona, que ya no existe
75. QLAB: Al agregar un nuevo examen a una persona, no restringir el doctor
76. QLAB: Al agregar un nuevo paciente, quiere el QFB que ahí mismo se seleccionen los examenes a realizar, pero esto es repetir funcionalidad, es más práctico agregar un botón "generar examen"
77. QLAB: Establecer status a los examenes de persona: al generar la orden, terminado, y entregado (además de cancelado). Se agrega el campo EXPER.status
78. QLAB: Desde frmExPer, poder imprimir ticket, imprimir orden. En las propiedades del proyecto, en References, oprimo Add, browse, recent, y agrego de CrystalDecisions, shared, crystalreports.engine y windows.forms. Creo mi propio módulo de código modImpresion, en base al de SAC, y copio como vínculos desde SAC, CrystalReportClass.vb y frmCrystalViewer.frm
79. QLAB: Agregar observaciones al realizar un examen de persona. Nvarchar 400.
80. IC, lectura automática de CFDI, no desglosar, acumular los movimientos en solo dos conceptos, IVA y monto principal
81. En MBATCH, en la consulta LOANS, regresar también datos del aval, nombre, domicilio y teléfono (manejan máximo 2 avales) (query type="person-loans")
82. Agregar varios campos en SOCIOS, con el fin de complementar una matriz de riesgo de crédito: gastos por deudas, formales e informales, tipo de comprobante de ingresos, formal o informal (CompIng),  Primer pago del préstamo (para evaluar capacidad de pago actual), ya existe {PagoProm}
83. Reutilizar el campo SOCIOS.zona, para zona de residencia (zonas locales y zonas foráneas). Agregar como un valor reconocido de la tabla VALORES. Agregar las zonas por default: norte, sur, este, oeste, noreste, noroeste, sureste, suroeste, centro, foráneo1, foráneo2 y foráneo 3, esto para la nueva matriz de riesgo de créditos.
84. Agregar "Experiencia de pago" para MCAL. Crearlo como un campo calculable en la tabla PRESTOTOR, y calcularlo automáticamente: pago montos similares o superiores, pago montos inferiores, sin historial crediticio. Así como "Experiencia de ahorro" en la tabla SOCIOS, socio de recién ingreso; ahorro constante, más de 3 veces por mes; ahorra de vez en cuando, máximo 2 veces por mes; sin hábitos de ahorro, deposita solo la garantía líquida
85. Ya existe Historial de pago BC, tomarlo para MCAL. Por si alguien llegara a usarlo, se agrega también el historial de pago de CC.
86. Se implementa la nueva estructura de calificación de cartera (credit scoring) para PV
87. En el aviso de cobranza, al parecer no esta enviando el SaldoServ, campo de parámetro, a crystal reports. Estaba mal referenciada la columna en ImprimirOficioPre0
88. Para los cobros de seguro de préstamo, primero generar un cargo al socio, pero no contra efectivo porque no sale efectivo, considerarlo como cuentas de orden. Manejar los mismos tipos de mov en MOVSERVICIOS, 0 y 1, pero sin datos del socio. Crear un formulario frmProgServ, que crea estos MOVSERVICIOS en diversas fechas y para diversas personas.
89. Aumentar MOVUSUARIOS.denom, para almacenar las denominaciones, de 35 a 50 caracteres. Se presentó el caso de un gasto que generaba un denom de 36 caracteres, si bien en casos extremos pueden ser aún más grandes.
90. En el segmento TL del reporte de buró de crédito reportaba la clave de observación como CC, para todos los préstamos después del primero con CC; es porque la variable no se inicializaba, quedaba el valor anterior
91. Se modificó la lectura de CFDIs en IC para considerar y distinguir las facturas recibidas y las emitidas (mediante Emisor y Receptor en el XML), y así intercambiar cargos por abonos y visceversa de ser necesario. También, no se pueden leer varios CFDIs en una sola póliiza contable, si se mezclan facturas recibidas y emitidas (porque la póliza tiene que ser de ingreso o de egreso)
92. Se agrega un nuevo documento de impresión de Crystal Reports en la lista de actualización de personas, se trata del CheckList.rpt, para verificar los documentos entregados en físico por el socio
93. El formato ReciboGarantia.rpt requiere nuevos campos para impresión, la clave del contrato que garantiza el préstamo, y su monto. Para obtener la clave del contrato ligado al préstamo, uso la instrucción SELECT p.*, s.*, c.sucursal as sucursalcontrato, c.clavecontrato FROM  prestotor p LEFT JOIN socios s on p.sucsoc=s.sucursal and p.maymen=s.maymen and p.clavesocio=s.clavesocio LEFT JOIN continv c on p.sucursal=c.sucpre and p.claveprestamo=c.claveprestamo WHERE p.ClavePrestamo={?ClavePrestamo} and p.Sucursal='{?Sucursal}'"
94. Modificar el formato de CR CartaMandato.rpt, para que reciba tres nuevos parámetros, sucursal, claveprestamo y fecha de vencimiento. Con estos se crea una consulta a BD para traer los datos del préstamo. Como estan relacionados, también se modifican ConfirmacionPago y ConfirmacionFirma
95. Ocurría al dar de alta un préstamo que se establecía como cartera tipo II
96. PV sigue reportando que hay movimientos dobles de pago de préstamo realizados por MBATCH. Prestamo pv-3291 gabriela maria hernandez ochoa, al hacerle un abono recibido mediante mbatch, al parecer hace 2 o 3 polizas. Se creó un xml tipo payment post, ad hoc, y no se pudo repetir el error. Agregar transacciones en las operaciones de MBATCH que involucren agregado y actualización de información, porque cabe la posibilidad de que después de guardar en BD, se ocasione un error y no se informe a la app de android de que se hizo el movimiento, y esto se evita con las transacciones. También se evita agregar un movimiento a préstamo, si ya hay otro reciente (menos de 10 minutos). Se usa un T-SQL como la siguiente select * from movprestamo where sucdes='PV' and claveprestamo=6450 and status=0  and fecreal='19/06/2019' and datediff(minute, hora, '19/06/2019 21:37')<10
97. Que no se modifique la naturaleza de las operaciones (productos usados) automáticamente por SAC, cuando son socios muy recientes, porque la entidad captura manualmente este dato. No calcular ningún campo del perfil transaccional en socios recientes. La 26 de las Disposiciones de los artículos 71 y 72 indica “Las evaluaciones se realizarán sobre aquellos Clientes cuya apertura de cuenta o celebración de contrato se hubiere realizado al menos con seis meses de anticipación a la evaluación correspondiente.”
98. Reporte R04-C-0451, redondear la tasa anual con 0 decimales. Es una petición extraña, porque no es lo mismo una tasa de 13.5 que de 14 anual, así que asegurarse. El documento oficial indica Deberá reportarse sin el signo de “%”, a cuatro decimales y en base 100, ejemplo: 20% se reportaría 20.0000
99. Reporte R04-C-0451, la descripción del producto de préstamo, agregarle al inicio la clave de producto
100. Ampliar SOCIOS.documentacion de 12 a 17 caracteres, para almacenar la existencia de 5 documentos mas: verificacion domiciliaria, perfil transaccional, aviso privacidad, certificado de aportación,solicitud de ingreso. Cambiar los checkbox por una checkedlistbox. El formato CheckList.rpt tomará este campo para presentar en una tabla qué documentos se han recabado del socio.
101. Que el formato de ChequePoliza, tenga el nombre de producto de prestamos, tipo y tasa, Numero del socio, fecha de vencimiento, nombre del banco y cuenta. Como se muestra en la imagen. Envío todo como un texto en el parámetro Concepto del formato CR.
102. Reporte de operaciones de 24 horas. Reportar las operaciones inusuales, relevantes e internas preocupantes ocurridas las últimas 24 horas. DCG art 71 y 72, 45o. DCG art 124, vigésima quinta. Señalar  en la columna de Descripción de la operación, la leyenda Reporte de 24 horas.
103. Hubo cambios en el XML que regresa Banxico con el tipo de cambio del dólar. Ahora el atributo BANXICO_FIGURE_TYPE regresa un string vacío, "". Anteriormente regresaba un string "TipoCambio". Se modifica la subrutina TraerDolar para que refleje este cambio.
104. La entidad SMC reporte que obtiene planes de pago caóticos, incluso con 2 fechas de pago similares consecutivas. Usan pago semanal (7 dias) con dia de pago -1, sincronizado con PPI. No se debe usar pago semanal con dias preestablecidos (sincronizado con PPI, tambié es un tipo de dia preestablecido)
105. Implementar matriz de riesgo de PLD para SMC
106. No numerar los renglones del reporte de operaciones relevantes, inusuales o preocupantes, si el formato de reporte es el oficial para SHCP, IIf(cbSabor.SelectedIndex = 0, True, False)
107. Había un UDPATE en vez de un UPDATE en la intrucción para actualizar datos de consulta de PEPs, frmConsultaPEP, o barrido masivo.
108. Al modificar un préstamo en el formulario de préstamos, proceder como en el formulario de personas, limpiar forma y regresar a la captura de llave primaria, pero sin borrar ésta
109. QLAB: Determinar un precio base por tipo de examen, o por detalle de examen (DETALLEEX). Al crear un nuevo examen (EXPER) crear también un movimiento de abono por el precio base.
110. El 26/jun hice un cambio en el sub Modificar de frmPrestamos, para limpiar forma y regresar a la llave primaria. Esto ocasionaba que se limpiaran datos en pantalla, por lo que ocasionaba error al autorizar o entregar el préstamo, puesto que los subs de autorizar y entregar hacen uso del sub modificar.
111. Al entregar un préstamo, en el formulario correspondiente (frmEntPrest) se pueden modificar las fechas de autorización, entrega, inicio, PPI. No permitir que la fecha de entrega sea posterior a fechauso. La fecha de inicio y PPI si pueden ser fechas futuras.
112. Debido a una instrucción SQL mal estructurada, al entregar cualquier préstamo, se establecía como cartera tipo II (cartera emproblemada). La instrucción establecía FecTipoCartera='SYSTEM.DBNULL.VALUE' en vez de FecTipoCartera=NULL que es lo correcto. Esto causaba también que se calcularan mal las estimaciones preventivas para estos préstamos.
113. Se agregan los parámetros clave de cuenta (clavecue) y cheque a todos los formatos cheque y chequepoliza de CR. En SAC se mandan los valores correctos, de GuardaBancos a frmCheque, de este a ImprimirCheque, de este a CrystalReports.LoadRpt. Agregar también el nombre del banco, NombreBanco, el cual lo obtengo con una consulta T-SQL en GuardaBancos cuando es necesario.
114. Cambiar la redacción del concepto "Tutor económico" (tutor eco.) por "Proveedor de recursos" (prov. rec.). En SAC, en la tabla y campo SOCIOSDEP.tiporel, se almacena 1 para dependiente económico y 2 para tutor económico, que son conceptos complementarios. Es decir si A es tutor económico de B, entonces B es dependiente económico de A. Cambiar solo la redacción.
115. Agregar para MCAL los parámetros {propreal} y {provrec}, que significan propietario real y proveedor de recursos, respectivamente, que tendrán el valor 1 cuando sea el caso, y 0 en caso contrario. Estos valores se toman de la tabla y campo SOCIOSDEP.tiporel. Agregar también {prodcre} que regresa la clave de producto del préstamo deseado, tomado de PRESTOTOR.clavetasa.
116. En préstamos renovados/reestructurados, había un error por una división entre cero. En la instrucción SaldoGarLiq += MontoPreR / TipPreR a veces TipPreR (los tantos del préstamo que se renueva) era cero. Se cambió por SaldoGarLiq += IIf(TipPreR = 0, 0, (MontoPreR / TipPreR))
117. Agregar también {saldopas}, para el saldo de la suma de los pasivos del socio, y {saldocont} , el saldo de los contratos (de inversión), a la fecha de consulta. Todo esto para su matriz de riesgo de PLD. Para esto mandar llamar a los procs. que calculan saldos global o individualmente, en el mismo lugar donde se llama a CalcCamposPLD. Con los saldos ya calculados (en una tabla temporal #sociospastmp) llamar a mcalRecalcSaldos, enviando como parámetro estos saldos, y asi obtener la calificación de riesgo de cada persona.
118. Cambiar nomenclatura para MCAL. Catálogo -> Estructura. Expediente -> Matriz de riesgo . Puntuaciones -> matriz de riesgo. Valuación, valor -> saldo.
119. Se renueva totalmente la metodología de recálculo de montos bloqueados, sobre todo para trabajar correctamente en un ambiente multipréstamo. Cada vez que se liquida un préstamo, o que se entrega uno nuevo, se recalcula el monto bloqueado total, resultado de bloquear para cada préstamo activo del acreditado.  Si se está liquidando un préstamo, no fuerza el monto bloqueado, solo bloquea, cuando mucho, el saldo del ahorro. Pero si se está entregando un préstamo nuevo (o renovando/reestructurando) si obliga a que se tenga todo el monto bloqueado necesario para todos los préstamos activos.
120. Se agrega impresión de códigos de barras a QLAB. En bin/debug está el archivo TECIT.tbarcode.dll. Se instala Formas Comunes\Programas de terceros\TBarCode_Setup
121. En el formulario de socios, en ocasiones marca error al guardar/modificar. El campo ocupación es muy extenso. Agregar una función mid para limitar si pasa de los 30 caracteres.
122. SAC no permitía hacer abonos a préstamos castigados, porque comúnmente ya no tiene partes sociales (mínimas) el socio. Se modifica el comportamiento para que solo se restrinja el movimiento de pasivos y de servicios cuando no hay p. soc. min. Siempre se podrá abonar a préstamo.
123. No lee el UDIS de Banxico, checar si cambió el XML. Ahora el atributo BANXICO_FIGURE_TYPE regresa un string vacío, "". Anteriormente regresaba un string "TipoCambio". Se modifica la subrutina TraerUDIS para que refleje este cambio.
124. Al reestructurar/renovar un credito, bloquear solo lo correspondiente al saldo insoluto del credito que se reest/renov, y no en base al monto inicial, como se hace ahora. Se crea el campo PARAMETROS.CalcBloq, con valores 0-sobre monto inicial 1-sobre saldo insoluto. Actuaría tanto al otorgar como al pagar cualquier préstamo. En ese momento se calcula el monto bloqueado de todos los préstamos activos del socio. Si es una entrega, se fuerza a se tengan los saldos mínimos, si es un pago de préstamo, no. También se crea la variable global vCalcBloq
125. Se modifica el cálculo de monto bloqueado como aval, en el proceso CalcBloqueos. Se restringía a que la persona calculada fuera "aval solitario" por lo que se buscaban préstamos donde fungiera como aval pero los demás campos de aval estuvieran vacíos. Ahora basta con que funja como aval, aunque no sea el único.
126. Actualmente existen 2 tipos de estructura de MCAL, para riesgo de préstamo y para riesgo de persona PLD. Agregar un tercer tipo, enfoque basado en riesgo. Cada uno de estos 3 tipos de catálogo se puede tomar de varios catálogos preexistentes en SAC/MCAL.