[caracas-pm] [OT] Valores negativos en inventario

[Carlos Ramírez]

Hola Alberto,

Ciertamente concuerdo contigo que "lo correcto" en este caso depende de la
política del negocio, ahora lo correcto para mi persona es que no se
debería permitir, me explico, creo que debe facilitarse tanto como sea
posible al "usuario" el uso de un sistema y que un sistema debe ser una
herramienta y no una piedra de tranca en los procesos, pero los sistemas
deben ser confiables para  cuidar los intereses del "negocio" y que
constituyan una herramienta real, fiable y obviamente que facilite
procesos.

Pueden existir tópicos más complicados, ¿qué sucede, si tienes faltantes o
sobrantes en los insumos directamente en los procesos de compra?, o como
indicas que es para posibles artesanos/costureros (a modo de ejemplo, lo
entiendo), ¿Qué sucedería si un cliente dejará para buscar posteriormente
un mueble/camisa de un lote que estaba llevando y lo facturan porque aunque
el sistema dice que no tienes, el vendedor lo ve y piensa ¡si hay!, y lo
vende?

Particularmente no concibo un mecanismo de compra - venta que maneje
inventario sin un proceso "administrativo" de ajuste por el cual arreglar
este tipo de situaciones, por otra parte, creo que todo inventario debería
tener asociado un kardex, si haces la traza y permites negativos sin
ajustes, con toda seguridad terminarás con un desastre para trazar y con
niveles de confiabilidad de inventarios inciertos.

Cuando digo administrativo lo digo en el sentido más simple, un mecanismo
que desde la misma venta permita corregir el stock pero dejando la traza en
el kardex de que fue un arreglo intencional del "administrador".

Al usar Postgres, el kardex puede ser muy fácil porque sale directamente
con desencadenadores en las acciones de insert y update.

Tal vez me estoy yendo muy lejos, pero también pienso que si localizaste
una posible necesidad y te motivo a hacer esta pregunta es que
probablemente algo de esto ya te encuentres visualizando.

Por último soy de los que piensa que los "usuarios" siempre buscan atajos
como estos para saltarse procedimientos y después culparan al programador
por dejarlos (ya sabes, la culpa es del árbol que produjo la madera de la
flecha y no del indio que la disparó).

Saludos,

*-----------------------*
*Carlos Ramírez.*

El 18 de febrero de 2015, 20:26, Alberto Mijares <amijaresp at gmail.com>
escribió:

> Hola lista,
>
> Disculpen el OFF-TOPIC, la consulta no se refiere a Perl pero como
> volvímos a perder las listas de VELUG (l-desarrollo particularmente),
> no sé dónde podría consultar.
>
> Estoy haciendo un software de gestión de negocios para pequeños
> comerciantes. Algo bastante simple, llamarlo ERP sería demasiado, y la
> idea es que permanezca sencillo. Lo que se quiere es registrar es
> compras y ventas; a partir de ahí, llevar un inventario muy simple y
> poder simular una pequeña cadena de procucción. Y reportes, claro.
> Pero no se va a llevar impuestos, bancos, cuentas por cobrar o pagar,
> facturación ni nada de eso, mucho menos RRHH. Digamos que está
> orientado al comercio informal o negocios personales (costureras,
> reporteros, artesanos, carritos de perrocaliente y esas cosas).
> Quienes necesiten llevar todas esas cuentas pueden usar GNUCash.
>
> Lo que quiero saber es qué opinan de los valores negativos en los
> campos de existencia de inventarios. Formalmente, creo que no debería
> permitirse: no se puede vender algo que no tienes, etc; pero también
> creo que siempre existirán excepciones que van a requerir intervención
> humana. ¿Si compro un insumo, y olvido registrar la compra, tengo que
> dejar de vender, aún teniendo la mercancía disponible? Supongo que ese
> es el caso más común y creo que "lo correcto" depende de la política
> del negocio pero me gustaría conocer la opinión de ustdes.
>
> Gracias de antemano.
>
> Saludos
>
> PD: Mojolicious + PostgreSQL, FYI XD
>
> Alberto Mijares
> _______________________________________________
> caracas-pm mailing list
> caracas-pm at pm.org
> http://mail.pm.org/mailman/listinfo/caracas-pm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/caracas-pm/attachments/20150220/dc64077f/attachment.html>