[Cognitiva Consultores]

Paso unos fix para que tengamos en cuenta en el próximo release

Bug de Combos sin líneas: Si existe un combo publicado sin lineas, el TPV se cuelga y la aplicación se tilda consumiendo la mitad del procesador…

Error al vender con configuracion de TPV para que genere Presupuestos: En la configuración normal dará un error de Periodo Cerrado, para solucionarlo le seteamos al Tipo De Documento Para la Entrega con el valor de Remito de Salida.

Error por Orden de Secuencias en Descuentos: Si no se tiene el cuidado de cargar las secuencias de menor valor con los cortes de mayor valor, los descuentos no funcionan.

[Franco Bonafine]

Estuve viendo estos bugs y a continuación van mis comentarios para que queden asentados en el tema.

Bug de Combos sin líneas
Correcto. Este es un bug que ya había sido detectado y registrado.

Error al vender con configuracion de TPV para que genere Presupuestos
Correcto. El problema va mas allá de lo que se indica aquí, ya que además el TPV está registrando los cobros y allocations en ese caso, lo cual tal vez no sea el comportamiento deseable.

Si te parece comentame algo mas acerca de este problema, por ejemplo para qué surgió la necesidad de usar el TPV solo para emitir presupuestos, otros errores, etc. El bug ha sido registrado.

Error por Orden de Secuencias en Descuentos
Justamente el sistema hace una búsqueda secuencial de las reglas del esquema de descuento, por lo cual las reglas mas específicas hay que definirlas antes que las reglas mas generales. Por ejemplo si tenemos un 20% en el artículo Mouse Genius Modelo XXX, y un 10% en la subfamilia Mouses, hay que definir primero el corte por el artículo específico y luego el corte de la subfamilia. Si lo hacemos al revés, el sistema va a aplicar el 10% por ser un mouse y va a ignorar el descuento específico, ya que al aplicar un corte no sigue recorriendo el resto.

[Cognitiva Consultores]

Quote:

Error al vender con configuracion de TPV para que genere Presupuestos
Correcto. El problema va mas allá de lo que se indica aquí, ya que además el TPV está registrando los cobros y allocations en ese caso, lo cual tal vez no sea el comportamiento deseable.

Si te parece comentame algo mas acerca de este problema, por ejemplo para qué surgió la necesidad de usar el TPV solo para emitir presupuestos, otros errores, etc. El bug ha sido registrado.

Franco, gracias por la rta. Mira, llegamos a esa configuración porque el TPV duplica los pedidos si éstos se facturan desde el TPV. Es decir, si un vendedor creó un Pedido, y se factura desde el TPV y la configuración del TPV indica que se va a generar un Pedido, entonces se vuelve a crear un pedido que ya existía. Por esta razón, probamos la configuración de Presupuesto, para que al menos genere un documento diferente de Pedido y el peor de los casos no exista esta duplicidad. Pero bueno, lamentablemente el TPV tiene como concepto inherente a su definición el pedido de cliente, lo cual ralentiza su tiempo de respuesta también.

[Franco Bonafine]

Entiendo la cuestión de la duplicidad de los pedidos. El motivo principal por el cual el TPV siempre genera el Pedido es porque para generar el remito de salida el mismo debe estar asociado a un pedido.

En el caso de agregar un pedido pre creado, también tiene sentido que el TPV cree un nuevo pedido ya que en el TPV se podrían por ejemplo agregar mas de 1 pedido previamente creado, y mas aún se podrían modificar esos pedidos directamente del TPV por ejemplo agregando nuevos artículos manualmente, o eliminando alguno existente en el pedido orginal. En este caso, el TPV creará un nuevo pedido que refleja la venta real realizada.

Tal vez una mejora sería que, cuando se agregan pedidos pre-creados al pedido del TPV, el mismo siga creando su propio pedido pero que la lógica cancele o cierre el pedido original pre-creado. De esa forma el resultado de la venta será un único pedido (el que crea el TPV) el cual va a tener una asociación directa con el remito y la factura.

[Javier Ader]

Buenas Franco. Estuve mirando el código en 10.09, y si, parece requerir un pedido por remito, pero:

1) No hace la validación de este requerimiento (eso hace en MInOut.prepareIt se obtenga un pedido a partir del id C_Order_ID = 0), y te permite completarlo sin problemas…el tema es que hace cosas muy raras con el stock: al acceder al “pedido” con id 0, actualiza el stock utilizando attributos de instancias creados al vuelo (esto creo que antes no pasaba….). Esto es, si es requerida tal asociación de cabecera de remito a cabecera de pedido, que no permita completar un remito al cual nunca se le especifico el pedido.

y
2) No veo la razón de esta necesidad; por un lado porque en muchos casos es muy “restrictiva” (uno tiene que si o si , usar un pedido… en muchos casos, veo como algo mucho más frecuente que no se usen pedidos; lo veo innecesariamente burocrático), y por otro “poco flexible” (no solo desde el TPV, si no, en general): uno puede asociar un solo pedido a un remito… Lo extraño, es que las tablas parecen indicar “claramente” (al menos para mi), que la asociación entre remitos y pedidos en realidad se da a nivel de lineas (pero tampoco debería ser un necesidad); esto es, un linea de remito puede “satisfacer” a una linea de pedido, otra de otro, etc. La relación pedido-remito, es muchos a muchos y se da en realidad a nivel de lineas. El C_Order_ID en la cabecera del remito para mi no tiene mucho sentido, salvo a lo sumo para marcar que un remito fue generado a partir de un pedido, pero solo como un campo informativo sin mayor semántica. Lo mismo con la facturas-pedidos; ademas acá también se da la relación factura-remito a nivel de lineas.

[Taboada Mirian]

Hola Javier,

Sabes si la unica forma para generar un remito SIN referenciar un pedido es a traves del código solamente? Ya que en Reglas de Validacion, no encontré nada..

Espero tu respuesta,

Muchas Gracias

Saludos

Mirian

[Antonio Calviño]

Mirian,
No es posible hacerlo por configuración ya que hay logica por detrás que no puede ser salteada por parametrización (al completar el remito, busca SI o SI el pedido para validar cuánto resta entregarle al cliente). La aplicación espera que hagas un pedido como 1er paso y luego si, podes facturar o entregar en forma indistinta, pero debe existir el pedido.
De todas maneras, lo que podes hacer es crear un pedido y luego el remito crearlo a partir del pedido con el botón “crear desde”, con lo que el unico dato que debes ingresar al hacer el remito es el cliente. Si bien hay que entrar en 2 ventanas, no estarías cargando todo dos veces.

Otra alternativa que es medio rebuscada pero podría servirte, es que si no vas a facturar y solo vas a hacer el remito de salida, podes generar un remito de proveedor con el tipo de documento “devolucion a proveedor”. Esto es una salida de mercadería. Si en vez de un proveedor, pones un cliente… le estás haciendo un remito a un cliente, el cual descuenta de Stock. Esto no lo podrás facturar despues, pero si no es el caso… no habría problema.

Saludos
Antonio.

[Kristiam Alvarez]

Creo que este es un problema de programación, porque si existe un pedido ya creado y luego lo deseo facturar por medio del TPV si va a crear un nuevo pedido con las lineas del anterior o agregadas o quitadas deberia de cancelar el anterior y quedar todo con lo nuevo pues si descargas 10 articulos podras ver que en el Almacen ya te aparta el doble de los articulos facturados uno con la cantidad de los productos creados con el pedido anterior y otro creadas con las nuevas lineas del pedido creado por el TPV al final no te dejaria vender esa mercaderia porque se supone que ya esta apartada.

[Autor]

Entradas