Control de Saldos de Stock

[integral]

Que tal Amigos :

Recurro a ustedes amigos de la comunidad de VFP para pedirle sus consejos y recomendaciones.

Cual es la forma mas practica y efectiva de llevar un Control de Saldos de Stock de productos de Consumo

De tal forma que pueda luego obtener un reporte de Entradas, Salidas y Stock

Agradezco sus comentarios y sugerencias.

Saludos,  

INTEGRAL

[LEWIS LOPEZ GOMEZ]

https://www.gerencie.com/metodo-peps.html

Cordialmente:

LEWIS LOPEZ GOMEZ

Desarrollo de Software y Aplicaciones Móviles
Diseño, desarrollo y mantenimiento de sitios web
Facturación electrónica
Suministro de Hosting y Servidores en la nube

Cel: (57) 310 843 5431, Fijo: (57) (036) 338 9625

Dosquebradas, Risaralda - Colombia.

          

Jesús le dijo: Yo soy el camino, la verdad y la vida; nadie viene al Padre, sino por mí. Juan 14:6

--
Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/934e1bcb-ea53-4b04-be23-70b55cad58f5n%40googlegroups.com.

[Victor Espina]

Tres consejos:

a) Lleva una tabla de Journal, Kardex, o como quieras llamarla, donde registras TODO movimiento de stock que ocurra:  entradas, salidas, ajustres de existencia y ajustes de costo.

b) Lleva una tabla maestra de stock donde mantienes la existencia y costo promedio actual para cada pieza en inventario.  Esta tabla debe actualizarse automaticamente desde triggers en la tabla de Journal/Kardex, de modo que cada registro que se ingrese, modifique o elimine en esa tabla, recalcule automaticamente existencia y costo de esa pieza y actualice los datos en esta tabla de saldos.

c) Crea un proceso que borre el contenido de la tabla maestra de stock y la llene de nuevo en base a la informacion de la tabla de journal, y programa una tarea que ejecute este proceso todas las noches

Saludos

Victor Espina

[ggcagnola gmail]

me parece que un poco de lectura sobre stock no estaría mal

después avanzas sobre la parte técnica/desarrollo

--

Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/a266dce4-8192-4ad8-81e1-56b680a2c0cbn%40googlegroups.com.

[Miguel Antúnez]

1. Tener una tabla donde se guarden todos los movimientos a detalle, incluyendo el inventario inicial.
2.  Todo registro debe ser modificado por otro registro, prohibiendo los update's a esta tabla.
3. Guardar los ingresos en positivo y los egresos en negativo, así se puede recalcular fácilmente el stock y reportes de stock a una fecha.
4. tener una tabla de stock actual, para acceder fácilmente al stock en línea. 
5. de preferible que tengas un trigger en tu tabla de detalle de movimientos que haga el update del stock actual.

Saludos.

Miguel Antúnez C.

--

Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/934e1bcb-ea53-4b04-be23-70b55cad58f5n%40googlegroups.com.

--

Miguel Angel Antúnez Camones
mant...@gmail.com

[Jorge Kiernan]

Otro detalle a tener en cuenta, es incluir el deposito. SI bien usualmente uno lo piensa como q el stok es uno solo, no esta demas pensarlo como varios depositos.

Otro tema, mas arriba se menciono de borrar registros, no estoy de acuerdo, uno no debe Nunca borrar nada, a lo sumo anular, y en este caso ni siquiera, si hay un movimiento equivocado, se revierte con un contra movimiento.

Tene presente que los movimientos son Un cabecera + N detalles de los productos involucrados

EL cabecera te dice cuando, xq (hay diferentes tipos de entradas no solo por compra y diferentes tipo de salidas) te da un nro de comprobante asociado, te dice quien lo ingreso, a que depósito afecto, etc, y en el detalle indica el producto, cantidad (+/-) , esta bueno registrar la existencia en ese momento (por ejemplo mis sistemas de stock permiten salidas aun con stock negativo pero eso queda documentado d q el usuario lo vio y aprobo igual la salida) }

Mucha suerte

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAJX81kVhdu8vr0hgEwb1Hbhi6m50tvb7W3fRzuzSEU54SV17NQ%40mail.gmail.com.

[Victor Espina]

Totalmente de acuerdo. Lamentablemente esa es una decision operativa, no solo de programacion, por lo que es necesario convencer al cliente de la importancia de no modificar ni eliminar transacciones ya posteadas... .y eso no siempre resulta facil, sobre todo en el mundo de la PYMES... porque involucra mas trabajo para el usuario y mas complicaciones para completar un trabajo.

Victor Espina

[José Antonio Peña Martínez]

Estoy de acuerdo con Victor solo en un paso no ...

c) Crea un proceso que borre el contenido de la tabla maestra de stock y la llene de nuevo en base a la informacion de la tabla de journal, y programa una tarea que ejecute este proceso todas las noches

En esto si de acuerdo al 100:

a) Lleva una tabla de Journal, Kardex, o como quieras llamarla, donde registras TODO movimiento de stock que ocurra:  entradas, salidas, ajustres de existencia y ajustes de costo.

b) Lleva una tabla maestra de stock donde mantienes la existencia y costo promedio actual para cada pieza en inventario.  Esta tabla debe actualizarse automaticamente desde triggers en la tabla de Journal/Kardex, de modo que cada registro que se ingrese, modifique o elimine en esa tabla, recalcule automaticamente existencia y costo de esa pieza y actualice los datos en esta tabla de saldos.

Adjunto una imagen de mi Kardex de Movimientos de Un producto, este reporte de Kardex puede ser generado de un almacén o de todos, de un rango de fechas dadas, de un departamento o todos o de un solo producto para ubicar un error o faltante en alguna auditoria

Como puedes observar el trigger que graba el Kardex lo lanzas cada que afectan el movimiento y allí mismo guardas la existencia resultante además de guardarla en otra tabla de existencias del mismo producto y mismo almacén.

Los registros para auditoría se muestran en orden Fecha/hora de manera que siempre sabrás la existencia en cada momento.

Saludos

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/91c490f8-3e85-4136-9865-146d10fa99a6n%40googlegroups.com.

--

Desarrollo de Sistemas TecnoPro

José Antonio Peña

Saludos!

[Oscar Bonet]

Si usas SQL o cualquier otro motor de bases de datos

una tabla TBL_MOVIMIENTOS

campos:   

- Codigo_del_producto tipo caracter de 15 aprox    o como desees almacenar el dato

- Cantidad  tipo numerico N(12,2)   o con la cantidad de decimales desees conocer

- Descripcion movimiento    tipo caracter de 100  C(100)    o del ancho que desees almacenar informacion relacionada con el momiviento

- Tipo_Movimiento tipo numerico      este te sirve para un futuro generar un informe segun agrupacion de tipos de movimiento.  en mi sistema coloqué varios como 1=Produccion  2=Traslados  3=Ventas o Despachos,  etc

- Fecha_del_Movimiento  tipo datetime     alli es para almacenar la fecha y hora y minutos y segundos en el que ocurrió el movimeinto

- Bodega   tipo entero es el codigo de la bodega que donde se genera el movimiento (aplica solo si deseas almacenar esta informacion en mas de 1 bodega)

- Lote   tipo caracter  de almenos 15 (en mi caso)  donde se genera el movimiento (aplica solo si deseas almacenar esta informacion en mas de 1 lote )

luego otra tabla:  TBL_INVENTARIOS

campos:

- codigo_del_producto

- Bodega

- Lote

- Cantidad

-fecha y hora

- Cantidad o stock 

luego en la logica de funcionamiento de tu programa donde se vea la necesidad de registrar la informacion de inventario aplcias los movimientos en esas dos tablas.  lo que te toca resolver en el grupo el manejo de bloqueos de registros cuando se actualiza la ifnromacion de la tbl_inventario

Espero te sirva de guia lago esto,

Att

Oscar Bonet

[Victor Espina]

La razon de ser de ese paso es que hay muchas razones por la que los trigger que actualizan la tabla de saldos podrian fallar en algun momento y dejar desactualizada esa tabla.   Lo se porque me ha pasado.  Entonces, ese proceso nocturno te garantiza que al menos al iniciar cada dia los saldos y costos estaran 100% de acuerdo a las transacciones del kardex.

No deberia ser necesario... pero lo es :)

Victor Espina

[Germán Fabricio Valdez]

hay muchas formas de hacer esto con trigger sin trigger, pero si son dbf abierta es una cosa si son motores es otra.

se involucran varias tablas generalmente en una venta.  por eso es importante que sepas manejar transacciones y bloqueos y buffering.

hay muchas tecnicas.  Tambien el tema de garantizar el stock a la hora de realizar la venta de 1 mismo producto por 2 usuarios cuando solo queda 1.   pero los 2 usuarios ven queda 1, pero solo 1 lo puede vender.   podes permirir stock negativos en estos casos o no.  todas son tecnicas distintas.  si usas servidores distribuidos en sucursales con stock centralizado es un quilombo.

yo conzoco varios metodos y utilizo una que considero es la mejor en esta epoca moderna, ya que han cambiado a lo largo del tiempo por otras tecnicas mejores. 

[mpulla]

Hola Integral.

Si recuerdo bien, usas SqlServer, lo mejor que puedes usar es una vista materializada en base a tus tablas de movimiento de inventario.

Si tienes bien normalizadas las tablas y los índices correctos puedes sacar el stock al vuelo con un sql, ten en cuenta las recomendaciones de Miguel.

Saludos.

Mauricio

El lunes, 13 de marzo de 2023 a las 10:54:03 UTC-5, integral escribió:

[Max Riel]

Hola, el tema de stock se corresponde con el arqueo permanente de un bien físico versus registros en una base de datos, ok, parece simple, un archivo maestro de productos, y comprobante de transacciones con dos posibles operaciones: Ingresos o Egresos. Puede haber uno o más depósitos donde se ingresa o egresa esa mercadería.

No recomiendo un campo fijo en la tabla de productos que sea cantidad_en_stock o algo similar, dado que esa cantidad es fruto de un proceso de calculo, por lo que si sugiero que el saldo de existencia siempre venga calculado con un subquery en la BD y si el sistema manejará grandes volúmenes de información se hace imprescindible contar con un buen SGBD (huir urgente de los dbf).

A su vez para manejo de stock hay algunas variantes,

Artículos que llevan Lote: Lote es una agrupación que indica la partida de producción y la fecha de vencimiento, se aplica a alimentos , medicación y consumibles perecederos en general. 

Artículos que llevan Número de Serie: cada bien físico transaccional con esta característica se "serializa" con un número y en cada transacción se indica código de producto y NRO de Serie, validando su ingreso o egreso correcto. Se aplica por ejemplo a bienes de alto costo cómo prótesis médicas o electrodomésticos caros.

El secreto de informatizar todo esto es que el dato de los existencia surja por calculo de BD en tiempo real y luego las transacciones pueden manejarse por reserva temporaria. Cuando se comienza a cargar un comprobante de egreso y se elije un producto se reserva por x minutos hasta que se confirme la transacción entera, pasado ese tiempo el que graba primero, gana y el que viene atrás se encuentran con que la existencia ha cambiado, esto sucede con cualquier sistema de carga en línea con reserva temporaria cómo por ejemplo sacar pasajes de avión. 

Pero, reitero, un SGBD con buen manejo de transacciones en tiempo real es clave en todo esto.

Saludos

--

[Jorge Kiernan]

Max, me parece que calcular en tiempo real el saldo de existencias leyendo todos los movimientos de un producto desde que el sistema se puso en marcha, es una recarga innecesaria de procesos, tengo sistemas andando desde hace años en que los datos mas antiguos ya ni siquiera estan en linea sino en entornos históricos.

No le veo realmente la ganancia de hacerlo de esa manera, versus tener una tabla producto/deposito con su existencia, que es muchisimo mas rápido.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAHTK47sH7UMEy_pWNQZPfDxp90y-6fuS-sXSCH60CP78McMVWw%40mail.gmail.com.

[Max Riel]

Jorge, 

Si entiendo lo que mencionas a nivel perfonance, pero, hay una consideración y es el volumen de información y la potencia del servidor. Para manejo de stock promedio no he tenido demasiado problema en calcular existencias de una empresa mediana con hasta 3 años de carga de información, pero, llegado el caso de que por volumen se afecte perfomance, se hace una tabla aparte y se dejan saldos iniciales a fecha x por artículo y se comienza a calcular desde ahí, por ejemplo, se puede hacer un corte semestral. Mí estrategia de calculo en tiempo real es más segura que andar rogando que una vez actualizada la tabla de movimientos se actualice correctamente la tabla de stock por artículo, dado que por más transacción en sgdb algo puede fallar y el saldo de campo en artículo puede no coincidir con la suma de movimientos. Esto, es viejo como el mundo.

Saludos 

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAKeWEdoasAFkE5_Bw%2Bq9UkhF-YMCEi7jk%2BfRyBaYRPufmQt9wQ%40mail.gmail.com.

[Miguel Antúnez]

Max, me uno a lo de Jorge, tener una tabla alterna donde se guarde el stock actual, mientras no se le meta mano no hay pro que se descuadre, y siempre usas transacciones para asegurar su actualización.

Saludos.

Miguel Antúnez C.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/CAHTK47uu6-KkJepdQB57Sa%2BWgv9HwS4%2BVCmXhgTamF6%3D0%2BQwfA%40mail.gmail.com.

[Jose Antonio Peña Martínez]

Cada que uno de los programas o módulos del sistema o ERP que afectan la existencia del producto se lanza un programa que actualiza la existencia

en mis programas algo como esto:

/* variables de entrada al programa */

define shared variable valma  as int.
define shared variable vusu  as char.
define shared variable xlotes as integer.
define shared variable xtipomov as char.

/* Parametros */

define input parameter cod like art.Idart.
define input parameter cant as decimal.
define input parameter alm as int.

define variable contador as int.

/* dentro de una transaccion */

do transaction:
    find first exist where exist.Idalma = alm and
                           exist.Idart = cod no-error.
    if not available exist then create exist.
    assign
        exist.IDart     = cod
        exist.Idalma    = alm
        exist.cant      = exist.cant + cant.
    create kardex.
    assign
        kardex.Cant         = cant
        kardex.Exist        = exist.cant
        kardex.Fecha        = today
        kardex.Hora         = time
        kardex.Idalma       = alm
        kardex.Idart        = cod
        kardex.Idusuario    = vusu
        kardex.Num          = next-value(NumKar)
        Kardex.folio        = xlotes
        Kardex.tipomov      = xtipomov.
end.   

Como pueden ver tengo dos tablas, una se llama exist (que lleva control de la existencia del producto/articulo) basado en el almacén y el código y otra que se llama Kardex que al mismo tiempo de guardar el movimiento guarda la existencia resultante para poder reportear de manea rápida sobre la misma tabla

por supuesto que no es VFP .. pero pues solo se debería adaptar según el lenguaje que use cada uno.

Saludos!

[integral]

Que tal Amigos :

Agradezco a cada uno de ustedes por sus comentarios y sugerencias vertidas en base a su experiencia...

Me queda ahora hacer los cambios y mejoras para un buen funcionamiento.

PD : Hoy mi pais esta atravezando por uno de los cambios climatologicos mas dramaticos y fuertes de los ultimos años. A pesar de sus problemas el Peru saldra adelante y como dicen 

        No hay mal que dure cien años. Las intensas lluvias continuan. Hoy empezó a llover desde las 11:00 de la mañana. Algunos dicen que es castigo de Dios...

Saludos cordiales,

Integral

(Lima-Peru)

[integral]

Que tal Amigos :

Buscando información encontré el siguiente video en youtube que muestra la forma de Eliminar un Registro y a la vez tambien Actualizar el Stock 

https://www.youtube.com/watch?v=aPchWy4gl6g

Saludos,

Integral

[Victor Espina]

La verdad el video me parece tiene varias falencias:

a) No es eficiente enviar multiples comandos consecutivos con SQLEXEC, porque cada uno involucra un roundtrip hacia el servidor.  Es mas eficiente en este caso invocar un SP que ejecute dichas instrucciones o, en el peor de los casos, concatenar las instrucciones usando ; como separador, ej;

r = SQLEXEC(conn,  "UPDATE tabla SET columna = ?valor WHERE columna=?valor; SELECT * FROM tabla WHERE valor = ?valor", "cursor_temp")

b) SIEMPRE que se invoca a SQLEXEC es necesario capturar el resultado devuelto para verificar si el comando fue ejecutado correctamente o si ocurrio un error, ya que el SQLEXEC por si mismo no genera un error si la instruccion falla.  Esto es particularmente necesario si se estan enviando varias llamadas a SQLEXEC.  Entonces, esto

SQLEXEC(conn, "comando-sql")

SQLEXEC(conn, "comando-sql")

en realidad deberia ser:

r = SQLEXEC(conn,"commando-sql")

IF r >= 0

   SQLEXEC(conn,"comando-sql")

ENDIF

IF r >= 0

    ** FIN DEL PROGRAMA

ELSE

   LOCAL ARRAY aErrInfo[1]

   AERROR(aErrInfo)

   MESSAGEBO(aErrInfo[2])

ENDIF

c) Se recomienda no permitir eliminar o modificar registros en el kardex/journal de movimientos de inventario no por un tema de imposibilidad tecnica, sino de consistencia de datos.  Digamos que tu sacas un resumen de existencia al 30 de Enero y lo envias a gerencia.  Luego alguien viene y elimina un documento que causa que se eliminen movimientos en el kardex/journal correspondientes al mes de Enero.  Imagina que hora te piden que vuelvas a emitir el mismo informe al 30 de enero... la data ya no sera la misma mostara en el reporte anterior y eso causa desconfianza de los usuarios en la data del sistema.   Y este principio no aplica solo a este caso sino, en general, a practicamente todo lo que se hace en un ERP.... es por eso que SIEMPRE deberia aplicarse el principio de que para corregir un error la unica via es generar un reverso, NUNCA una eliminacion/modificacion, porque eso te garantiza no solo la consistencia de los datos en el tiempo sino tambien la trazabilidad de los mismos.

d) Nunca, pero NUNCA debe usarse los comandos para SPT (SQLCONNECT, SQLSTRINGCONNECT, SQLEXEC, etc) directamente.  Debe siempre abstraerse su uso con una clase o funciones personalizadas, ya que esto nos permite introducir codigo nuevo y correcciones en un punto central y que afectaran a toda la app de una sola vez.

e) Ya a nivel de recomendacion, es mejor utilizar el pattern Singleton para manejar el acceso a datos globales compartidos, en lugar de accesarlos directamente mediante variables globales o como propiedades en el _SCREEN (el Singleton usara internamente una variable global o el _SCREEN, pero eso sera transparente para el resto del programa y se podria cambiar en cualquier momento sin afectar al resto de la app).

El pattern Singleton permite que cuando se instancie una clase se devuelva siempre la MISMA instancia, por lo que los valores de sus propiedades seran siempre las mismas.

asi, en lugar de:

cn = SQLSTRINGCONNECT(_SCREEN.cad_conex)

seria mas recomendable algo como:

oConfig = CREATE("appConfig")

cn = SQLSTRINGCONNECT(oConfig.cad_conex)

DEFINE CLASS appConfig As Custom

    PROCEDURE Init

       IF TYPE("_SCreen.appConfig") = "U"

           _SCreen.addProperty("appConfig", CREATE("appConfig_Singleton"))

       ENDIF

       RETURN

  PROCEDURE THIS_Access

      RETURN _Screen.appConfig

ENDDEFINE

DEFINE CLASS appConfig_Singleton AS Custom

    cad_conex = ""

ENDDEFINE

Saludos

Victor Espina

[integral]

Amigo Víctor Espina

Muy Buenos Días

Leer sus recomendaciones y sugerencias siempre son bien recibidas y tomadas en cuenta.

Da la casualidad que es la forma como estoy aprendiendo actualmente a programar algo parecido a su ejemplo mostrado.

IF SQLEXEC(cn, lcSQL_UP_01) < 1
   =AERROR(laError)
   lcError = laError(1,3)
   MESSAGEBOX("No se Pudo Ejecutar el Siguiente Comando : " + CHR(13) + CHR(13) + ;
                ALLTRIM(lcSQL_UP_01) + CHR(13) + CHR(13) + ;
                lcError,16+0,"[ ERROR :  SQL SERVER 2008R2 ]")
   RETURN .F.                      
 ELSE
        WAIT WINDOW " [ Grabando los Campos Ingresados...] " NOWAIT
        ...     
        ...
        MESSAGEBOX("Actualizado el Consumo Modificado : " + '[ ' + ALLTRIM(UPPER(m.Prod_name)) + ' ]' + CHR(13) + ;
                   "Se Grabo el Registro en SQL Server 2008 R2...",0+64,THISFORM.Caption

ENDIF

Totalmente de acuerdo con usted en las recomendaciones.

Ahora bien, anoche estaba buscando información sobre como Actualizar el Saldo de un registro ingresado por Error...

Anoche de prueba se dio salida a un articulo que no era el correcto debiendo ser otro articulo el de salida

Ej.-   Fecha Salida      Cod. Articulo                    Cantidad         Stock           (Registro de Salida Incorrecto)

          15/03/2023        2 (Jabón de Tocador)          1                    14          

   Según el Video  : Planteaba Borrar el Registro y mediante un SP en mi caso sumar la Cantidad + Stock = 15 

                                  y Grabar el Stock Actualizado

Consulta : 

Como Usted  haría el reverso del proceso para Actualizar el Stop... 

   

Fecha Salida      Cod. Articulo                    Cantidad         Stock      Status           (Registro de Salida Incorrecto)

15/03/2023        2 (Jabón de Tocador)          1                    14             ?

Agradezco sus comentarios y sugerencias...

Saludos,

Integral

  

[Valentin Fernandez]

Fecha Salida      Cod. Articulo                    Cantidad              Stock      Status           (Registro de Salida Incorrecto)

15/03/2023        2 (Jabón de Tocador)         -1                   14             ?

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/b482c6cf-9e48-44a2-8da3-fda061a412c4n%40googlegroups.com.

--

Atentamente:

Valentín Fernández

[José Antonio Peña Martínez]

Bueno, aunque un registro sea erróneo:

Ej.-   Fecha Salida      Cod. Artículo                    Cantidad         Stock           (Registro de Salida Incorrecto)

          15/03/2023        2 (Jabón de Tocador)          -1                   14          Venta al cliente etc etc

Debes tener herramientas para hacer la corrección SIN borrar el registro, como? es sencillo

Es mejor 

Ej.-   Fecha Salida      Cod. Artículo                    Cantidad         Stock           (Registro de Salida Incorrecto)

          15/03/2023        2 (Jabón de Tocador)          1                    15          Corrección de salida venta etc etc

Esto en el Kardex y guardar en la tabla existencias la cantidad 15.

Saludos!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/b482c6cf-9e48-44a2-8da3-fda061a412c4n%40googlegroups.com.

[Victor Espina]

La forma correcta seria:

FECHA       SKU    TiPOMOV   CANT   STOCK   COSTO   OBSERVACIONES

15/03/2023  0001     SA       -1     14      15.2   SALIDA SKU ERRADO

15/03/2023  0001     AE        1     15      15.2   AJUSTE DE ENTRADA (AL COSTO DE LA SALIDA) PARA REVERSAR LA SALIDA ERRONEA

15/03/2023  0002     SA       -1     12      13.5   SALIDA SKU CORRECTO

Aqui queda claramente registrada tanto la salida erronea como el movimiento realizado para reversar el error, lo cual facilita mucho las labores de auditoria y da confiabilidad sobre los datos del sistema.

Victor Espina

[José Antonio Peña Martínez]

Es correcto Victor ... y así te basas únicamente en el Kardex para auditar tus inventarios y cualquier aclaración bien documentada...

Saludos!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/290daf90-564b-4844-8168-c408da70879cn%40googlegroups.com.

[Jose Antonio Peña Martínez]

Solo con la aclaración:

FECHA       SKU    TiPOMOV   CANT   STOCK   COSTO   OBSERVACIONES

ERRONEA:

15/03/2023  0001     SA       -1     14      15.2   SALIDA SKU ERRADO

CORRECCION:

15/03/2023  0001     AE        1     15      15.2   AJUSTE DE ENTRADA (AL COSTO DE LA SALIDA) PARA REVERSAR LA

SALIDA

MOVIMIENTO FINAL CORRECTO:

15/03/2023  0002     SA       -1     12      13.5   SALIDA SKU CORRECTO

Saludos!

[integral]

Que tal Amigos :

Procedí a realizar los ajustes necesarios y todo quedo solucionado.

Gracias nuevamente a todos por sus comentarios y sugerencias.

Saludos,

Integral

[Edwin Duran]

Saludos Integral mira este vídeo son dos que explica como debe ser un Kardex

https://www.youtube.com/watch?v=DPzVqtm3xSo

El lunes, 13 de marzo de 2023 a las 11:54:03 UTC-4, integral escribió:

Que tal Amigos :

[Nicanor Rodil]

Yo lo que haría sería es crear varias Bases de Datos: 1) Clientes Habituales o que compren en grandes cantidades y todos sus descripciones (código cliente, teléfono, dirección, E-mail, etc.), 2) Una base de datos de lo que tienes en existencia. 3) Base de datos de los productos vendidos, que se van restando a la Base de Datos de existencia, con fecha de salida, código del comprador o cliente y, sobre todo, la fecha que se vendió. Así sabrás en qué época del año se venden más tales productos y puedas prever el tener que comprar artículos nuevos.

Recuerda de hacer relaciones de mucho a mucho, muchos clientes te pueden comprar el mismo artículo o muchos artículos pueden ser comprado por varios clientes. Eso depende de tus necesidades. 

Espero haber sido de gran utilidad. Suerte.

--

Blog de la Comunidad Visual FoxPro en Español: http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/publicesvfoxpro/0c50d195-2cdd-47cc-9094-57b91cd83a1en%40googlegroups.com.