lunes, 14 de diciembre de 2015

Mejoras en albaranes, pedidos y presupuestos.

Open-ERP SOCGER

Al crear un nuevo presupuesto, si le dábamos nada más entrar al cliente para ponerlo, nos daba un error. Esto ocurría porque la función que nos traía las líneas que todavía no pertenecían a ningún pedido, intentaba hacerlo cuando todavía no estaba abierta la tabla de líneas de detalles del presupuesto.

Al crear un nuevo pedido, si le dábamos nada más entrar al cliente para ponerlo, nos daba un error. Esto ocurría porque la función que nos traía las líneas que todavía no pertenecían a ningún albarán, intentaba hacerlo cuando todavía no estaba abierta la tabla de líneas de detalle del pedido.

Solucionado el problema al elegir un cliente en albaranes, presupuestos o pedidos que no tenía puesto su representante. Habían campos del representante que en la cabecera del albarán, pedido o presupuesto era obligatorio ser rellenados. Ahora no lo son, pues pueden haber clientes que no estén asignados a un representante.

Cuando en pedidos intentamos pasarlo por completo a albarán, comprobamos primero si está dado de baja el pedido. Porque si lo está no debe de crear el albarán.

Cuando en presupuestos intentamos pasarlo por completo a pedidos, comprobamos primero si está dado de baja el presupuesto. Porque si lo está no debe de crear el pedido.

Ahora si se borra un albarán entero se ha conseguido que aumente las líneas del stock de los artículos a los que se les tenga que controlar su stock. Por supuesto también lo hace cuando se borran líneas de detalle una a una.

Cuando traspasabamos entero un pedido a albaranes no comprobaba anteriormente si había stock de todos sus artículos. Ahora ya está corregido, además se ha corregido el problema de que si el pedido tenía varias líneas del mismo artículo, debe de hacer la comprobación sobre el total del mismo artículo a traspasar. no sobre cada una de las líneas. Porque si la línea primera de detalle del pedido tiene 2 unidades del artículo "artículo primero" y hay stock para descontar, y además puede que la línea 3 tenga una unidad del artículo mencionado ... pues si se hacía por separado el toal de stock a comprobar de cada línea nos diría que si para la primera línea, pero que no para la tercera línea de detalle a traspasar.

Si se vuelve a dar de alta un albarán que fue borrado por completo, primero comprueba si hay stock, pero lo hace por su conjunto de artículos. Pues un albarán puede tener varias líneas de un mismo artículo, así que debe de hacer la comprobación de su stock por el total de cantidades por artículo del albarán.

Por supuesto si una línea de detalle de un albarán se diera de alta también disminuye el stock del artículo.

Se corrige el mensaje de que no hay stock suficiente cuando intentamos convertir una línea de detalle de un pedido a albarán. El mensaje no era lo suficientemente claro.

Se corrige el mensaje de que no hay stock suficiente cuando creamos/modificamos una línea de detalle de un albarán. El mensaje no era lo suficientemente claro.

Mejoras en módulo de artículos.

Open-ERP SOCGER


   En artículos en el mantenimiento de su ficha, se obliga ahora a introducir la descripción para la terminal o punto de venta (TPV). El motivo es porque es una descripción más corta que la descripción general del artículo y ciertas terminales de venta no permiten esta descripción tan larga, ni tampoco las impresoras de tickets enlazadas a este tipo de terminal.

Mejoras generales.

Open-ERP SOCGER

   Antiguamente cuando un registro era borrado y luego vuelto a dar de alta, preguntaba por si estábamos seguros de darlo de alta. Pues ahora no, directamente se da de alta, tal y como lo hacemos en dar de baja. Es el usuario el que los diferencia por los diferentes colores del registro según su estado (borrado o no borrado).

   Desde el principio optemos por cada vez que abríamos una tabla para un grid, traer sólo una cantidad específica de registros y sólo traeríamos el resto de registros por necesidad, por ejemplo cuando nos desplazáramos por los registros del grid hacia abajo o hacia arriba. Bueno pues esto nos generaba un error a la hora de saber la cantidad de registros devueltos en un filtro, porque sólo nos decía los que había traído en ese momento y no el total. Esto se ha solucionado volviendo a traer todos los registros desde el principio y no parte de ellos.

   Se ha corregido un fallo común en todos los mantenimientos que tenían tablas ligadas a la tabla de cabecera. Este error sólo se producía mientras teníamos en el módulo principal pulsado VER BAJAS = SI y por ejemplo pulsábamos para crear un nuevo registro.