Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Log de cambios.
En el presente log, están presentes todos los cambios realizados desde la versión 3.4.2 hasta la
3.4.6.
IMPORTANTE: En las nuevas versiones, se requiere un nuevo formato de licencia, el cual debe
solicitar al correo business@bigwise.com. De no poseer una licencia actualizada, aparecerá
continuamente un mensaje solicitando tal requerimiento al ingresar al sistema.
Para ejecutar esta nueva versión, es imprescindible ejecutar los script SQL adjuntos en el paquete
de la revisión, y posteriormente ejecutar el instalador de BUSINESS incluido en el paquete de
instalación o en su defecto, si no hay instalador, reemplazar y registrar los componentes
(Ejecutables, DLLs / OCXs, etc) manualmente.
General
Revisión general del proceso de Retenciones Masivas, para asegurar que sea compatible con
documentos tanto en moneda predeterminada como en moneda alterna, y que grabe de la misma
forma o con las mismas consideraciones que las retenciones automáticas y / o manuales. En
versiones anteriores este proceso no estaba soportado para los documentos multimoneda de
manera explícita.
BugFix. Se corrigió un escenario en el cual en un ambiente de Razon Social, que posee registrada
varias localidades (o un Central y varias tiendas), en el cual, al registrar una factura de compras de
un depósito / sucursal que no era la principal del sistema desde dicha razón social, se podían grabar
registros mixtos (unos pertenecientes a la localidad seleccionada y otros a la localidad desde donde
se está realizando el proceso). Esto daba lugar a inconsistencias en el libro de compras,
particularmente con el desglose de los impuestos.
A partir de ahora, cuando se registre una factura, en un depósito de una localidad distinta al de la
localidad donde este apuntando el sistema, todos los registros de la factura estarán asociados a la
localidad del depósito seleccionado, para asegurar la consistencia en el libro de compras en este
escenario y el resto de los procesos.
Nota: Para los escenarios de registrar facturas en las tiendas y no en un ambiente centralizado el
proceso no se ve afectado, ya que todos los registros están asociados a la misma localidad.
Se realiza ajuste en registro de factura a la hora de importar una orden de compra o recepción, de
manera que si está trabajando con la forma de Unidades y Empaques, y en dicho documento se
colocó un costo de empaque que da lugar a un costo unitario con muchos decimales, en la medida
de lo posible mantener el costo de empaque al cargar el documento, y que el mismo sea recalculado
en función del costo unitario pero tomando en cuenta la cantidad de establecidas en la regla de
negocio que especifica la cantidad máxima de decimales para los costos.
Ejemplo, si realiza una orden de compra en la cual el costo de empaque del producto es 17.49, y la
cantidad por empaque es 12, esto da lugar a un costo unitario de 1.4575. Si solicitó un empaque, y
la cantidad de decimales es 2 (ya sea especificada en la regla de negocio o que sean los decimales
de la moneda del documento), el costo unitario se redondearía a 1.46, y el costo del empaque se
recalcularía a 1.46 * 12 = 17.52 (En este escenario no se mantiene el costo de empaque especificado
originalmente, debido a que el redondeo configurado no lo permite). Pero si tiene especificada en la
regla de negocio una cantidad mayor de decimales para el costo, si podrá mantener el costo unitario
de 1.4575, para que el costo de empaque no se vea afectado y sea el mismo que se estableció en
la orden de compra (17.49).
En versiones anteriores no era posible este resultado y / o esta flexibilidad, a menos que se
modificara manualmente el costo directamente desde el grid.
Ajuste menor en ficha de regla de negocio. Al estar posicionado en una fila correspondiente a la
regla de negocio que quiera editar, ahora al pulsar Enter o espacio en la fila, lo posicionará en el
cuadro de texto para poder editar el valor de manera más rápida que teniendo que tabular o hacer
clic con el ratón.
Ajuste en pantalla de habladores. Cuando la regla de negocio que establece si se factorizan los
precios de los habladores a moneda predeterminada este desactivada, en la pantalla se mostrará el
precio del producto sin factorizar (este es el cambio en cuestión, ya que aun con la regla de negocio
desactivada se mostraba el precio factorizado en pantalla).
Este cambio no afectará a nivel de impresión de los habladores por RTF con las plantillas que ya
estén creadas o en uso (donde la regla de negocio si tiene efecto según la configuración para un
determinado conjunto de variables principales), solo afectará a nivel de pantalla.
Ajuste técnico en reporte Control de Puntos de Venta – Guía de Licores, para que no de error de
conversión de fechas y funcione independientemente de la configuración regional y el idioma del
SQL.
Ajuste de visualización en Orden de Compra cuando se carga una orden en espera en la forma de
trabajo de solo unidades, debido a que el grid no mostraba las filas del documento importado (a
pesar de que si habían sido cargadas) directamente, lo cual podía originar confusión al usuario en
este escenario. Se ajusta el comportamiento al igual que para otras formas de trabajo.
Se incluye la posibilidad de emitir reverso de retención por nota de débito a una nota de crédito en
cuentas por pagar, desde el proceso de nota de débito (anteriormente solo era posible emitir el
reverso para facturas de compra)
Adicionalmente, se mejoró el algoritmo de búsqueda de cuenta bancaria del proveedor para la opción
de pagos a proveedores.
registrada. En caso de no conseguir ningún registro se coloca el foco en el campo para que
se ingrese manualmente.
Se realizó un ajuste en el libro de compras para obtener el monto retenido en las notas de crédito.
Anteriormente solo llenaba la columna “retenido” en facturas de compra. Adicionalmente se mostrará
siempre que haya sido ingresado el campo y este correctamente enlazado el Documento Afectado
(Compra afectada por la nota de crédito).
Principalmente, ahora el sistema incluirá en este archivo las retenciones de las notas de crédito del
proveedor (Anteriormente solo se anexaban las de compras).
Adicionalmente, se realizaron unos cambios para evitar en la medida de lo posible registros en cero
(En algunos escenarios no se lograban enlazar correctamente algunas notas de débito).
Las notas de débito por reverso de retención ahora pueden estar enlazadas a notas de crédito y no
solo a compras.
Adicionalmente se realizó un ajuste según la documentación del Seniat, las notas de débito deben
reflejarse con el identificador “02”, y las notas de crédito con el identificador “03”. Anteriormente todo
lo que no fuera factura de compra se reflejaba con identificador 03. Este cambio es para asegurar la
correcta interpretación de los registros a la hora de ser subidos en el portal del Seniat.
Pero en la versión emitida por XML de dicha modalidad de reporte, se estaba tomando en cuenta
siempre el costo actual, sin tomar en cuenta esta particularidad. Se corrigió que el reporte emitido
como XML siga el mismo criterio del reporte en pantalla (el mencionado en el primer párrafo).
Se añadieron unas reglas de negocio y una funcionalidad para asegurar el cuadre de registro de
facturas de compra, en el entorno multimoneda, para el siguiente escenario:
El proveedor suministra un documento que en físico está emitido en moneda alterna, pero a su vez
refleja los totales en la moneda local del país de manera referencial, incluyendo la tasa de cambio
utilizada para el documento. En este escenario, pudiera haber ligeras variaciones en la forma en la
que calcula el sistema del proveedor y el sistema Stellar (ya sea por diferente forma de cálculo o por
variación de precisión en los decimales).
De cualquier manera, el comprador registra la factura en la moneda alterna y los montos en esa
moneda cuadran. Sin embargo, no hay manera de garantizar que el monto equivalente en la moneda
local entre ambos sistemas sea igual, por las variaciones anteriormente indicadas. Por lo tanto, se
crea una nueva funcionalidad activable por regla de negocio, que permite que a la hora de grabar
estas facturas en moneda alterna, el comprador ingrese el monto en moneda local que indica la
factura del proveedor. De esta manera, el sistema recalculará la tasa de cambio a la cual se debe
grabar la factura, para asegurar que todos los montos sean equivalentes en ambas monedas, y de
esta manera evitar diferencias en los libros de compras, retenciones, y otros procesos asociados a
la gestión de las cuentas por pagar.
COM_ValidacionTasaDocMultiMoneda
Ubicada en cuentas por pagar - registro de facturas. Si se activa, se permitirá utilizar esta
funcionalidad siempre y cuando se vaya a registrar un documento en moneda alterna. Se incluye
una regla de negocio que identifica una tolerancia máxima de diferencia entre la tasa reflejada por
el proveedor y la tasa recalculada, de manera que esta funcionalidad solo permita trabajar con
diferencias pequeñas y no vaya a ser utilizada para “forzar el cuadre” de cualquier documento.
También se puede configurar cual va a ser el campo de la factura que se va a ingresar (subtotal,
base imponible, impuesto o total) y de manera opcional un nivel de autorización para cuando se
exceda el límite de la tolerancia. Al activar esta funcionalidad, la misma aplicara tanto a registro de
facturas como a facturas o notas de crédito ingresadas desde CxP movimientos.
(Aplicable a Venezuela)
Cumpliendo con la normativa del proceso previo a la Reconversión Monetaria de expresar los precios
de bienes y servicios en Bolívar Digital, como parte del proceso de familiarización con la coexistencia
temporal de ambas monedas, a partir del 01 de septiembre, se deberán mostrar los precios en
ambas monedas (Bs. S / Bs. D) hasta que el BCV lo disponga.
Recordemos que para las versiones actuales ya existía la posibilidad de reflejar los montos en
moneda predeterminada y una moneda alterna. Ahora se podrán configurar de manera opcional
moneda alterna 2 y moneda alterna 3.
Al igual que con la moneda alterna principal, se define su código por regla de negocio:
Hbl_MonedaAlternaPrecios2=CodigoMoneda2
Hbl_MonedaAlternaPrecios3=CodigoMoneda3
Esto habilitará unos nuevos conjuntos de variables que podrá utilizar asociadas a dichas reglas de
negocio. Para mayor información consulte el listado de variables RTF contenido en este paquete de
instalación.
Aclaratoria: Usted podrá utilizar uno de estos instrumentos en conjunto con los ya existentes para
configurar su formato de habladores / etiquetas. En caso de que ya maneje la moneda alterna
principal para expresar los montos en USD, usted podrá utilizar la moneda alterna 2 para reflejar los
montos en bolívares digitales.
Tenga en cuenta que deberá crear la moneda temporal de Bs. Digitales como una moneda alterna
con tasa de 1,000,000.00, 2 decimales, para usar esta configuración en la regla de negocio. No
deberá crear ningún tipo de movimiento en el sistema con esta moneda dado que solo será usada
como referencia hasta que entre en vigencia por medio del proceso de reconversión y la misma
posteriormente será descartada (se podrá eliminar cuando ya no sea necesaria y no tenga vigencia,
siempre y cuando no le haya creado movimientos). Adicionalmente, tome en cuenta que las
instrucciones específicas para el proceso de reconversión serán suministradas en los próximos días
y esto solo representa un paso previo referente a la normativa.