CV 20190327v11 – Update 22

Print Friendly, PDF & Email

Índice de desarrollos – Update 22 / CV20190327v11

COMPRAS

Nuevos desarrollos
  • En «Reaprovisionamiento entre almacenes» se añaden nuevos campos a grabar en el fichero albaran-datos cuando se traspasen kits.

Reaprovisionamiento entre almacenes

Nuevos campos a grabar en albaran-datos con los traspasos entre almacenes

Se mejoran internamente los traspasos entre almacenes de modo que, cuando la mercancía traspasada sea un “Kit” (artic-kit), en el fichero albaran-datos se guarden los siguientes datos/campos:

  • albaran-datos.referkit
  • albaran-datos.cankit
  • albaran-datos.carcasa
  • albaran-datos.impuesto

CORRECCIONES

  • Error en el reparto de cantidad sobrante entre almacenes teniendo en cuenta mínimos y equivalentes: Cuando el usuario, al ejecutar el “Cálculo de la propuesta” de “Reaprovisionamiento entre almacenes” (reapro-alm), tenía en cuenta las referencias equivalentes, ocurría un error en el “Reparto”. Concretamente, cuando la referencia original y equivalente del almacén que cede tenían mínimos distintos, y el resultado del cálculo conjunto obtenía un exceso de unidades que el almacén podía repartir; si el almacén que cedía y que recibía era el mismo, el almacén no repartía cuando sí podía hacerlo ya que tenía X unidades de stock sobrante. Solventado, cuando el almacén que cede y el de destino son el mismo, no se tendrá en cuenta para el reparto.
  • No se guardan los valores modificados en el “Reparto” de un “Reaprovisionamiento entre almacenes”: Cuando el usuario, al ejecutar el “Cálculo de la propuesta” de “Reaprovisionamiento entre almacenes” (reapro-alm) y, en ventana del “Reparto”, modificaba los valores; éstos no se cambiaban ya que se recuperaba la cantidad guardada. Solventado, sólo se guardarán las cantidades cuando el usuario las haya modificado definitivamente.
  • No se aplican los precios netos al importar pedidos web (i2i) a isiParts: Cuando mediante “Tarea programada” (tareas-mant) se importaban a isiParts los pedidos realizados en i2i y, para el cliente del pedido existían “precios netos” (pvp-cli-ref) y “Ofertas” (ofertas-man), se aplicaba la “Oferta” de forma prioritaria. Esto ocurría debido a que el criterio de aplicación de las condiciones comerciales aplicaba la “Oferta” antes que los “Precios netos”. Solventado, en primer lugar siempre prevalecerá el “Precio neto”.
  • No se muestra si la remesa de un banco con N43 ha sido contabilizada: Cuando el usuario accedía a la función “Movimientos y extractos de banco” (movextbanco) y, teniendo seleccionado un banco con “Norma 43” activada, accedía al menú superior “Remesas” y pulsaba “Cancelación riesgos al descuento”; en la ventana «Cobro de efectos remesados» que se abría no se indicaba “Sí” o “No” en la columna “Contabilizado en remesa”. Solventado.
    Ver ejemplo


  • No se puede modificar un efecto de un cliente con “Riesgos”: Cuando el usuario, desde la función “Mnto. documentos de cobro” (cobro-mant) accedía a la “Cartera de cobros” de un “Cliente” (cliente-mant) con gestión de “Riesgos” (riesgos) activada y, mediante el botón derecho del ratón (o haciendo doble click) seleccionaba la opción “Mnto. documento de cobro” para modificar el efecto; aparecía un mensaje avisando que “el efecto no existe”. Además, el acceso a dicha ventana mediante el doble click del ratón no funcionaba. Solventado.
  • Lentitud en el proceso “Actualizar stock ideal”: A raíz del “Update 58”, cuando el usuario ejecutaba la función “Actualizar stock ideal” (actureapr), el cálculo tardaba mucho en realizarse y dejaba bloqueada la función. En algunos casos, plantillas que tardaban 30 segundos en cargarse pasaron a tardar horas. Solventado.
  • El “Mostrador” no coge la serie de facturación por defecto del usuario (gseguridad) cuando no se indica el código de cliente: Cuando el usuario Isi (gseguridad) accedía al “Mostrador” y no introducía el código del cliente (cliente-mant); la serie de facturación que se detectaba no era la que debería ser (almacén asignado al usuario). Solventado.
  • El pedido urgente de compra a proveedor (ligado a un pedido de cliente) se vincula con el almacén por omisión del usuario vendedor: Cuando el usuario, desde el “Mostrador” (mtoalbventa) o la “Entrada Pedidos de Cliente” (mtopedidoscli) no disponía de la mercancía solicitada y en la “Ruptura de stock” de esa línea realizaba un “Pedido urgente de compra a proveedor”; si el almacén por omisión del usuario/vendedor (gseguridad) era diferente al almacén de la línea, el pedido a proveedor quedaba vinculado al almacén del usuario, en lugar del almacén de la línea. Solventado en “Pedido de proveedor” y en la “Propuesta de pedido”.
    Ver vídeo
  • Existen líneas en el “Histórico de movimientos” con el mismo documento y diferentes clientes y horas: Cuando el usuario accedía a la función “Consulta Histórico de movimientos” (hist-alm-con) se visualizaban movimientos vinculados a un mismo número de documento pero a diferente cliente y en diferentes horas.  Al comprobar desde el “Editor de datos” se visualizaba la misma información errónea. Solventado.