Artículos vendidos más baratos

Tengo una base de datos con el formato siguiente:
La primera es la tabla de las líneas de factura de proveedores, con este nombre FACFA2PR
Y tiene los siguientes campos:
SERIE, FACTURA(NUMERO), ALBARAN, CUENTA, GRUPO, ARTICULO FECHA_FA, FECHA_AL, NUM_LIN, ....
Y por otro lado la tabla de las lineas de factura de clientes, con este nombre, FACAL2CL
Y tiene los siguientes campos:
SERIE, FACTURA(NUMERO), ALBARAN, CUENTA, GRUPO, ARTICULO FECHA_FA, FECHA_AL, NUM_LIN, ....
Yo quiero saber que articulo he vendido más barato que lo he comprado, si hay alguno.
Como puedo hacer una consulta que me relacione los artículos, teniendo en cuenta la fecha de compra i la de venta, ya que cada año varían los precios de venta.
La consulta resultante me debería mostrar los siguientes campos:
Articulo, fecha_fa(facal2cl), precio(facal2cl), fecha_fa(facfa2pr), precio(facfa2pr)

1 respuesta

Respuesta
1
Tu pregunta es muy elocuente y a la vez de difícil resolución.
Ten en cuenta que las compras se realizan en unas fechas concretas, que normalmente difieren de las fechas de venta.
La única relación posible, es la que se puede formar mediante el articulo, siempre que el articulo que se compra sea igual al articulo que se vende.
Si realmente, no cambian los precios de compra, ni de venta, nada más que una vez al año, entonces puedes hacer una consulta para mostrar una especie de extracto ordenado por fechas, en el que después puedes analizar de que forma han ido entrando y saliendo artículos, y a que precio de compra, y de venta.
Otra solución es montar una consulta de selección, para un año dado, y que se muestren las lineas de venta donde el precio de venta sea menor que el de compra, similar a la que te indico a continuación:
"SELECT FACFA2CL.ARTICULO, FACFA2CL.FECHA_FA, FACFA2CL.PRECIO FROM FACFA2CL INNER JOIN FACFA2PR ON FACFA2PR.ARTICULO=FACFA2PL.PRECIO WHERE FACFA2CL.PRECIO<FACFA2PR.PRECIO AND YEAR(FACFA2CL.FECHA_FAC)=2001
En cualquier caso lo tienes difícil ya que no existe una relación entre los movimientos de entrada y los movimientos de salida.
Controlar estadisticamente los consumos de los artículos y su rentabilidad sobre precios, hace que los desarrolladores tengan que controlar en tablas independientes los movimientos relacionados, y para ello hace falta un campo en común, que permita identificar las entradas con las salidas.
Hola
He hecho la consulta que me dijiste, pero surge un problema a causa del problema en la relación " creo ".
Durante el 2001 un articulo lo he comprado 4 veces i lo he vendido 3 i la consulta me devuelve 16 registros en los que el pvp es < que el precio de compra.
Saludos
PayoRanger
El origen del problema puede ser de índoles diferentes, puede que tengas registros sin controlar en las tablas, puede que haya que afinar un poco más la consulta, en cualquier caso, eres tu el que debes analizar los resultados, comprobando que información solicitas en la consulta, campo a campo, y cual es la información que te ofrece, y si realmente esos registros que devuelve la consulta tienen relación con los que realmente deberían existir.
Para poder matizar más en el asunto, debería tener en mi poder los datos, y creo que eso no es viable, a no ser que exportes las tablas a una base de datos nueva y me los hagas llegar, junto con un pequeño detalle de como están compuestas las tablas, y que información contienen a [email protected].
Hola sofocles
Como me dijiste te mando una parte del programa por mail
Cuando sepas algo, lo hayas solucionado o no dime algo.
Un saludo
payoranger
[email protected]
A continuación te muestro la consulta que he confeccionado, en la que puedes ver el beneficio por articulo (yo he seleccionado beneficio negativo para ver operaciones cumplen el criterio de ser menor el precio de venta que el precio de compra, pero puedes quitar el criterio <0 de esa columna, y verás el beneficio positivo o negativo).
SELECT FACAL2CL.ARTICULO, FACFA2PR.FECHA_FA AS FechaCompra, FACAL2CL.FECHA_FA AS [Fecha Venta], FACFA2PR.PRECIO AS [Precio Compra], FACAL2CL.PRECIO AS [Precio Venta], [FACAL2CL].[PRECIO]-[FACFA2PR].[PRECIO] AS BENEFICIO
FROM FACAL2CL INNER JOIN FACFA2PR ON FACAL2CL.ARTICULO = FACFA2PR.ARTICULO
WHERE (((FACAL2CL.ARTICULO) Is Not Null) AND ((FACAL2CL.PRECIO)<>0) AND (([FACAL2CL].[PRECIO]-[FACFA2PR].[PRECIO])<0) AND ((Year([FACAL2CL].[FECHA_FA]))=2001))
ORDER BY FACAL2CL.ARTICULO, FACFA2PR.FECHA_FA;
Copia directamente el texto de la select y pégalo en la consulta, editando en formato sql.
Espero haberte ayudado. Si tienes más consultas que hacer o continuar con esta, no dudes en efectuar nuevas consultas.
Hola Sofocles.
He probado esta consulta que me mandaste, pero sigue sin funcionar correctamente.
Veras, con el programa que te mande comprueba lo siguiente:
Ves a la tabla FACAL2CL ( la de ventas ) i veras que del articulo "W0892332840" hay 892 registros,
luego ves a la de compras (FACFA2PR) i con el mismo articulo veras que te salen 20 registros.
Ahora para finalizar ejecuta tu consulta i del mismo articulo veras que salen 6750 registros. Por lo tanto esto quiere decir que la consulta duplica información i por lo tanto los resultados no son los que yo quiero.
Un saludo,
Payoranger.
He analizado el resultado de la consulta y efectivamente los registros relacionados se multiplican para cada compra aparecen todos los de venta. Yo lo probé con un articulo con menos registros, y coincidió bien.
Ahora vamos a plantearlo de otra forma. Así que teniendo en cuenta, que los precios no varían en todo el año, se me ha ocurrido utilizar la tabla de artículos FACARTIC, ya que esta tabla, supongo que es el origen del precio de venta. He cogido la tarifa 1 y la he relacionado con las compras, así se puede observar la diferencia en precios. Se puede hacer lo mismo con las ventas, por si el precio aplicado en la factura no coincide con el de origen, es decir el del articulo.
SELECT FACARTIC.codigo, FACFA2PR.FECHA_FA, FACFA2PR.PRECIO AS [Precio Compra], FACARTIC.tarifa_1, FACARTIC.tarifa_2, FACARTIC.tarifa_3
FROM FACFA2PR INNER JOIN FACARTIC ON FACFA2PR.ARTICULO = FACARTIC.codigo
WHERE (((FACARTIC.codigo)="W0892332840") AND ((FACFA2PR.PRECIO)<>0) AND ((Year([FECHA_FA]))=2001))
ORDER BY FACARTIC.codigo, FACFA2PR.FECHA_FA;
En cualquier caso, el análisis es complicado por lo que ya te comenté, si no se guarda un identificador de la compra en la tabla de ventas, luego no hay forma humana de relacionarlo, a no ser que utilices funciones, pero la lógica de la aplicación se va al carajo.
Hola Safocles.
La consulta que me has mandado ya la había hecho yo algo parecida, pero esto no es lo que yo estoy buscando.
En la consulta que tu me mandas solo puedo analizar el ultimo año, pero por ejemplo si ahora a mi me actualizan los precios el 01.09.01, a partir de ahora el resultado de la consulta no me sirve, no es bueno.
Yo quiero saber cuantas veces he vendido los artículos más baratos o a precio de coste, en su momento, para llegar a saber el dinero que yo he perdido.
Como dices creo que es muy difícil, porque no se sabe que compra pertenece a cada venta, pero se me ha ocurrido una cosa:
A lo mejor si cogemos i "ordenamos" los registros por fechas i utilizamos las cantidades podemos hacer algo. Me explico, si yo compro a la vez(en un registro) 2 artículos, luego que sume las ventas hasta que le salgan 2 artículos.
Puede que lo que digo son fantasías, pero a lo mejor encuentras la manera de solucionar-lo con esta pequeña aportación.
Un saludo
Payoranger.
Prueba a juntar las tablas en una nueva tabla de movimientos, mediante consultas de datos añadidos.
Ten en cuenta que cuando vayas a añadir los datos debes configurar un campo para identificar cada tipo de movimiento (Compras y/o Ventas).
Una vez que tengas la consulta nueva con los datos de las dos tablas, solamente te queda ordenarla por articulo, Fecha, Tipo de Movimiento.
Y de Esta forma al menos tendrás la secuencia de entradas y salidas por articulo.
Lo que tu propones es muy complicado, porque en un ejercicio partes normalmente con existencias del anterior, y entonces ya no puedes cerrar el criterio de fechas por el año, sino que es un planteamiento continuo, similar al de un almacen, como ya te he comentado en otros mensajes.

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas