Logo

ClearLight
Sistema Integrado para la Administracion

Su IP: 54.236.62.49


Cambios anteriores (2006-2008)

Desde marzo de 2011, todos los cambios realizados a los programas de ClearLight se publican como pequeñas noticias en nuestra página de FaceBook.

Esta página se conserva sólo con fines de referencia, pero no seguirá siendo actualizada.

Marzo 21, 2011

Coleccion de las noticias de actualizacion publicadas en el foro de Facebook desde el 11/02/2011:

11/02/2011:
Cuando un proceso interno de ClearLight iniciado desde un proceso originado en un script llamaba a su vez a un script, se producía un mensaje de error.
Dicho mensaje de error fue eliminado.

- 14/02/2011 (V6.8.57):
Dependiendo de un valor en el registro, se permite especificar el costo unitario de los artículos que ingresan mediante ajustes de inventario.
El valor de registro es EditarCostoAjustes (en ClearLight\General) y los valores admisibles son 0 (no editar el costo) y -1 (permitir la edicion).

Version 6.8.65 (22-02-2011):
- Se puede agregar una retencion de ISLR en las compras de mercancía.
- Los proveedores almacenan el porcentaje de retencion de IVA a practicar sobre sus facturas.
Requiere la ejecucion de un procedimiento de actualizacion sobre las BBDD.


Version 6.8.68 (28-02-2011):
- Se agregó a la Factoria la funcion checkForWildcards(codigo, nombreTabla, columnaCodigo) que permite la asignacion de sufijos correlativos para la creacion de nuevos códigos.
- Se agregó la función Descripcion() a la clase clsMINV (movimientos de inventario), que devuelve la descripción del articulo afectado por el movimiento.

Version 6.8.70 (28-02-2011):
- Se agregó una cuarta pestaña en el formulario de compras (facturas/consignaciones/ordenes de compra) en la que se muestran las cotizaciones recibidas de todos los proveedores y las veinte compras más recientes para el último artículo introducido.

Version 6.8.71 (02-03-2011):
Se agregó lógica para detectar cambios accidentales de la fecha.
Por una parte, no se admiten diferencias mayores a cinco minutos entre la hora del servidor SQL y la de las estaciones de trabajo.
Luego se agregó un campo con la Fecha de Ultimo Uso a la tabla de contadores (que se carga como parte de la creación del contexto de operacion de la empresa). En LoadContadores se bloquean intentos de entrar con fechas anteriores a la fecha de ultimo uso, y se pide confirmacion si han pasado mas de "MaxDiasInactividad" desde esa fecha. "MaxDiasInactividad" se define en el registro.
Ahora solo un usuario torpe o mal intencionado puede causar el problema del cambio indebido de fecha.

Version 6.8.75 (21-03-2011):
Se reemplazó el límite fijo de unidades válidas en una etiqueta de balanza (36) por un valor especificado en el registro (ClearLight\General\MaxQty), con un valor por omisión de 36.
Es un cambio menor que sólo debería producir diferencias en las aplicaciones de punto de ventas y en casos muy particulares.

Febrero 9, 2011

Coleccion de las noticias de actualizacion publicadas en el foro de Facebook desde el 28/11/2010:

- 28/Nov/2010: se modificó la rutina del argumento SCRIPT en la linea de comandos para que busque el archivo siguiendo el método definido para el resto de los scripts:
1.- Argumento
2.- Carpeta de programas
3.- Carpeta de datos activa
4.- Carpeta especificada en <UbicacionScripts>

- En el formulario de transcripción de notas de debito y credito había un error cuando se creaba una nota de un proveedor: al seleccionar el código se actualizaba el contenido en el editor de documentos fiscales, y el tipo de documento fiscal se inicializaba incorrectamente. Ya está arreglado.

- No se en qué momento invertí el signo de una operación en la actualizacion del saldo de las consignaciones cuando se procesaban facturas de compra en modo de liquidación de consignaciones. El asunto es que acabo de arreglarlo.

- Al modificar la forma de consultas de movimientos de banco, en medio de un frenesí de cortar y pegar, reemplacé el codigo del botón "Imprimir" con el de los eventos Change de los controles editables. A consecuencia de ello, al pulsar "Imprimir" lo único que pasab es que el botón "Guardar" se hacía visible.

- Se mejoró la información devuelta al producirse un error en el proceso de los ajustes de inventario cuando el artículo referenciado en un detalle había sido eliminado.

- Se agregaron dos notificaciones a posExt.vbs:
1.- createNewDocISPC(elDoc [As clsDocumentosISPC): elDoc acaba de ser incorporado a la cuenta de una entidad
2.- addDCE(elDetalle [As clsDetalleCuentaEntidad]): elDetalle acaba de ser registrado en la cuenta de una entidad.
Ambas notificaciones se producen dentro de una transaccion activa, de manera que no es recomendable ninguna interacción con el usuario o con dispositivos "lentos" dentro de estos eventos.

- Se agregó el selector "ProcesadorCotizaciones" a Factoria,CrearObjeto, para acceder a una instancia de la clase CProcesadorCotizaciones.
(V6.8.37)

- Se corrigió un error que causaba que los detalles de los documentos cobrados (subDocsMB) mediante un depósito o transferencia en una de nuestras cuentas bancarias no se asociaran con el depósito (V6.8.37, 24/12/2010).

- Se agregaron los siguentes eventos de notificacion a posExt.vbs:
1.- AnularDCE: notifica la anulacion de un DetalleCuentaEntidad
2.- AnularDocISPC: notifica la anulacion de un DocumentoISPC
3.- RevertirMVB: notifica la anulacion de un movimiento de banco
4.- ReverirDVC: notifica la anulacion de una devolucion de compra
5.- RevertirDVV: Notifica la anulacion de una devolucion de ventas
6.- RevertirCSG: Notifica la anulacion de un recibo de mercancia en consignacion
(v6.8.38, 25/12/2010)


- V6.8.39: Corregido un error que hacía que la ventana de interfaz de entidad de clientes no apareciera en la barra de tareas.

- 20/01/2011: El programa de cierre de turnos (CierreX.exe) permite especificar la distribución de los fondos en caja por tipos y/o denominaciones, de acuerdo con un esquema configurado en el registro.
Los datos de la distribución de denominaciones no se guardan, ni se usan para ningún fin adicional. El cliente que planteó el requerimiento lo caracteriza como una manera de "reducir errores de conteo y forzar al operador a organizar el efectivo por denominaciones".
Si a alguien le sirve, está disponible en el servidor FTP. En la carpeta "Custom" se encuentra el archivo "denominaciones.reg", con un ejemplo de como se definen las diferentes denominaciones.
El programa CierresX.exe, que es bastante independiente del resto del sistema, puede descargarse de la carpeta Support.

09/02/2010, V6.8.50:
- Se cambió el método para asignar la numeracion interna de los DocumentosISPC. Originalmente se generaba el número sumandole uno (1) al número mas alto registrado. Eso causó algunos problemas en un script de exportación de documentos. Ahora se obtiene a partir de la tabla de Contadores.
- Se agregó una opción para generar una ista de consignaciones desde el menú de reportes de compras. El reporte se genera a partir del archivo listaConisgnaciones.rcl, que debe estar contenido en la carpeta de datos (una vez actualizado el sistema, se debe copiar el reporte desde la carpeta bdMatriz, en el directorio de programas, al directorio de datos de la empresa)
- Es posible facturar explicitamente una consignacion desde la forma de consultas. Para acceder a la forma de consultas de la consignación, se hace doble clic sobre el numero de la consignacion en el listado de consignaciones.
Esta actualizacion requiere la ejecución de un script de actualizacion de la BBDD (Upgrade6.8.50.sql, o Upgrade6.8.50.vbs) disponible en el servidor FTP.
Hace una hora aproximadamente. · Eliminar mensaje

-V6.8.52 (09/02/2011): las notas de credito emitidas a clientes que no estén asociadas con un registro fiscal (entrada al libro de ventas), no llevarán numero correlativo externo (solo se usará el correlativo interno, común a las notas de clientes y proveedores). La idea es eliminar los "huecos" en la numeración de las notas que llevan efectos fiscales.

Octubre 11, 2010 (v6.7.8)

Otra revision importante.

Construir un sistema totalmente abierto, como lo es ClearLight tiene grandes ventajas, pero tambien tiene sus inconvenientes. El principal es que cualquiera puede meter mano en cualquier parte y alterar cualquier cosa. Para evitar eso, es necesario que las organizaciones y clientes usuarios de ClearLight diseñen e implementen políticas de seguridad muy bien pensadas en sus redes y equipos individuales. Pero ninguno, ni uno solo, de nuestros usuarios conocidos ha implementado ni una sola restriccion de seguridad en sus instalaciones informaticas.

La consecuencia es que cualquier usuario puede hacer cualquier cosa, desde borrar o alterar scripts o acceder a la base de datos y realizar en ella los cambios que desee.

ClearLight tiene mecanismos de redundancia que hacen que cualquier cambio indebido en la BD (a menos que sea muy bien ejecutado) produzca inconsistencias en los reportes de control de inventario o saldos de cuentas. La corrección del código que mantiene estas redundancias ha sido comprobada analíticamente (y es la misma desde hace aproximadamente 11 años), y verificada experimentalmente centenares de veces. Sin embargo, siguen apareciendo inconsistencias, y dichas inconsistencias siguen siendo achacadas a errores del programa, y no a operaciones o alteraciones indebidas de las BBDD (o a errores de los sistemas de gestion), que son los verdaderos responsables.

Una de estas estructuras redundantes son los registros de resumen mensual de existencias y saldos de las cuentas de las entidades, mantenidas en la tabla SaldosEntidadPeriodo. Cuando se quería conocer el saldo de una determinada entidad para una fecha dada, se buscaba el registro de SaldoEntidadPeriodo inmediato anterior a esa fecha y al saldo contenido en él se le sumaba el balance de los movimientos registrados a partir del inicio de ese período. Eso no solo ofrecía un control redundante que permitía detectar no solo alteraciones indebidas de la BBDD, sino que además permitia ubicar el período dentro del cual se había producido la alteracion. Además de que producia una ganancioa considerable de eficiencia, al necesitar la lectura de una cantidad relativamente pequeña de registros.

Ahora, cuando se quiere conocer el saldo de una entidad para una fecha dada, se suman los valores de todas las transacciones registradas para esa entidad hasta esa fecha.

Una nota importante: si su base de datos incluye transacciones anteriores al 1/01/2008, no debe actualizar a la versión 6.8 sin ponerse en contacto con nosotros previamente. Es necesario reajustar los montos expresados en Bolivares Viejos anteriores a 2008 y desactivar la conversión. Es recomendable que solicite soporte técnico para el proceso de actualizacion.

Julio 16, 2010 (v6.7.41)

Mayo 13, 2010 (V6.7.30)

 

Abril 28, 2010 (V6.7.25)

Abril 22, 2010 (V6.7.21)

Abril 15, 2010 (V6.7.20)

Abril 2010 (V6.7.18)

Marzo 2010 (v6.7)

Enero 2010 (v6.6.45)

Noviembre 2009 (v.6.5.100 / 6.6)

Octubre 2009 (v.6.5.84)

Septiembre 2009 (v6.5.75)

NOTA:
En bases de datos SQL Server con muchas facturas, el procedimiento de actualización puede ser bastante largo (para un cliente con 2M facturas y 24M detalles se necesitó una hora y media). En estos casos, es más conveniente utilizar el script SQL (MSSQLUpgrade6.5.75.SQL, tambien incluído en el archivo de upgrades) en lugar del script VBS, a fin de evitar el error de tiempo de espera agotado.

Durante la actualización, las tablas FacturasPOS y RenglonesFacturasPOS quedarán bloqueadas a cualquier intento de actualización. No actualice mientras el programa de punto de ventas esté siendo usado.

Descargue de aquí el archivo de acualizacion: Upgrade.zip 

Julio 2009 (v6.5.44)

Junio 2009 (v6.5.33)

Mayo 2009 (v6.5)

Abril 2009 (v6.4.88)

Marzo 2009 (v6.4.80)

Febrero 2009 (v6.4.70)

Enero 2009 (v6.4.50)

 

DESCRIPCION DEL PROCEDIMIENTO GENERAL DE ACTUALIZACION