[Cognitiva Consultores]

Cuando se asienta un Remito de Compra, por ejemplo, los asientos quedan en cero, y según éste link eso ocurre porque la tabla M_product_costing tiene los montos de los costos en cero, pero no se como soluciarlo ni porque queda así. Las tarifas de costos tienen al producto que asienta el remito.

[Javier Ader]

Si, yo había tenido ese problema. Al final no lo había investigado más, pero ahora que lo decís me puse a mirar un poco. Al parecer la tabla M_Product_Costing tiene asociada la ventana de Artículos, pero esta ventana no tiene asociada ninguna pestaña relacionada con esta tabla. Mirando un poco más M_Product_Costing tiene otra columna de enlace a tabla principal; en este caso a C_AcctSchema ; esta última tiene asociada la ventana Esquema Contable, pero de nuevo está ventana no tiene una pestaña a la tabla M_Product_Costing… Esto es, ninguna de las dos ventanas te va a permitir setear estos valores.
A nivel de sql M_Product_Costing es “medio extraña” ; ya que tiene una clave primaria doble con los dos Ids y que ademas son referencias a M_Product y a C_AcctSchema (e.d, es una relación muchos a muchos entre el producto y un esquema contable). También es raro que a nivel de libertya tiene solo 3 columnas acualizables, isActive, currentCostPrice (este creo que es el que importa) y FutureCostPrice. Los demás precios que aparecen, readonly desde esta tabla y creo que están seteados automáticamente a partir de la creación de listas de precios.

Ok, como se podría tener acceso a esta tabla? Supongo que podrías agregando un pestaña contable (para que no la vean todos) en Artículos asociada con esta tabla (nivel de pestaña 1; secuencia le pondría alguna justo después de la pestaña Accounting, pero esto va en gusto).
En cualquier caso vas a tener que ir producto por producto sentándole este “precio de costo”. Esto me hace pensar que tal vez exista un proceso o alguna otra ventana que permita hacer esto de una manera un poco más práctica (después busco alguna consulta sql que permita me ver cuales son todas las ventanas cuyas pestañas están relacionadas con esta tabla); por ej, un proceso que automticamente copie los campos calculados a partir de las listas de precios en los currentCostPrice.

Ahora, contablemente creo esto se usa para dar una valoración interna de tus propios bienes y el valor usado acá no necesariamente tiene que ser el precio de costo usado realmente en la compra del producto (Mercadería y Materias Primas es de Activo, aunque esto no se si dice mucho), pero en contabilidad tengo un baches bastantes grandes.

PD : si miras la salida en consola del servidor de aplicaciones vas a ver que muchas el procesador contable va a buscar filas a M_Product_Costing y al no encontrarlas muestra un mensaje de warning relacionado (creo que también lo muestra si el precio encontrado es cero).

[Cognitiva Consultores]

Gracias por la data Javier, de todos modos éstas son malas noticias… bueno habrá que hacer algún abm de la tabla de costos. Es muy extraño.

[Antonio Calviño]

La tabla se llena con el documento de matchinv, es decir el proceso mediante el cual se asignan los Remitos con las facturas. A partir de allí hay lógica en el procesador contable para cargar datos a esa tabla.

Los datos se toman desde las listas de precios o el pedido. Hay un algoritmo que determina cuál es el precio correcto y que intenta mediante varios mecanismos encontrarle un precio de costo al producto que sea diferente de cero.
Al parecer, hay un tema respecto de la comparación con cero que hace que el algoritmo que llena la tabla se confunda y registre un valor en cero pensando que no lo es. Se está haciendo una comparación con cero que devuelve un cero con diferente precisión que el comparado, por lo que el algoritmo “piensa” que encontró un costo cuando no lo hizo. Para probarlo, hay que poner un precio en la lista de costo en los 3 valores, incluído el precio límite (creo que ahi está el problema) en un producto nuevo, luego generar un pedido, un remito y una factura a partir de éste. Ahi debería cargar el costo en la tabla.

También es cierto que se podría agregar una ventana que permita la carga y edición manual de precios de costo para los casos de excepción. No sería demasiado complejo en primera instancia.

Espero haber aclarado un poco la situación.

También es cierto, por otro lado, que la mayoría de las empresas en argentina toman las valuaciones de inventario como diferencia del balance anterior contra el actual. Hay una cuenta (que yo nunca recuerdo) que da el inventario actual.

Saludos
Antonio.

[Javier Ader]

“Valoración de inventarios”, esa era concepto. Me da la sensación por lo que dice Antonio que esos asientos son generados aútomaticamente para dar un valoración de inventario en tiempo real, pero solo como dar un idea “del valor de los bienes”, así que en caso de ser un bug, no sería muy importante. Algo leí en google (es lo que hay jajaja) y me resulto raro que simplemente no se usase el precio de costo de los productos para esto. Meditando un poco me di cuenta que el tema debe venir cuando hay una disminución, por ej por una venta. Ahi no se sabe por cual valor disminuir (por ej, si tengo 10, 7 lapiceras que compre a un 1$, 3 a 2$, y vendo 8; por cuanto disminuyo mi valoración de inventario?). En este sentido, qué la valoración no ande tampoco cuando hay aumento de artículos no lo veo tan mal, ya que me da la sensación que en cualquier caso la valoración real es siempre un proceso “humano” (supongo que en un empresa, si el contador quiere decir que la valoración del inventario es X, tiene y va a ser X por más de lo que diga libertya o cualquier otro software de gestión).

Ahora, en cuanto a hacer una ventana para mostrar esta tabla o asociarsela como una pestaña a la venta de productos lo veo simple y se podría usar como una prueba de concepto para el framework de componentes.

[Cognitiva Consultores]

Gracias antonio por la rta.

Javier, Estoy de acuerdo con vos en que en ningún caso representa un problema para la operatoria pero solo porque existen costos resumidos disponibles… es decir, la contabilidad de costos es crítica para una organización, y el contador nunca va a saber a cuento se compró una mercadería salvo que tenga una pila de facturas de compra a mano cosa que no me parece muy compatible con un ERP; con ésto quiero decir que no darle ninguna info de costos al contador nunca puede ser la solución.

La buena noticia es que muchas veces el control se lleva simplemente haciendo la cuentita de Costo de Mercadería Vendida = Existencia Inicial. + Compras de mercaderías. – Existencia Final. Lo que si bien requiere de info de stock esta es totalmente resumida y puede ser tomada del sistema y hasta donde alcanzo a ver es compatible con el LY aún si las imputaciones a la cuenta contable CMV (Costo de Mercadería Vendida) son cero.
El problema con éste método es que no se detectan faltantes por robo o por pérdida, pero es según entiendo, el mas usado en el sector Pyme argentino.

Las otras posibilidades que aparentemente contempla el sistema son FIFO (PEPS) y LIFO(UEPS). En el primero valuas tus existencias al costo de compra mas reciente, y en el 2do valuas al costo mas antíguo. Hay un tercer método que es el PPP (Costo Promedio Ponderado) donde se valúa tu existencia con un promédio de los precios de compra, pero este no está contemplado en el LY. De todas formas entiendo que los algoritmos de costos son clases encapsuladas de manera que no debería ser demasiado complicado incorporar una nueva, en teoría.

Voy a mirar un poco como trabaja el LY con al menos con los FIFO y LIFO, ahora que Antonio nos explicó la mecánica general para el impacto de las ctas ctables asociadas, después te cuento como me fué.

[Autor]

Entradas