CV 20190327v11 – Update 52

Print Friendly, PDF & Email

Índice de desarrollos – Update 52 / CV20190327v11

ADMINISTRACIÓN

Nuevos desarrollos
  • En «Impagados» se mejora la gestión de impagados añadiendo la posibilidad de cargar un % de incremento sobre el impagado en concepto de gastos de gestión.

Impagados

Poder añadir un porcentaje de incremento a un efecto impagado (además de correos y comisión banco)

Se mejora la gestión de “Impagados” añadiendo la posibilidad de aplicar, además del cargo extra por los gastos de gestión de impagados del banco (correos y comisión banco), un importe adicional calculado al aplicar un determinado porcentaje sobre el importe del impagado. Para ello, se han realizado varios cambios dentro de isiParts que se detallan a continuación.

“Mnto. Bancos y Cajas” (mcaj-mov)
La imagen tiene un atributo ALT vacío; su nombre de archivo es mtobanco.png

Una vez dentro de la ficha de un banco, pestaña “Notificación de impagados”, se han añadido los siguientes campos:

  • % Gastos de gestión: Porcentaje libre que la empresa decide aplicar en el impagado como incremento.
  • Importe mínimo gastos gestión: Importe mínimo de gastos de gestión a aplicar cuando el porcentaje anterior no haya alcanzado este importe. En caso de superarlo, se aplicará el importe calculado a partir del % calculado.
La imagen tiene un atributo ALT vacío; su nombre de archivo es noti-impago-gastos.png

Se ha añadido, en la ventana «Notificación de impagados» (mcajnotimp), la columna «Gastos gestión». En esta columna se mostrará el importe a incrementar sobre el impagado, bien sea el importe calculado al aplicar el % indicado en el banco (pestaña «Notificación de impagados») o el importe mínimo definido cuando el cálculo no alcance dicho valor.

La imagen tiene un atributo ALT vacío; su nombre de archivo es consulta-docs-cobro-gastos.png

Se modificará la «Consulta documentos de cobro» (cobro-con) añadiendo, en el bloque «Datos devolución», los «Gastos de gestión».

A tener en cuenta:

  • Se modifican todos los procesos de cartera (agrupación efectos, consultas, informes) para tratar el nuevo importe de cargos propios de gestión.
  • En el programa de renegociación de efectos (mcaj-regenimp), se tendrá en cuenta el nuevo importe para incluirlo en el total del nuevo efecto. Se contabilizará la diferencia entre el importe nominal antiguo y nuevo, con un asiento: 430 diferencia (DEBE) – 7XX cuenta ingresos del banco propio (HABER).
  • En el programa cobro de impagados por banco (mcaj-cobimp), desglosaremos el importe adicional calculado, permitiendo su mantenimiento, así como la cuenta contable en la que imputaremos el nuevo cargo.
  • En los programas de cobro (extracto y Norma 43) desglosaremos el importe adicional calculado permitiendo su mantenimiento, así como la cuenta contable en la que registraremos este importe.
  • Cobros por «Movimientos de Caja» (mcaj-mov) se agrupará el importe de cargo de gestión propio en la comisión de devolución.

CORRECCIONES

  • La factura del “Taller” de un cargo a cliente interno se imprime con los datos del cliente de la OR: Cuando el usuario, desde la función “Gestión Orden Reparación” (or-gest-grafic) del nuevo “Taller” de isiParts, pestaña “Facturación”, se disponía a seleccionar una línea de “Cargo” asignada a un “cliente interno” (la empresa se hace cargo sin coste para el propietario del coche); los datos de la factura emitida al pulsar “Facturar” se imprimían con los datos del cliente de la OR, en lugar de los datos del cliente interno. Solventado.
  • El “Análisis ABC por familia” tarda mucho: Cuando el usuario accedía a la función “Análisis ABC por familia” (analisis-abc-f) y se seleccionaban todos los almacenes y referencias (todas las marcas y familias), el proceso tardaba más de 15 horas. Solventado, se ha optimizado el programa para que el proceso se ejecute hasta 6 veces más rápido.
  • Se tiene en cuenta el “lote de compra” al registrar el movimiento en el histórico de una referencia cuando se solicita el abono por motivos de diferencias de entrada de material: Cuando el usuario accedía a la función “Diferencias entrada de material” (difEntAlm) par solicitar un abono al proveedor por la cantidad que no había recibido (por ej. se piden 2.000 y llegan 1.000 unidades); al pulsar “Generar abono” y seguidamente ir a la “Consulta de Histórico de Movimientos” (hist-alm-con) de la referencia, la cantidad registrada no era correcta. El problema residía en aquellas referencias que en su ficha tienen un “Lote de compra” (pestaña «Proveedores») ya que, al solicitar el abono y restar la cantidad en el histórico, la cantidad se calculaba en base al “Lote de compra”. Por ejemplo, si se solicitaba el abono de 1000 unidades y la referencia tenía un “Lote de compra” de 800, isiParts realizaba el siguiente cálculo 1000/800=1,25 y grababa -1,25. Solventado, al solicitar un abono por diferencia de entrada de material, la cantidad a registrar NO tendrá en cuenta el “Lote de compra”.