CV 20161015v11 – Update 35

Print Friendly, PDF & Email

Índice de desarrollos – Update 35 /  CV20161015v11

ADMINISTRACIÓN

Nuevos desarrollos

Bancos y Cajas

Se incrementa a 9 el número de “Dígitos subcuenta” de la “cuenta de talones pendientes de pago”

Se mejora la función “Mnto. Bancos y Cajas” (mtobanco), concretamente la pestaña “Datos contables” disponible cuando entras y seleccionas un banco en la ventana inicial. Dentro de la pestaña “Datos contables”, y junto al campo “Cuenta de talones pendientes de pago”, se encuentra el desplegable “Dígitos subcuenta” donde se han modificado las opciones para que se pueda definir un valor de hasta 9 dígitos, en lugar de 6 como hasta ahora.

  • Cuenta talones pendientes de pago: En esta cuenta se contabiliza la emisión de un talón que cancela una factura de proveedor, generando el siguiente asiento, 400 a Cta.
  • Dígitos subcuenta: Cabe la posibilidad de definir la cuenta de talones pendientes de pago a nivel de mayor y poder generar tantas subcuentas como a proveedores diferentes hayamos entregado talones o pagarés; es decir, que los movimientos del pago se contabilicen contra cuentas de terceros.


LOGÍSTICA / ALMACÉN

Nuevos desarrollos

Gestor de expediciones

Optimización de la velocidad de entrada al «Gestor de expediciones»

Se revisa internamente el “Gestor de expediciones” (gestorexp) para optimizar el rendimiento y la velocidad de entrada y carga de datos de la función. El “Gestor de expediciones” (Gestión Almacén, Menú Pedidos/Albaranes de Clientes, Menú Pedidos Pendientes de Servir) está directamente relacionado con el proceso de gestión de ventas a través del proceso de logística (PDA), en este proceso se van depositando aquellos albaranes o facturas de contado “no urgentes” que están asociados a una ruta (ruta-mant) o agencia de transporte (transport-mant). Desde esta pantalla el usuario y almacén autorizado podrá gestionar las expediciones pendientes.

PDA

Mejoras en el rendimiento de la reubicación de referencias desde la PDA

Se ha revisado y optimizado el proceso de reubicación de referencias desde la PDA, (menú principal, opción “Gestión de ubicaciones”) para mejorar el rendimiento y la velocidad del proceso.

Cambio en el foco de las ventanas emergentes informativas (verde) de la PDA

Se ha modificado internamente el comportamiento del foco (acción a tomar al pulsar INTRO) en las ventanas informativas de la PDA. Es decir, en aquellas ventanas con mensajes informativos de color verde (ver “Notificaciones de la PDA” en «Omisiones de gestión logística PDA«), al pulsar ENTER, el foco se del cursor estará ubicado en la “X”, de modo que al pulsar ENTER se cerrará la ventana tomando la acción como si se hubiera pulsado el botón “Aceptar”.

CORRECCIONES

  • No se imprime la descripción (modificada) del artículo: Cuando desde la función “Entrada Pedidos de Cliente” (mtopedidoscli) el usuario modificaba la descripción de la referencia y, tras realizar la extracción, validación y expedición de la mercancía desde la PDA se generaba el documento; la descripción que aparecía impresa en el documento/albarán NO era la modificada por el usuario. Se solventa.
  • Error en la detección de períodos liquidados al ejecutar el proceso de “Facturación”: Cuando existían dos empresas y una de ellas liquidaba el IVA (liq-iva) mensualmente (01) mientras que la otra (02) lo hacía trimestralmente y el usuario se disponía a ejecutar la “Facturación” (factu-alm-cre), se mostraba erróneamente el mensaje “la liquidación ya está realizada”. Esto ocurría cuando la empresa que liquidaba mensualmente (01) seleccionaba una serie de facturación que contabilizaba en la empresa 02; detectando como cerrado el período para la 01 cuando debería verificar los períodos de la 02. Solventado.
  • Error al notificar un impagado re-asignando la “forma de pago”: Cuando se notificaba un impagado desde la pestaña “Notificación impagados” de la función “Movimientos y extractos de bancos” (movExtBanco) y, en la ventana emergente que aparece al pulsar el botón “Notificar”, se reasignaba una forma de pago; ésta no se creaba correctamente en la cartera de cobros. Del mismo modo, en la generación del impago al banco, se generaba la línea con importe 0. Solventado.
  • No se genera el documento de pago en la “Notificación de impagados”: Cuando se notificaba un impagado y el modo de pago era “Crédito”, la factura de proveedor de gastos no generaba el documento de pago. Solventado.
  • No se actualiza el número del albarán de compra en el detalle del “Histórico del movimiento de la referencia”: Cuando el usuario accedía a la función “Modificar albarán de compra” (modalbcompra) y pulsaba el botón “Modificar cabecera” para cambiar el “Número albarán” (previamente introducido); no se actualizaba el “Detalle” (doble click) del movimiento de las referencias incluidas en el albarán de compra. Es decir, el usuario accedía a la “Consulta Histórico de Movimientos” (hist-alm-con) de las referencias del albarán y, al abrir el detalle del movimiento, el número del albarán que se mostraba era el de origen. Solventado, con la modificación se actualizará el número del albarán.
  • No se genera la garantía desde el almacén que la está generando, sino desde el almacén que realizó la venta: Cuando desde la función “Entrada Múltiple de garantías” (ent-gar-mul) se daba de alta una garantía desde un almacén diferente al que realizó la venta/cargo, la garantía se creaba en el almacén que realizó la venta/cargo en lugar del almacén que la generaba. Solventado, el almacén que da de alta la garantía será el que la genere, independientemente del almacén que realizó la venta.
  • No se borra la línea del banco al eliminar asientos contabilizados desde “Movimientos y extracto de banco”: Al anular un asiento desde la función “Movimientos y extracto de banco” (movextbanco) (botón derecho del ratón “Borrar asiento contable”), habiendo contabilizado previamente con la opción “Agrupar líneas de banco al contabilizar” (menú superior “Opciones”) marcada; la línea del banco quedaba pendiente de ser anulada en la consulta del “Extracto contable” (cuenta-con) del banco. Es decir, aunque en la cuenta del cliente se quedara la deuda correcta, en el banco quedaba la línea pendiente de anulación. Solventado, con la modificación se borrará la línea del banco junto con la eliminación del asiento.
  • Se duplica la campaña al importar un presupuesto desde “Entrada Pedidos de cliente” o “Mostrador”: Cuando un usuario guardaba un “presupuesto” de un cliente sujeto a una “Campaña” (campañas) y posteriormente lo recuperaba para finalizar la venta; la condición de la “campaña” se aplicaba dos veces puesto que en la creación del presupuesto ya había sido aplicada y, al importarlo, se volvía a calcular. Por ejemplo, si la campaña para el “viaje” consistía en reducir el descuento habitual del cliente (40%) en un 5%, dejando un 35% de descuento final; al importarlo se volvía a aplicar otro 5% dejando como descuento final un 30%. Solventado, con la importación de un presupuesto se validará la “campaña” para que sólo se aplique una vez.
  • Se permite “regularizar stock” desde la “ruptura de stock” a un usuario sin permiso: Cuando un usuario NO tenía permiso para “Regularizar stock” (definido en el “Mnto. Usuarios y Seguridad” (gseguridad), pestaña “Almacén”, en “Autorización por almacén”) y se producía una “Ruptura de stock” desde el nuevo “Mostrador” (mtoalbventa) no se validaba el permiso, permitiendo con ello realizar siempre una regularización de stock. Solventado.
  • No se asigna el “Tipo de cliente” en las “Ordenes de Trabajo” del “Mostrador”: Cuando se creaba un albarán de “Orden de Trabajo” (parte de reparación) desde el nuevo “Mostrador” (mtoalbventa); en la cabecera del documento no se asignaba el “Tipo de cliente” (tipo-cli-mant) indicado en la ficha del “Cliente” (cliente-mant), dentro del «Mantenimiento de datos por serie de facturación» (pestaña «Datos facturación», pulsando una serie de facturación). Solventado.