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.
- Se incorporan los ChequesDevueltos como documentos
acreedores. Si el programa se usa en combinación con el formulario
detallado de ingreso de caja, es posible identificar el origen de los
cheques devueltos a partir de su referencia. Esto reduce el potencial de
inconsistencia y de "ruido" (informacion innecesaria) en el libro de
ventas.
- Se agregaron operaciones para "compactar" los
detalles de las cuentas de entidades y productos de inventario, que las
acumulan en el año de 1899, manteniendo su efecto pero reduciendo su
volumen.
- Se agregaron a la BBDD funciones para obtener los
saldos acumulados de las entidades comerciales y articulos de inventario
a una fecha dada.
- Se agregaron operaciones para la anulacion
(reversión) de devoluciones de ventas.
- Se corrigieron inconsistencias en la nomenclatura de
los períodos contables cuando el año fiscal es diferente del año
calendario, y se agregaron funciones para permitir que la especificacion
de los periodos contables se realicen utilizando
referencias a periodos calendario (aaaa/mm) o directamente a periodos
contables (nnnnnn).
Julio 16, 2010 (v6.7.41)
- Se agregaron a la factoría los
métodos siguientes:
Public Function
PuedeUsarAlmacen(codigoUsuario As String, codigoAlmacen As String,
Optional ByVal warn As Boolean = False) As Boolean
Determina si el usuario identificado por CodigoUsuario
puede usar el almacen identificado por CodigoAlmacen. El valor
opcionar Warn especifica si se debe dar un mensaje de
advertencia al operador si el usuario no tiene permiso.
Public Function usrDLL() As CUsrDLL
Devuelve una instancia de CUsrDll (ver
frmdlls.php) para ser usada en formularios contenidos en DLLs de
extensión.
Mayo 13, 2010 (V6.7.30)
- Los formularios de las aplicaciones de punto de
ventas pueden cambiarse de tamaño, y las preferencias de tamaño y
posición se conservan entre sesiones.
- Se agregaron eventos de notificación para CUsrDLL al
descargar cada formulario. El código de evento es «Unload», y los dos
argumentos se refieren al mismo formulario.
- Se modificó la llamada a posExt.CalcularPrecio para
permitir que la misma función determine la cantidad de unidades
vendidas. Para ello, basta asignarle desde dentro de la misma función el
valor deseado a la variable Cantidad (creada desde la función
llamante). Esta característica puede resultar útil para la
implementación de promociones del tipo 2x1.
Por ejemplo:
Public Function
CalcularPrecio()
Dim elItem
Set elItem = CrearObjeto("AlmacenItemsVenta").itemVenta(CStr(Codigo))
If elItem Is Nothing
Then
CalcularPrecio = Precio
Exit Function
End If
If elItem.TieneAtributo("3X2")
Then
If Confirmar("Comprar
3 unidades por " & _
Format(Precio * 2,
"Currency")) Then
Precio = Precio * 2 / 3
Cantidad = 3
End If
End If
CalcularPrecio = Precio
End Function
|
- Se agregaron llamadas adicionales a posExt para
permitir el ajuste de un renglón completo en las aplicaciones de punto
de ventas, y para permitir el ajuste de los precios y las cantidades (v.
posExt: control paralelo de las aplicaciones)
Abril 28, 2010 (V6.7.25)
- Se agregó el soporte para las DLL de usuario
(CUsrDLL) en la forma de interfaz de entidad de los vendedores.
- Se agregaron dos eventos de notificación para
CUsrDLL en las formas de interfaz de entidad:
1.- "Save", donde el primer parámetro se refiere al formulario y el
segundo a una instancia de la clase correspondiente que contiene los
datos recién editado. Este evento es activado despues de modificar o de
crear una nueva entidad. En la forma de Mercancias (frmVINV) el segundo
parámetro es tambien una referencia al mismo formulario, ya que la forma
de mercancías maneja instancias sincronizadas de dos tipos de entidad
(clsItemVenta y clsItemInventario)
2.- "InstanceLoaded", donde el primer parámetros es una referencia al
formulario y el segundo a una instancia del objeto cuya información
acaba de ser presentada. La forma de Mercancías tiene la misma condición
excepcional descrita en el punto anterior.
La intención de estos cambios es permitir que el controlador externo del
formulario ejecute acciones adicionales al guardar o cargar una nueva
entidad.
- El generador de reportes (RepGen5.dll) no reconocía
el cliente nativo de SQL Server como proveedor de datos. Se reemplazó el
componente local de acceso a BBDD por el componente común de la
librería.
Abril 22, 2010 (V6.7.21)
- Se revisó el procedimiento de agregar un producto a
las cuentas de mesas para que los productos duplicados se acumulen en el
renglon semejante más reciente (originalmente se acumulaban en el más
antiguo). Afecta a clrCaja7 (Comandera) y clrCaja4 (punto ed ventas
touch).
Abril 15, 2010 (V6.7.20)
- Se corrigió un error en el componente generador de
reportes (RepGen5.dll) que hacía
que la última línea del encabezado se duplicara antes de la primera
línea de detalle cuando el cierre de un grupo coincidía con un cierre de
página.
Abril 2010 (V6.7.18)
- Se agregó una lista de los medios de pago utilizados
en la cancelación de las facturas de compra o venta. Este reporte se
activa desde el formulario de consulta del documento.
NOTA: Esta actualización requiere la actualización
de CLCIC.DLL.
- Se revisaron todos los formularios para estandarizar
la presentación del texto de ayuda para cada control en una barra de
status en la parte inferior del formulario.
- Se agregó una llamada a una rutina en posExt para
permitir que las extensiones del usuario sean notificadas de los cambios
de código de las entidades principales.
Estas rutinas están declaradas así:
CambiarCodigo<Entidad>(CodigoOriginal, NuevoCodigo)
Donde:
<Entidad>::=
Cliente | Vendedor | Proveedor | itemVenta | itemInventario
CodigoOriginal:
El código original de la entidad
NuevoCodigo:
El código nuevo
Ejemplo:
Public Sub
CambiarCodigoCliente(original, nuevo)
ExecuteSQL "UPDATE Vehículos SET
Cliente = ? WHERE Cliente = ?", _
nuevo,
original
End Sub
- Se corrigió un error en la presentación de la lista
de movimientos de un banco, en el que las última línea del encabezado
sobreescribía la próxima linea de detalle a presentar.
Marzo 2010 (v6.7)
- Se agregó un control para la actualización en
masa de los productos seleccionados en la "Tabla de Edición Rápida"
de productos y servicios. Este control permite aumentar o reducir
uno o más precios de los artículos cargados, aplicando un porcentaje
o bien sumando (o restando) un valor constante.
- Se modificó el programa de instalación para
permitir especificar el tipo de proveedor de SQL deseado (Cliente
Nativo o proveedor OLE DB) y para permitir el acceso al servidor
utilizando seguridad integrada de Windows.
- Se agregó la posibilidad de intervenir en la
apariencia y contenido de los reportes definidos por el usuario
mediante el uso de VBScript. Los scripts pueden definirse dentro de
una sub-sección de la sección de ENTORNO del script de reporte.
Puede obtener información detallada en el manual de referencia del
usuario de ClearLight, contenido en el archivo de documentación (Docs.zip).
- Se pueden recibir cobros con documentos
postdatados. El sistema actualiza los saldos de los documentos y
clientes afectados por esta operación, pero no registra el ingreso
de caja ni genera los detalles hasta la fecha de presentación de los
documentos. Se agregaron dos reportes accesibles desde el menú
principal mediante la opcion Reportes/Cuentas por Cobrar; uno que
muestra los cobros postdatados por cliente y otro uq emuestra los
documentos postdatados que deberían estar en nuestro poder.
- Se cambió la lógica del control de ejecución de
procesos de "reconversión monetaria". En las versiones anteriores
los valores monetarios se reconvertían (al cruzar la frontera de
regimen monetario) a menos que un parámetro específico lo impidiera.
A partir de la V6.7 la reconversión de montos se ejecutará sólamente
si un parámetro específico lo indica. Esto se hizo para neutralizar
los posibles efectos de omitir asignar una fecha correcta al
parámetro FechaGlobal al ejecutar operaciones desde scripts u otros
componentes externos. La variable en cuestion puede definirse en el
registro con el nombre "Reconvertir" dentro de la clave HKCU/VB and
VBA Program Setttings/ClearLIght/General. Un valor de -1 activará
las reconversiones. La ausencia del valor, o un valor de 0, las
inhibirán.
- Se permite la reversión de Movimientos de Caja.
Enero 2010 (v6.6.45)
- Se agregaron a la BBDD tablas para registrar el
detalle completo de las cobranzas.
- Se modificó el formulario de consulta de precios
para permitir que se muestre sólamente el precio standard
(incluyendo IVA) o bien los cuatro precios de cada producto,
dependiento del contenido de una variable de registro
(ConsultarPrecioTodos)..
- Se realizaron cambios en el componente generador
de reportes de usuario para mejorar las posibilidades de intervenir
en su presentación mediante el uso de scripts.
- Se corrigieron errores en el registro de las
retenciones de IVA realizadas por los clientes contribuyentes
especiales en notas de crédito.
- Se eliminó del programa de creación y
mantenimiento de empresas la opción de crear empresas con BBDD de
Access. Se permite al usuario seleccionar el tipo de seguridad a
usar en las conexiones con SQL Server (Integrada de Windows /
Intrínseca de SQL Server) y el tipo de cliente a utilizar (Proveedor
OLEDB o cliente nativo de SQL Server).
Noviembre 2009 (v.6.5.100 / 6.6)
- Se agregó el campo Ubicacion a los
artículos de inventario, para permitir especificar la ubicación del
producto en un almacén independientemente de su ubicación en el piso
de ventas. La forma para la generación de ajustes por diferencia a
partir de un archivo de conteo incluye un filtro adicional para
especificar la ubicación del artículo además de la del producto.
- Al generar una nota de débito a un cliente, es
posible relacionarla con un cheque devuelto.
- Se pueden agregar opciones a la barra de
herramientas debajo del menú principal. Cada nueva opción tiene tres
atributos:
- Nombre del comando: el nombre de la opción del menú que se
desea activar, seguido de los caracteres "_Click". Por ejemplo, si
usamos el documentador para examinar los miembros del formulario
principal (mainForm), veremos una opcion de menu llamada
MC_TABLA_PRODUCTOS (el prefijo MC_ distingue los comandos de
menú). El nombre del comando sería, entonces
MC_TABLA_PRODUCTOS_Click.
- Ruta del archivo de imagen: las imagenes son iconos o mapas
de bits de 32 x 32 pixels con una paleta de 256 colores. Si la ruta
no especifica una carpeta, se asumirá que el archivo se encuentra en
la misma carpeta desde la cual se inició el programa.
- Texto de ayuda emergente: es el texto que se muestra al
permitir que el puntero del ratón se detenga sobre el botón.
Estas opciones se especifican en el registro, en la clave
HKCU\Software\VB And VBA Program Settings\ClearLight\Botones, en
valores alfanuméricos identificados con números correlativos a
partir de uno, separando cada una de las opciones con una barra
vertical ( | ).
Ejemplo (tomado de un archivo .REG):
[HKEY_CURRENT_USER\Software\VB and VBA Program
Settings\ClearLight\Botones]
"1"="MC_CONS_FACT_Click|WriteOps.ico|Consultar facturas por cliente"
"2"="MC_TABLA_PRODUCTOS_Click|C:\\Mis
Documentos\\Fuentes.VB6\\Graphics\\Icons\\Flags\\flgspain.ico|Tabla
de edicion de productos"
El primer valor (1), ejecuta el comando MC_CONS_FACT_Click (ubicado
en el menú principal en Reportes \ Ventas \ Consultar Facturas por
Cliente), usa la imagen contenida en el archivo WriteOps.ico,
ubicado en la carpeta de programas, y muestra el texto "Consultar
facturas por cliente"
El segundo ejecuta MC_TABLA_PRODUCTOS_Click (Archivo \ Entidades \
Productos y Servicios \ Tabla de Edicion Rápida), toma la imagen de
una carpeta dentro de C:\Mis Documentos, y despliega el texto "Tabla
de edicion de productos" al dejar descansar el puntero del mouse
sobre la imagen.
- Se reorganizó el menú principal para hacerlo más
intuitivo:
- las "Tablas adicionales" que originalmente se accedian desde el
menú Entidades \ Tablas Adicionales fueron colocadas bajo la opción
Parametros y Tablas Adicionales, directamente bajo la opción
Archivos.
- la opción Archivos fue reorganizada para colocar las opciones en
el orden con el que se necesitan con más frecuencia.
- La opción de Consultar Precios fue movida hacia la derecha en el
menú, inmediatamente antes de la ayuda.
- La opción Tipo de Cambio del menu de Archivos fue movida dentro
del menú de Parametros y Tablas Adicionales.
- El menú de operaciones fue reorganizado. Se crearon dos nuevos sub
menús, Cuentas por Cobrar y Cuentas por Pagar, y las operaciones de
cobranzas, pagos, emision de notas y mantenimiento de documentos
fiscales y retenciones, que originalmente se encontraban bajo el
submenu "Administración General" fueron movidas a ellos. El submenu
"Administración General" fue renombrado como "Caja y Bancos". Bajo
el submenu de Cuentas por Cobrar se agregó una operacion para anotar
directamente retenciones de IVA practicadas por los clientes. Esta
operación no tiene ningún efecto adicional al de hacer aparecer la
retención en el reporte de IVA Retenido por Clientes.
- Las facturas de venta y compra pueden ahora ser
"revertidas". La reversión no es lo mismo que una anulación. Una
anulación debe dejar una constancia de que el documento original fue
emitido, y en ambos casos sigue realizándose mediante una devolución
de compras o ventas. La reversión produce el mismo resultado que si
el documento original nunca se hubiese emitido. ADVERTENCIA:
el uso de estas operaciones puede producir inconsistencias en los
saldos de algunas cuentas. Por ejemplo, se emitió una factura a
crédito, y se le aplicó una nota de crédito. La reversión de la
factura causa que el monto completo de la misma se acredite
nuevamente al cliente, esto incluye el monto de la nota de crédito
aplicada a la factura. El saldo del cliente, en consecuencia, será
inferior al saldo de los documentos en su expediente.
- Se permite la reversión de los ajustes de
inventario.
- Se permite la anulación de notas de entrega, aun
cuando hayan sido despachadas. Las notas de entrega que hayan sido
objeto de operaciones suplementarias o de facturas parciales siguen
teniendo restricciones.
- Para acceder a las operaciones de reversión o
anulación de documentos, es necesario acceder a la forma de
presentación de los mismos. El método más directo es obtener un
reporte que los incluya y hacer doble clic con el boton izquierdo
del ratón sobre el número del documento.
- NOTA: La actualización a la versión 6 debe
realizarse directamente desde el Analizador de Consultas (SQL
Server 2000) o desde el SQL Server Management Studio (SQL Server
2005), mediante el script SQLUpgrade6.6.SQL, contenido en
Upgrade.zip.
Octubre 2009 (v.6.5.84)
- Se eliminaron los "ClientesPOS", utilizados
originalmente para almacenar la información de los clientes
registrados por las aplicaciones de punto de ventas a fin de evitar
el complejo formulario de creación de los clientes de distribución.
En revisiones siguientes de las aplicaciones de punto de ventas se
simplificó el formulario de creación de los clientes. Por otra parte
se hizo necesario establecer una relación inequívoca de los clientes
referenciados en las facturas de punto de ventas con una tabla
específica. Al depender esta relación -en muchísimos casos- del
script de impresión de las facturas, depende de lo que el integrador
haya hecho. Se redefinió ClientePOS para ser tratado como sinónimo
de Cliente, se agregó un método a los Clientes para que soportaran
la interfaz de ClientePOS y se incluyó en el script de actualización
una rutina para copiar los registros de la tabla ClientesPOS a la
tabla de Clientes.
- Las Anulaciones de Facturas en el punto de ventas
crean ahora documentos persistentes. Hasta ahora, las anulaciones se
borraban con el cierre de la sesión. A partir de ahora se mantienen.
- Se incorporaron al sistema una lista general de
facturas de mostrador y una lista de anulaciones, ambas ordenadas
por numero de caja. Estos reportes estan implementados como reportes
de usuario, activados directamente desde la aplicación. La lista de
facturas de punto de ventas usa una sintaxis compatible sólo con SQL
Server (Access está descontinuado desde la versión 6.4), y puede
requerir de pequeños ajustes para correr.
Los archivos necesarios para soportar la nueva funcionalidad (más
otra, descrita en revisiones anteriores), pueden ser descargados de
este zip. Descomprima los archivos a la carpeta de datos.
- NOTA: La version 6.5.85 presenta los
siguientes cambios en la interfaz de usuario con respecto a las
versiones anteriores:
1) Los scripts que usaban ClientesPOS y que permitían la creación de
nuevos clientes mediante llamadas al metodo Validate, abrirán
una forma diferente para la captura de datos de los clientes.
2) La opción para el mantenimiento de Clientes POS desapareció del
menú principal de ClearLight.
3) La opción "Libro de Ventas (Mostrador)" del menú de
reportes de ventas fue movida al submenú "Listados de Punto de
Ventas" de ese mismo menú, e identificada con el título
"Resumenes Diarios", ya que técnicamente, no es un libro de ventas.
Septiembre 2009 (v6.5.75)
- Se corrigieron problemas relacionados con la
presentación de datos de la contabilidad cuando el mes de inicio
fiscal es diferente de enero.
- Se mejoró el método de "desambiguación" de los
comprobantes contables relacionados con los movimientos de banco.
- Se agregó un reporte que presenta el libro de
inventario tal como lo requiere el Articulo 77 de la Ley del ISRL.
- Se agregó a la tabla RenglonesFacturaPOS una
columna de relación con la columna Numero de FacturasPOS. Esto
permitirá una mayor simplicidad en la especificacion de consultas
basadas en la relación FacturasPOS->RenglonesFacturaPOS.
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)
- El cierre mensual pasa a ser un requisito de la
relación de retenciones de IVA realizadas a nuestro favor por
nuestros clientes que sean contribuyentes especiales.
- En la ventana de cobros a cuenta se incluye una
columna para la fecha del comprobante de retención.
Junio 2009 (v6.5.33)
- Se implementó una DLL para permitir que los
recargos en las compras se registren de manera detallada y generen
documentos comerciales (V6.5.20).
- Se modificó el programa de instalación para
instalar los scripts correspondientes a los diferentes tipos de
impresoras fiscales soportadas por el sistema.
- Se retiró el soporte para las impresoras fiscales
Optimus/Wiking.
- Se realizó una revisión detallada de los
mecanismos de enlace con la contabilidad.
- Las retenciones del IVA se registran
contablemente en una cuenta diferente -si así se indica- de la
cuenta donde se registran los impuestos causados por las operaciones
de compra y venta.
- El libro de compras correspondiente a cada mes
debe ser "cerrado" para permitir que operaciones correspondientes al
mes en cuestión registradas despues de la generación del reporte (y
liquidación de impuestos con base en su contenido) puedan ser
incluídas en meses posteriores.
Mayo 2009 (v6.5)
- La versión 6.5 presenta pocos cambios externos
con respecto a la 6.4. Su elemento distintivo es una redistribución
del código, consistente en extraer las clases independientes del
contexto a un componente externo (CLCIC.DLL) para permitir el
desarrollo de nueva funcionalidad. En este sentido viene a ser un
primer paso hacia la versión 7.
- Se cambió el método de emisión y algunos detalles
en la presentación del libro de compras. Hasta la versión 6.4, el libro de compras
presentaba exclusivamente las operaciones realizadas durante el
período reportado. En la versión 6.5, los reportes incluyen todos
los movimientos "no cerrados" cuya fecha sea anterior a la fecha de
cierre del reporte. De esta manera pueden incluirse en él notas de
crédito emitidas en períodos anteriores aun cuando dicho período
haya sido reportado.
El libro de compras elige los registros a presentar de acuerdo con
tres criterios.
1. Si el rango de fechas introducido por el usuario no corresponde a
un mes calendario, sólo se incluirán los documentos con fecha de
emisión dentro de ese período, independientemente de si fiscalmente
pertenecen o no al período o períodos fiscales incluidos en ese
rango de fechas.
2. Si el rango de fechas coincide con un mes calendario, y si el
reporte correspondiente a ese mes ha sido cerrado, se selecionarán
los registros cuya "Clave de Reporte" coincida con el reporte
pedido. La "Clave de Reporte" se define en el momento en que el
reporte del período que incluye el registro es cerrado.
3. Si el rango de fechas coincide con un mes calendario, y si el
reporte correspondiente a ese mes no ha sido cerrado, se dará al
usuario la opción de "cerrar" el reporte. Si el operador confirma
que desea cerrar el reporte, se deberá introducir una clave de nivel
5 y posteriormente confirmar el cierre. En este reporte se incluirán
todos los movimientos con fecha anterior o igual al último día del
mes reportados que no hayan sido incluídos en un reporte anterior.
Al cerrar el formulario que presenta el reporte´y si se ha
solicitado el cierre del mes correspondiente, se pedirá al operador
que confirme el cierre antes de proceder al mismo. Un registro
corresponde a un período cerrado cuando el valor contenido en su
columna Reporte es igual al año del período multiplicado por cien
más el mes (p. ej. 200905 indica que el registro fue incluido en el
reporte de Mayo de 2009).
Adicionalmente, durante los meses de transición entre dos regimenes
de IVA, es posible que se registren dentro del nuevo período
operaciones correspondientes a períodos anteriores, usando tasas
diferentes a las vigentes en el período dentro del cual se
reportarána. El mecanismo vigente hasta la versión 6.4 no permitía
la existencia de más de dos tasas, y sólo las definidas como Tasa
Genral y Preferencial dentro del regimen actualmente vigente. El
nuevo reporte permite la coexistencia de tasas correspondientes a
regímenes tributarios diferentes.
- Se agregó un "modo de lectura con scanner" en el
formulario de transferencias de inventario entre almacenes. En este
modo, la introducción de un código de artículo causará que se
agregue una unidad a la cantidad de este artículo a transferir y el
cursor saltará a la siguiente línea (si era un artículo nuevo).
- Errores corregidos:
1 Las referencias al
documento de origen en los documentos fiscales asociados con notas
de crédito debían ser el número correlativo de dicha nota. Por una
confusión en los nombre de dos propiedades (TipoEntidad vs.
TipoEntidadRelacionada), se seguía usando el número del documento
que había dado origen a la nota de crédito (la factura, en caso de
un descuento, o la devolución de venta en caso de devoluciones o
anulaciones). Este error viene desde la V6.4.1 (agosto de 2008) y
fue corregido para la 6.5.1.
2 Cuando el ejercicio fiscal comenzaba en un mes
diferente de enero, los balances de movimientos mensuales que se
presentaban en la forma de interfaz de las cuentas se ubicaban de
manera incorrecta. Dicho error fue reparado.
- La actualización a la versión se realiza mediante
los scripts AccessUpgrade6.5.vbs ó SQLUpgrade6.5.vbs contenidos en
Upgrade.zip.
Abril 2009 (v6.4.88)
- Se corrigió un error en el programa de definición
de productos para la aplicación de registro de productos en barra.
- Se corrigió un error en el formulario de ajustes
por diferencia que causaba que los costos fueran "convertidos" a Bs.
viejos cuando la primera operación realizada en una sesión
administrativa era un ajuste por diferencia.
- Se optimizó el procedimiento de llenado de la
forma de presentación de reportes para reducir (hasta en un 70%) el
tiempo requerido para la carga de los reportes.
Marzo 2009 (v6.4.80)
- Se redefinieron los métodos para el calculo de
las retenciones del ISLR para hacerlos depender del valor de la
Unidad Tributaria. Hasta esta versión tomaban los parámetros como
valores absolutos en unidades monetarias.
- Se agregó el campo de clasificación a las notas
de debito bancarias. El código de clasificación "IDB" se
reserva para el Impuesto al Debito Bancario.
Febrero 2009 (v6.4.70)
- Ampliación: Se agregó un campo para la
clasificación de cheques, egresos de caja y notas de crédito a
proveedores. Esta clasificación puede usarse como filtro en los
reportes de movimientos de caja y bancos. Permiten, además, tener un
control detallado y resumido de los egresos por partida sin
necesidad de depender de la contabilidad general. Se requiere
ejecutar un script de actualizacion (4.70). Los scripts están
disponibles en el archivo Upgrade.zip
- Se agregaron filtros por descripción a los
reportes de movimientos de caja y bancos. El reporte de movimientos
de banco puede filtrarse tambien por el beneficiario (de los cheques
emitidos).
- Errores corregidos: Ninguno.
Enero 2009 (v6.4.50)
- Actualización: 6.4.57 (08-01-2009): se
redefinió el proceso de cálculo de retenciones del ISLR para
almacenar como referencia el monto total del documento pagado.
DESCRIPCION DEL PROCEDIMIENTO GENERAL
DE ACTUALIZACION
