Control de salidas por consignacion

[lucius]

Cual es el proceso de salida cuando se trabaja con una guia a consignacion, a simple vista representaria una salida de almacen por lo cual tendria que registrarlo en mi tabla es ENTRADA-SALIDAS, pero si luego creo una factura a partir de dicha guia u por otros motivo que se les ocurra tendria que volver a registrar una salida en mi tabla? en este punto no lo tengo claro, espero me aclaran un poco el panorama, espero se entienda la idea general de esta duda que tengo.

[ssccaann43]

Estimado en ese caso puedes crear un modulo para registrar las guias a consignacion, pero "COMPROMETIENDO MERCANCIA", es decir, la mantienes en un status cualquiera, hasta que la factures que posteriormente se rebaja de inventario.

Saludos

[lucius]

Tengo mi tabla MOVIMIENTOS que se rellenan cuando compro/vendo. Por modulo te refieres a crear otra tabla con su respectivo form y ahi almacenar mi SALIDA por consignacion? No entendi del todo lo de COMPROMETIENDO MERCANCIA, me podrias detallar mas y si puedes darme un caso mas general porque nunca he tratado esto sobre consignacion y no tengo idea que casos se puedan presentar. Saludos

[ssccaann43]

Ok, te lo expongo así...!

Debes tener una tabla que se llame MercanciaComprometida, la cual llenaras cuando registres las guias a consignacion. Para efectos de Inventario Fisico, es decir lo que ves fisicamente que tienes en existencia, el inventario debería rebajarse, ya que le entregas la mercancia al cliente, pero para Efectos del Sistema, la Existencia se mantiene en Otro Lugar que en este caso es la tabla de MercanciaComprometida, la cual podras consultar y saber que cliente la tiene, por tal motivo, si la sacas de allí es por dos razones: 1. Facturarla y descargar la mercancia de inventario, es decir del sistema. 2. Anular la guia de consignación y retornarla a la existencia normal, tal y como estaba.

Espero me entiendas...

[zxs23]

Hola ssccaann ya entendi lo que dices, crees que crear una tabla EXISTENCIAS y relacionarla de 1 a 1 con la tabla PRODUCTOS este correcto o es mucho asunto y me traeria algun tipo de problema, como lo vez? es mas o menos a lo que te referias.

En el grafico que muestro por ejemplo puede haber un producto con Existencias=100 que representa al stock y CONSIGNACION=20 que representaria la "mercaderia comprometida" y para obtener EL STOCK REAL seria con un campo calculado: existencia_real=existencias-CONSIGNACION

Le ven algun inconveniente a este planteamiento...


campo Mov de la tabla MOVIMIENTOS representa E:Entrada; S:Salida
campo costo de la tabla EXISTENCIAS representa al COSTO PROMEDIO

[lucius]

Pero necesariamente tendria que tener un campo calculado, no seria mejor crear un campo que guarde dicho valor y ya. Segun lo que dices al crear un nuevo producto tendria que crearse un registro para la tabla de existencias por la relacion de 1 a1 es usual utilizar relaciones de este tipo, voy a probarlo

[lucius]

Ya lo probe y la relacion de 1,1 estaba bien, saludos

[ssccaann43]

Buenas tardes,

Que bueno que me hayas entendido.. Tengo ciertas observaciones...!

1. Si el cliente maneja diversos tipos de precios, esa tabla de Productos debes cambiarla, por ejemplo el producto deberia tener al menos una lista de precios, PRECIO DISTRIBUIDOR, PRECIO MAYOR, PRECIO PVP. Esto con la finalidad que cuando se vaya a realizar una venta, se pueda escoger con cual lista de precios trabajar.

2. (campo costo de la tabla EXISTENCIAS representa al COSTO PROMEDIO) MALO...! Todo lo referente al PRODUCTO, llamese precios, costos, costos promedios, etc, van en la tabla Producto, no en existencia.

3. Si deseas manejar el tema de Consignación por la tabla de existencia, me parece genial... Pero debes mantener un Maestro o un Historico, para controlar que tienes en Consignación y a quien se lo diste...

4. Exito...!

Saludos

[YAcosta]

Tengo tambien una observacion a mi amigo Miguel:

1. Si el cliente maneja diversos tipos de precios, esa tabla de Productos debes cambiarla, por ejemplo el producto deberia tener al menos una lista de precios, PRECIO DISTRIBUIDOR, PRECIO MAYOR, PRECIO PVP. Esto con la finalidad que cuando se vaya a realizar una venta, se pueda escoger con cual lista de precios trabajar.

Es correcta y aconsejable esta recomendacion. No hay nada que decir.

2. (campo costo de la tabla EXISTENCIAS representa al COSTO PROMEDIO) MALO...! Todo lo referente al PRODUCTO, llamese precios, costos, costos promedios, etc, van en la tabla Producto, no en existencia.

Perfecta aclaracion, esos datos pertencen al maestro. La tabla de existencias es una tabla transaccional.

3. Si deseas manejar el tema de Consignación por la tabla de existencia, me parece genial... Pero debes mantener un Maestro o un Historico, para controlar que tienes en Consignación y a quien se lo diste...

Efectivamente.
----
Mi observacion es que aun no me dices para cuando mas o menos vendras a Peru a tomarnos unas chelas.  :-)

[zxs23]

Buenas tardes,

2. (campo costo de la tabla EXISTENCIAS representa al COSTO PROMEDIO) MALO...! Todo lo referente al PRODUCTO, llamese precios, costos, costos promedios, etc, van en la tabla Producto, no en existencia.

Hola sccaann/yacosta nen cuanto al punto2 de tu comentario, segun mi logica y nose si estaba haciendo bien y acudo a su experiencia, si coloco mi CAMPO COSTO PROMEDIO(el valor sale del calculo de entradas/salidas) en la misma TABLA PRODUCTO tendria que aplicar 3 sentencias sql por ejemplo actualmente y segun mi grafico lo estaba haciendo asi cada vez que realizo una ENTRADA/SALIDA

Código: (SQL) [Seleccionar]

INSERT INTO MOVIMIENTOS VALUES(var_idmov,var_numdoc,var_tipodoc,var_idprod,var_fechamov,var_mov,var_cantidad,var_costounidad)
UPDATE EXISTENCIAS SET costo=var_costo, existencias=var_cant WHERE idprod='P998'

Pero si coloco el campo costo(COSTO PROMEDIO) en la tabla PRODUCTO tendria que hacerlo asi en cada movimiento

Código: (SQL) [Seleccionar]

INSERT INTO MOVIMIENTOS VALUES(var_idmov,var_numdoc,var_tipodoc,var_idprod,var_fechamov,var_mov,var_cantidad,var_costounidad)
UPDATE EXISTENCIAS SET existencias=var_cant WHERE idprod='P998'
UPDATE PRODUCTO SET costo=var_costo WHERE idprod='P998'


Osea aplicaria 3 sentencias, aunque ya han dado su parecer que opinan de esta situacion? la idea que tenia era hacer todo en una sola tabla incluso recomende meterle el campo CONSIGNACION en lugar de crear otra tabla, nose si al final sea tan practico como me parecia en un inicio!!

[YAcosta]

Te estoy leyendo al vuelo y me llamo la atencion este comentario:

... la idea que tenia era hacer todo en una sola tabla incluso recomende meterle el campo CONSIGNACION en lugar de crear otra tabla...

Si partimos de esa premisa terminaríamos diseñado algo que no se basa en el requerimiento. No debes partir deseando querer hacer todo en una sola tabla, lo mismo no debes partir deseando querer a ser todo en 10 o 100 tablas. Tienes que crear las tablas que sean necesarias, si el diseño te arroja crear 3 tablas HAZLO, si te arroja hacerlo en uno o cien pues esas seran.

Ahora, yendo al punto especifico, el costo como bien dijo Miguel va en la tabla de maestro de producto. Otra cosa es que conserve la "evolucion" de ese costo para poder hacer reversiones en otra tabla, pero el costo en si va en un campo de la tabla maestro de productos, al menos es lo que yo también opino.

Igual cuando calculo el costo leo el stock actual, leo el costo actual, leo lo que se esta ingresando y leo su valor de ingreso (o precio de compra, la venta no altera el costo), inserto y actualizo en una tabla de histórico de costo y el valor obtenido lo meto en el maestro.
Si quiero sustentar dicho costo acudo a la tabla de histórico, lo armo, lo presento en un grid y hasta lo gráfico.


El tema de consignación no manejo, pero si lo hiciera no crearía un campo en el maestro, a ojo de buen cubero considero que ese tipo de transacción la trataría de forma "similar" a una venta, similar pero no igual, o sea, crearia un par de tabla (cabecera y detalle) o usaría la tabla de ventas pero aumentaría un campo mas para indicar al sistema que esa es una consignación y no una venta y darle una evaluación particular. Es lo que creo haría con cargo a rectificar algo porque últimamente estoy en otros horizontes alejados de la programación en general.

igual en lo que pueda ayudarte. Saludos

[zxs23]

Igual cuando calculo el costo...

Tu historico de costos lo manejas solo con fecha o con fecha y hora porque el valorizado del maestro segun tu grafico podria tener 2 o mas valores en un mismo dia supongo que muestras pocos registros para darme cuenta.
En tu pantallazo solo se ve el resultado pero realmente tienes una tabla fisica de historico de costos porque me parece en mi caso que esta se podria armar con datos de la tabla MOVIMIENTOS o hay algo que estoy obviando? no muestras el detalle puedes colocar el detalle en una imagen.

Otra gran duda que me ha surgido es que pasa cuando se modifica/elimina un movimiento(creo que aqui entraria en accion la tabla historico que mencionas?), lo que pasa es que tengo una plantilla de kardex en excel y al presionar un boton me genera todo el kardex, osea si modifico algo manualmente no hay problema puesto que generare todo el kardex desde cero(obtengo el costopromedio y demas),supongo que es la costumbre, caso distinto es hacerlo por un sistema y tener que hacer ¡¡reversiones!! como mencionas en tu comentario!

[YAcosta]

El historico lo manejo solo de fecha a fecha, no de hora a hora, ese caso no se me ha presentado y si ingresan dos compras con diferentes precios del mismo producto en el mismo dia igual el calculo funciona bien porque hay un ordenamiento por Id, pero en ese pantallazo no lo muestro ya que ese es un resumen de evolución de costo por afección.

Muestro pocos registros porque es solo para dar una idea o sustentar lo que estaba explicando, no pretendía sugerir que se haga exactamente igual, quizás hallan mejores formas.

Si tengo una tabla física solo para el tema de el histórico de los costos pero su construcción es un poco compleja como para explicarlo por aquí, pero básicamente lo que hago (segun recuerdo porque lo hice hace 3 años +/-) es insertar un registro por cada ingreso y hacer el calculo del promedio y por cada salida hago updates a ese registro. En la tabla de detalle de salida lo que pongo no es el valor del costo de esa transacción sino el Id de la tabla de costos donde esta el valor que tomare (lo mismo en el de salidas, aunque en realidad uso la misma tabla para entradas y salidas), de esa forma es mas fácil hacer una eliminación en el pasado y reconstruir los costos posteriores ya que quedan afectados.

Saludos

[TAHANIAN25]

buenos días, para entender un poco que quiere decir salida por consignación. ´¿en que momento debo usar esa opción? uso profit plus administrativo y en ajuste de entrada y salida del inventario me aparece esa opción.