Ir al contenido


Foto

Como realizan actualizacion de precios?


  • Por favor identifícate para responder
25 respuestas en este tema

#1 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 17 abril 2015 - 03:09

Hola amigos queria saber que estrategia utilizan para actualizar los precios en un sistema de gestion? Para no actualizar uno por uno obviamente, de que manera se podria?

 

Pense un modulo donde se seleccione un proveedor y se registren los productos que se le va a comprar y luego al hacer el pedido se actualize el precio.

Para no actualizar el precio de a un producto hay que aplicar porcentajes porque sino hay que ingresarlo manualmente lo cual es imposible, porque cada producto es distinto en forma y precio.

 

Por ejemplo: todos los productos de un proveedor, ¿pueden aumentar un 10%? esto se da en la realidad? o que otro caso habría para cambiar grupal mente el precio?

 

Saludos


  • 0

#2 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 17 abril 2015 - 07:24

Hola giulichajari

Podes usar SQL:
 

sql
  1. UPDATE Productos SET Precio = Precio * 1.10 WHERE IdProveedor = :IdProveedor



La anterior sentencia SQL aumenta en un 10% todos los precios del proveedor que indiques como parametro
 
En cuanto a lo que preguntas primero, la estrategia que yo sigo es la siguiente, cuando cargan las facturas de compra de mercaderia, es necesario cargar el precio costo de cada producto. Luego cada producto tiene un % de ganancia, ese margen a priori el sistema lo va a intentar mantener. La idea cuando se carga la factura de compra es, preguntarle al usuario si quiere actualizar los precios de venta para que estos respeten el margen teniendo en cuenta el costo nuevo
 
Saludos
  • 1

#3 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 17 abril 2015 - 09:21

Opcion ampliada:


php
  1. UPDATE Productos SET Precio = Precio * (1 + :porcentaje / 100)
  2. WHERE IdProveedor = :IdProveedor and IdGrupo = :IdGrupo

donde podrias utilizar 3 parametros


  • 1

#4 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 18 abril 2015 - 06:50

Una vez escogido un grupo de productos a actualizar conjuntamente su precio, yo además de preguntar el porcentaje a incrementar, también pregunto al usuario que indique el redondeo que quiere aplicar : sin redondeo (0), redondear a fracciones de 0,05, de 0,10, de 0,20, de 0,25, de 0,50, o redondear a precios enteros (1).

 

En Firebird :


php
  1.       update PRODUCTOS set PRECIO = CEILING((PRECIO * (100.0000 + :PORCENTAJE) / 100.0000) * (1 / :REDONDEO)) / (1 / :REDONDEO)
  2.       where ID_PROVEEDOR = :ID_PROVEEDOR and ID_GRUPO = :ID_GRUPO

Si tu versión de Firebird no viene con la función CEILING ya de forma nativa, la tienes que declarar a partir de la UDF estándar que viene con Firebird mismo :

 

Es decir :


php
  1. DECLARE EXTERNAL FUNCTION CEILING
  2.     DOUBLE PRECISION
  3. RETURNS DOUBLE PRECISION BY VALUE
  4. ENTRY_POINT 'IB_UDF_ceiling' MODULE_NAME 'ib_udf';


  • 1

#5 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 18 abril 2015 - 06:59

Opcion ampliada:


php
  1. UPDATE Productos SET Precio = Precio * (1 + :porcentaje / 100)
  2. WHERE IdProveedor = :IdProveedor and IdGrupo = :IdGrupo

donde podrias utilizar 3 parametros

 

Si aparte de las consultas me referia a como se podria plantear la actualizacion ademas de la individual de un solo producto.

Me parece que al momento de encargar un producto se tiene que registrar el nuevo precio, o bien cuando se confirma el arribo de la mercaderia al local, para esto se podria tener un archivo de actualizacion de precios que se cargue de manera automatica, para no tener que buscar el producto nuevamente.

 

Pense guardar en xml el proveedor con los productos a encargarle y el nuevo precio, asi como tambien generar un excel para enviarle.

 

Muchas gracias a todos


  • 0

#6 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 05 mayo 2015 - 01:23

Llego tarde, pero quiero aportar una idea.

Algunas aplicaciones comerciales suelen utilizar más de una lista de precio. Se selecciona la lista según el cliente.

Desde mi punto de vista, como dicen los tres ya es suficiente, es decir, con una instrucción SQL. Pero si quieres dar un paso más, podrías agregar procedimientos a la base de datos para seleccionarlos en determinados casos y ejecutarlos en diferentes momentos. Me refiero a algo parecido a scripts como los que funcionan en el caso de las promociones.

 

Saludos


  • 0

#7 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 05 mayo 2015 - 04:10

Hola amigos queria saber que estrategia utilizan para actualizar los precios en un sistema de gestion? Para no actualizar uno por uno obviamente, de que manera se podria?

 

Pense un modulo donde se seleccione un proveedor y se registren los productos que se le va a comprar y luego al hacer el pedido se actualize el precio.

Para no actualizar el precio de a un producto hay que aplicar porcentajes porque sino hay que ingresarlo manualmente lo cual es imposible, porque cada producto es distinto en forma y precio.

 

Por ejemplo: todos los productos de un proveedor, ¿pueden aumentar un 10%? esto se da en la realidad? o que otro caso habría para cambiar grupal mente el precio?

 

Saludos

 

No se si es que estoy dormido o si es que hay cierta confusión en tus palabras.

¿Proveedor? ¿Y los productos que se le van a comprar? ¿Ponerle precio?

 

A ver. Pongamos orden. Si se le ve a a comprar a proveedores el precio de los productos no los uno. Eso lo establece cada proveedor. Esto no es un precio es un COSTO.

 

Ahora, si tu me dices que la idea es ponerle precios a los productos que uno vende allí si tiene sentido. En este caso si intervienen proveedores del producto el precio sería un caso de Reventa, y si se trata de que los proveedores nos aportan materia prima entonces el precio estaría hablando de fabricación+producción+etc.

 

Si aclaras mejor el contexto podríamos ver a lo que apuntas. A mi por el momento no me queda claro. ¿El módulo se trata de administrar los precios que mandan los proveedores sobre sus productos? ¿O se trata de poner precio a los productos que en realidad se van a poner a la venta? ¿Estamos en el contexto de un P2P (Provider to Producer), o un P2C (Producer to Client)?

 

Si el módulo en cuestión está basado en el modelo P2C, el típico TVP o Sistemas de Ventas (e incluso en un ERP), la asignación de los precios depende de la naturaleza del negocio. No basta el enfoque simple de "si a mi me cuesta Z pesos tener un producto y quiero tener ganancias del 30% entonces debo venderlo a 1,3 x Z". También dependerá de los tipos de productos/mercadería y el sistema de inventario que se defina.

El precio juega mucho en el sistema de inventario. No es lo mismo ponerle el precio a la lata de manzana que el proveedor me dió la semana pasada que el precio de la que me ha dado hoy. Esto afecta mucho a la contabilidad. Presten atención al método PEPS, UEPS y Método Ponderado.

Esto es vital sobre todo para manejar adecuadamente los casos de una devolución de producto. ¿Que valor se va a descontar? ¿El nuevo? ¿El viejo? ¿El promedio? No basta la simple consulta como la que pone OrtuAustin que pisa y pierde el valor. Debe tenerse un registro.

 

Asignar precios es un arte, pero tiene ciencia.

 

Saludos,


  • 0

#8 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 06 mayo 2015 - 07:56

Claro que la idea es marcar el precio del proveedor, una manera es aplicar un porcentaje al valor que el mismo manda, por eso pensaba cargar la lista si es que se recibe en formato digital en excel por ejemplo, pero es muy tedioso y deben coincidir los nombres de los articulos del excel con los de la base de datos, y no lo veo viable.

Lo mas aproximado es elegir el proveedor y mostrar los articulos que este brinda.. se le debe asociar un IVA... (que se cobra en el precio final: impuesto al valor agregado) ademas del incremento de un porcentaje.

Suponiendo que un articulo vale de un proveedor 10 pesos, con iva queda minimamente en 12,1, porque sino de donde se pagan los impuestos??????. Luego si el articulo sube a 12 pesos el IVA en vez de 2,1 son 2,5 es decir 14,5 final. y a 12.1 y 14.5 hay que ponerle la ganancia.

 

Otra idea es tener la ganancia deseada en la tabla de producto, aunque con la inflación la ganancia aumenta(no al ritmo de la inflación sino esta no seria problema).

Para hacer una nota de crédito por devolución de un producto, simplemente buscamos el historial del cliente que lo esta devolviendo, o la factura asociada, ahi esta registrado el precio.


  • 0

#9 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 06 mayo 2015 - 11:28

Ten en cuenta que agregar el IVA y luego la ganacia será en algunos casos. Sólo los responsables inscriptos pueden deducir el IVA para luego obtener lo que se denomina crédito fiscal. Los comercios monotributistas siempre tienen un costo con IVA aplicado.

Los comercios con régimen monotributistas agregan un porcentaje para obtener ganancias, a lo sumo en la fórmula puede ingresar el costo del envío.

 

El IVA es un porcentaje que termina en Argentina en un valor de 21% (creo que es en partes iguales 3 veces 7%) para algunos productos, pero no para todos, algunos comestibles solo tienen un IVA de 10,5% (es decir la mitad). Para entender muchas de estas cosas hay que comprender qué es ese impuesto (maldito impuesto). Y a groso modo es una suma de tres impuestos que se agregan al fabricante, distribuidor y minorista (o detallista) para que al final lo pague el consumidor.

 

La mayoría de los sistemas aplican la fórmula de preciación mediante la agrupación del mismo proveedor. Otros lo hacen por lo que ellos -los comerciantes- denominan rubros y en realidad es línea o marca (ya que rubro es otra cosa). Yo prefiero agregar una clasificación que denomino categoría y es mediante ésta que aplico los diferentes parámetros para las mismas fórmulas.

 

Es un tema delicado, ya que al final depende de la política de cada comercio y la mayoría no quieren que el sistema les imponga una manera de trabajar.

 

Saludos


  • 0

#10 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 06 mayo 2015 - 07:44

Es un tema delicado, ya que al final depende de la política de cada comercio y la mayoría no quieren que el sistema les imponga una manera de trabajar.

 

 

 

Te me adelantaste, iba a poner justo eso mismo

 

Lo que comenta Delphius es totalmente valido, pero en realidad depende del comercio

 

Si tengo un kiosco que vende caramelos, no me compliques la vida con PEPS o PPP :p

 

A mi estas cosas me gusta charlarlas con el cliente y ponernos de acuerdo (siempre hago a medida los sistemas)

 

Si lo que se busca es hacer algo "generico" en realidad yo creo que la mejor opcion es que se pueda configurar.. es decir, que el precio se asigne manualmente por producto, usa un margen de ganancia de acuerdo a la factura de compra, agrupar por categoria y aplicar porcentajes, o llevar el control completo del inventario en el que importa la fecha (porque vendo pan y facturas por ejemplo)

 

El tema es bastante largo, pero por lo general en la mayoria de los casos es a lo "pica piedra", porque como comentan arriba, es molesto que te impongan la forma de trabajar, que calcule algo tan "sensible" y que por ahi se te pase y te ponga un precio que no va, mas en la situacion que esta el pais hoy :p


  • 0

#11 Azidrain

Azidrain

    Member

  • Miembros
  • PipPip
  • 18 mensajes

Escrito 22 mayo 2015 - 04:32

La pregunta que haces tiene que ver más bien con el diseño y casos de uso que con la programación. Te puedo poner un ejemplo basado en como lo manejan las grandes cadenas de venta al retail:

 

  1.  Se tienen N productos
  2. Se tienen N proveedores
  3. Cada proveedor nos puede surtir algunos de los N productos que vendemos,
  4. Algunos productos nos los puede surtir mas de un proveedor
  5. Cada proveedor nos da un precio al cual le compramos sus productos (precio de costo)
  6. Nuestros productos los vendemos siempre a un mismo precio al público (precio de venta) sin importar cuanto nos costó comprarlo.
  7. Dependiendo del precio al que hayamos comprado y que vendamos será nuestra utilidad o ganancia
  8. Nuestro inventario siempre lo calculamos a precio de venta, es decir nuestro inventario en dinero sera igual a existencias por el precio de venta en ese momento

 

Con base en lo anterior:

El precio de venta lo podemos cambiar en cualquier momento pero tenemos que registrar el incremento o decremento en nuestro inventario en dinero.

Si un proveedor nos cambia sus precios y no corresponden con los que tenemos registrados, basta con hacer al aumento o disminución del inventario en costo que está entrando con nuestra compra, a saber:

 

Compramos 100 piezas a $80 para venderlas a $100. Nuestros costos son de $8,000 y nuestro inventario queda en $10,000, o sea una utilidad bruta de $200 (hasta que no se venda la última pieza no lograremos los $200).

Luego, compramos otras 100 piezas a otro proveedor ( o al mismo) que nos la vende a $90. A nuestros costos agregamos $9,000 y a nuestro inventario agregamos $10,000 ya que nuestro precio de venta sigue igual.

 

Entonces:


php
  1.  


php
  1. Compras   $8,000
  2.           $9,000,
  3. Total: $17,000
  4. Inventario $20,000
  5. Utilidad: $3,000

Cu

Cuando se venda la totalidad de las piezas obtendremos $3,000 de utilidad sin importar a que precio compramos cada artículo.

 

Es decir, no importa que precio tenga registrado por parte del proveedor en mi sistema, si registro mis aumentos o disminuciones al momento de dar entrada a mi inventario automáticamente ajusto el mismo a sus valores correctos y puedo obtener la utilidad real de cada artículo. Los precios que tengo registrados por parte del proveedor solo son una mera referencia y no deben jugar para nada al momento de afectar las cuentas del negocio. 

 

Ahora bien, vamos a suponer que queremos variar el precio de venta, esto en automático nos va a cambiar el valor de nuestro inventario por lo que tenemos que hacer el ajuste en dinero del mismo ya sea con un aumento o disminución.

 

Supongamos el ejemplo anterior, nuestro inventario vale $20,000 (pensando que no ha tenido movimiento)

 

Entonces decidimos que ahora lo queremos vender no en $100 sino en $95, Hacemos la operacion de el total de piezas (200) por la diferencia de precio (-$5) y obtenemos que rebajeremos $1,000 a nuestro inventario en dinero, entonces en lugar de tener $20,000 ahora tenemos $19,000 la diferencia la comprobamos con un registro de "rebaja" por esa cantidad de manera que:


php
  1. Compras $8,000
  2. $9,000,
  3. Total : $17,000
  4. Inventario $20,000
  5. Rebajas: -$ 1,000
  6. Inventario: $19,000
  7. Utilidad: $2,000

Como podemos darnos cuenta nuestra utilidad disminuyó. Si se hubieran subido precios de venta la utilidad aumenta. En ambos casos al ser ajustes siempre en función de la existencia que tengamos tendremos un valor real de nuestro inventario y una utlidad también real sin importar si contamos o no con listas de precios del proveedor. 

 

Este esquema quita y limita problemas comunes con la mayoría de programas de gestión:

  1. No es posible dar entrada a artículos con precios de costo diferentes a los registrados en el sistema para un proveedor
  2. No es posible calcular cuanto vale el inventario dado que se utilizan esquemas contables rígidos
  3. No es posible cambiar precios de venta debido a que no se han recalculado costos en el inventario
  4. etc.

 

 


  • 0

#12 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 23 mayo 2015 - 06:07

No esta mal tu idea @azidrain. Por lo pronto no me interesa el stock inventario etc...

Otra cosa que pensaba era obtener el precio al que, si un producto es vendido pagando el IVA se recupere el dinero pagado al proveedor.

Si el impuesto(IVA) es del 21%, y un producto vale $10, se lo debe vender a $12,5. Ya que: el 21% es 2.5 y 12.5-2.5= 10.

Entonces si a 12.5 le sumo la ganancia me queda el precio final. Es decir que a mas de 12.5 hay un margen de ganancia.

Y es mejor hacerlo al reves: si quisieramos ganarle 3 pesos al producto que vale 10... debo hallar un numero que menos su 21% de como resultado 13... entonces 10 son para el proveedor y 3 de ganancia...


  • 0

#13 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 23 mayo 2015 - 11:51

Otra cosa importante, el esquema de la base de datos debe tener(ademas de otros campos):

 

PRODUCTO(precioproveedor, iva, preciofinalb,ganancia,preicofinala);

 

Porque lo que llamamos precio, en realidad depende de la factura:

 

Si es B: el iva no esta discriminado, entonces se tomaria preciofinal(es un precio que menos el 21% debe dejar precioproveedor y una ganancia).

Si es A: se tomaria preciofinala que es precioproveedor mas ganancia(la ganancia aparte para que el user la decida), y el iva se discrimina, y se suma la cuota al valor bruto, ademas de los subtotales.

No se que les parece.


  • 0

#14 Azidrain

Azidrain

    Member

  • Miembros
  • PipPip
  • 18 mensajes

Escrito 23 mayo 2015 - 01:25

La utilidad se calcula siempre ANTES de impuestos, es decir, al precio de costo que tengas se le aumenta el % de utilidad que quieras y al resultado ya se le aplica cualquier impuesto. Los impuestos NO deben ser parte de los cálculos para obtener utilidades pues no es dinero nuestro. No entiendo bien a que te refieres con precio a y precio b.


  • 0

#15 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 23 mayo 2015 - 03:39

La utilidad se calcula siempre ANTES de impuestos, es decir, al precio de costo que tengas se le aumenta el % de utilidad que quieras y al resultado ya se le aplica cualquier impuesto. 

si el costo es 10 y quiero ganar un 20% son 2 pesos... pero no puedo vender el producto a 12 porque pago 2.4 de impuestos(20%) y me quedan 9.6 osea pierdo dinero.

 

precioa seria con la ganancia y ademas se pone el impuesto (es para factura a), percob con impuesto y ganancia incluida.


  • 0

#16 Azidrain

Azidrain

    Member

  • Miembros
  • PipPip
  • 18 mensajes

Escrito 23 mayo 2015 - 03:47

No, me entendiste mal, lo que quieres ganar se lo tienes que sumar al precio de costo. De ahi ya calculas el impuesto y el precio final, tu utilidad permanece intacta. Por eso te dije que el precio de venta se calcula asi: (precio_costo + utilidad_deseada) + impuestos. Nuevamente, los impuestos NUNCA se deben tomar en cuenta para nada en operación de la empresa pues no es dinero de ella y lo tiene que entregar al fisco.


  • 0

#17 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 24 mayo 2015 - 08:13

No, me entendiste mal, lo que quieres ganar se lo tienes que sumar al precio de costo. De ahi ya calculas el impuesto y el precio final, tu utilidad permanece intacta. Por eso te dije que el precio de venta se calcula asi: (precio_costo + utilidad_deseada) + impuestos. Nuevamente, los impuestos NUNCA se deben tomar en cuenta para nada en operación de la empresa pues no es dinero de ella y lo tiene que entregar al fisco.

osea en mi caso si quiero ganar 2 pesos al producto que el proveedor me cobra 10... son 12 pesos mas 2.4 quedan 14,4 de preico final..ahora si entiendo..


  • 0

#18 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.448 mensajes
  • LocationMéxico

Escrito 24 mayo 2015 - 05:46

Muy buena explicación Azidrain.

Bienvenido a delphiaccess, para algunos ya eres conocido.

Saludos
  • 0

#19 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 27 mayo 2015 - 10:59

osea en mi caso si quiero ganar 2 pesos al producto que el proveedor me cobra 10... son 12 pesos mas 2.4 quedan 14,4 de preico final..ahora si entiendo..

 

Por ahí había leído que el IVA es una suma de varios impuestos, en el caso de Argentina es de 21% que es el resultado de tres veces 7%. Un impuesto en la fabricación, otro en la venta mayorista y por último en otro en la venta minorista. Cada parte calcula el impuesto justo antes de entregarlo al cliente según sea el caso. Es decir, la fábrica entrega al mayorista con un 7%, el mayorista le agrega otro 7% para entregarlo al minorista y es el minorista el que termina cobrando todo al cliente, es decir la suma de los impuestos anteriores.

Dándole vuelta, el cliente entrega el 21% y paga los impuestos de el minorista, el mayorista y el fabricante. No se si lo entendí bien, pero más o menos así es la cosa.

 Por esta razón es que es luego de agregar la ganacia que se le "aplica" ese porcentaje (el del IVA).


  • 0

#20 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 27 mayo 2015 - 11:05

Actualmente, no sé si me convencerá del todo, pero estoy desarrollando un mecanismo de preciación mediante un perfil que se almacena en una tabla.

El perfil us el dato proveedor (preferido), la línea, las marca y la categoría. Según cada uno de estos se aplica un valor a partir del costo.

Un procedimiento realiza la tarea de leer cada perfil y crear varias listas de precio.

Un cliente tiene asociada una única lista de precios.

Mi problema actual para terminar dicho mecanismo de preciación es más que nada debido a la integridad referencial, por lo que se tiene que esperar algún error por falta del usuario y tener una salida de escape, como por ejemplo un valor por omisión.

Esto me acarrea un gran número de inconvenientes, como por ejemplo, tener que indicar al vendedor que hubo un error al obtener el precio, tener que crear interfaces cómodas para crear los perfiles, la aplicación de los mismos, etc.

 

Parece una locura sin sentido, pero existen sistemas de gestión que incluyen hasta tres listas de precios dentro de la tabla de artículos y esto viola una de las reglas de normalización.

 

Saludos.


  • 0




IP.Board spam blocked by CleanTalk.