Respuestas de foro creadas
-
Entradas
-
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, la prueba la hiciste sobre una 10.09 verdad?
Es raro que el TPV no esté haciendo caso al tilde en la Configuración. En la actual versión de desarrollo el error no existe ya que el código que imprime el ticket presenta lo siguiente:
Code:// El pedido tiene al menos un artículo que se retira por almacén,
// además se creó la factura y el TPV está configurado para emitir el
// documento de retiro
if (order.getWarehouseCheckoutProductsCount() > 0
&& invoice != null
&& [b]getPoSCOnfig().isPrintWarehouseDeliverDocument()[/b]) {
….
}Por lo cual esto estará corregido en el nuevo release.
Retomando el tema… y respondiendo a la pregunta de Javier, si el cliente paga con $100 una venta de $60 no es correcto registrar una línea de caja de entrada por $100 porque la realidad es que entraron $100 pero salieron $40, por ello es que el sistema directamente registra los $60 y con eso cancela la factura.
El problema de esto es que, como comentan, el sistema no registra en ningún lugar con cuanto pagó el cliente realmente por ende el módulo de las fiscales no tiene posibilidad de obtener esa información para poder imprimir correctamente el cambio.
Existe una solución al problema la cual será implementada aunque no para el próximo release, que es ampliar el paso de cobro en el TPV. Al seleccionar Efectivo el operador deberá indicar el importe real de efectivo que se usará para pagar la factura (en el ejemplo serían $60). Luego, al presionar el botón Cobrar el sistema detectará que hay un pago en efectivo y antes de continuar mostrará un popup el cual permite ingresar el importe con el cual el cliente abona realmente (en el ejemplo sería $100). Ese importe será guardado en un nuevo campo de la factura y luego al emitir el ticket fiscal, en vez de agregar el medio de cobro según la línea de caja agregará el cobro en efectivo a partir de lo que esté registrado en ese nuevo campo de la factura, el cual contiene el importe en efectivo con el cual abonó el cliente.
Matías
Los errores de impresión de Ticket que comentás se dan en el caso de usar un artículo “dummy” con precio $1 y cambiando el precio manualmente. Por algún motivo la impresión del ticket no tiene en cuenta el precio modificado manualmente y ahí es donde comienzan los problemas. Está claro que el error es en el módulo de impresión fiscal ya que comentás que los documentos quedan guardados correctamente.
La buena noticia es que esto ya ha sido corregido y el fix estará en el próximo release estable.
De todas formas, sería bueno que realices una prueba tal como indica Javier en donde intentes emitir un ticket cuyos artículos tienen definido el precio en la tarifa y en donde además no realices un cambio manual del precio (que es justamente la causa del problema).
Probablemente sea una cuestión de la JVM ya que además el error no es reproducible en todos los casos. A veces ocurre y otras veces no.
Estuve haciendo pruebas bajo Windows (XP) y ahí pareciera funcionar bien ya que luego de varios intentos no pude lograr que se pierda el foco como sucede en Linux.
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.Estimado:
Para cambiar el tamaño de la hoja del reporte tienes que ir al menú Edit -> Report Properties en el iReport (yo tengo la versión en inglés). Al entrar en esa ventana vas a ver una serie de tamaños preconfigurados y además puedes indicar el ancho y alto de forma manual si es necesario.Una vez importado el reporte en Libertya, habría que ver si al ejecutar el informe y abrir el diálogo de impresión, el mismo respeta la configuración de hoja que has indicado en el jrxml. Dejo en tus manos esta prueba y luego nos comentas como te fue.
CarolinaC escribió:
Quote:Hola Foro.1) Mirando la nueva versión 09, encontré lo que creo es un nuevo campo en la pestaña Artículo de la ventana Artículos: Lugar de Retiro. Su dominio es TPV; Almacen/TPV y TPV.
Hay comportamiento de acuerdo al valor elegido? O es solo referencial?
Existe un comportamiento entorno a este campo el cual determina cuando se puede y cuando no vender un artículo en la ventana del TPV. A continuación detallo el comportamiento del TPV al agregar un artículo cuyo lugar de retiro está configurado como:
– Almacén: en este caso el TPV no permite agregar el artículo al pedido. Los artículos cuyo lugar de retiro es solo Almacén deben salir por la ventana de remitos de salida la cual es administrada por el perfil de Gestión de Almacenes.
– TPV/Almacén: aquí el TPV permite agregar el artículo al pedido y además, si el TPV está configurado para emitir remito, al agregar el artículo al pedido se mostrará que su retiro es en el mismo punto de ventana. De esta forma, el TPV incluye ese artículo en el remito que genera.
– TPV: solo se puede agregar el artículo al pedido si el TPV está configurado para generar el remito. Esta opción indica que el artículo debe ser retirado por línea de cajas, con lo cual si el TPV no va a generar el remito entonces el artículo no debe poder ser agregado al pedido. Esta opción debería ser utilizada si el TPV siempre genera el remito.Quote:2) Como se realiza la venta de combos y promociones en el TPV?Lo primero que hay que hacer es crear una Configuración de Descuento para la organización con la cual se está vendiendo, o una Configuración para la org. *. En el perfil de Adminstración se encuentra la ventana de Configuración de Descuentos, en la cual se debe indicar las prioridades de aplicación de descuentos a nivel de documento (EC o medios de pago) y a nivel de línea (EC, combos y promociones). Para el caso de Combos y Promociones, hay que indicar los mismos en las listas desplegables correspondientes, y en general suelen tener mayor prioridad los combos que las promociones.
Luego hay que configurar los combos y promociones propiamente dichos. También en el perfil de Administración está la ventana de Combo de Artículos y Promociones. En cada caso se ve que es posiible indicar si el descuento es “Al Precio” o “Bonificación”. Un descuento “Al precio” en realidad va a reducir el precio del artículo y en la impresión se va a imprimir este nuevo precio descontado (como si se hubiese reducido directamente en la tarifa), mientras que si es una “Bonificación” el precio será el original y luego se imprime una línea que descuenta el importe bonificado (similar a los tickets de supermercados).
Para los combos, hay que indicar los artículos incluídos en el mismo con sus cantidades y porcentajes de descuento para cada uno. Por ejemplo, para configurar un 2×1 en un artículo X, se debe crear una línea de combo en donde el artículo es X, la cantidad es 2 y el % de descuento es 50.
Para las promociones, simplemente se debe indicar cual es el esquema de descuento que se debe aplicar. Los esquemas de descuentos permiten configurar descuentos simples que son un porcentaje fijo aplicable a todos los artículos, o descuentos por cortes (ver pestaña de cortes), el cual permite por ejemplo configurar descuentos para ciertos días, subfamilias, familias, artículos y demás.
Una vez configurado todo esto, luego el TPV se encarga del resto. Cada vez que agregamos un artículo al pedido el TPV evaluará todos los Combos y Promociones cuyo estado sea Publicado, y en caso de que sea aplicable reducirá el precio del artículo según la promoción o combo aplicado. Además, se puede ver en la grilla del pedido TPV si se aplicó como descuento “Al Precio” o como “Bonificación”. Hay que tener en cuenta que los combos y promociones no son acumulables en ningún caso. Esto implica que si un artículo entra en un combo y también pertenece a una subfamilia que está en promoción, solo se aplicará el Combo o Promoción según la prioridad que se le haya dado en la Configuración de Descuentos que comenté al inicio. Por tal motivo es que, normalmente, primero se da prioridad a los combos y luego a las promos.
Por último, vale la aclaración de que el TPV está constantemente comprobando la aplicación de promos y combos, esto implica que si se elimina, modifica la cantidad o agrega un artículo al pedido el TPV recalculará todos los combos y promociones y mostrará de forma inmediata los precios según esas aplicaciones.
Espero te sea de utilidad esta información. Cualquier duda puntual que tengas no dudes en consultar.
Algunos comentarios sobre la implementación actual y las correcciones de Javier:
1) Correcto, lo más lógico es que ordene los pagos según su importe de mayor a menor y no de menor a mayor como lo está haciendo ahora.
2) Correcto para TPV, pero hay que tener en cuenta que en Libertya también se puede emitir facturas desde la ventana de Facturas de Cliente. Al completar una factura, se emite el comprobante fiscal y aquí no es tan válida la suposición que hace Javier. Cuando completamos la factura desde esta ventana, nunca va a tener pagos asociados dado que justamente la estamos completando. Es por eso que se tuvo en cuenta el caso (pagos = 0) en el cual se imprime lo que dice el PaymentRule de la factura, ya que, si al completar la factura desde la ventanas de facturas la misma tiene un PaymentRule “A Crédito”, entonces hay que indicar eso mismo en el ticket, y si tiene un PaymentRule “Efectivo” (recordar que aquí se crea la línea de caja automáticamente), el ticket debe imprimir “Efectivo” (cosa que con la solución de Javier seguiría imprimiendo el default del CF, que es normalmente “Crédito” o “Cuenta Corriente”). Aquí, con los cambios realizados también se produce una inconsistencia entre el documento en Libertya y el ticket/factura impresa, con lo cual hay que definir una solución diferente que se adapte a los dos casos.
Dado que es la Entidad Comercial Consumidor Final, podrías configurar la Forma de Pago de la misma como Efectivo en la ventana de Entidades Comerciales, pestaña de Cliente, campo “Forma de Pago”. Supongo que actualmente no tenés configurada la Forma de Pago para la EC, con lo cual el TPV está asignando por defecto A Crédito. Si realizas esa configuración no vas a tener problemas en facturar con la EC Consumidor Final.
La otra opción sería activarle la gestión de crédito a la EC Consumidor Fina, lo cual no tiene mucho sentido salvo que realmente quieras que así sea. Con respecto a la venta, no hay que preocuparse por este hecho ya que si el medio de cobro seleccionado es Efectivo, el pago se asentará en Efectivo y no A Crédito, es decir, por mas que aparezca ese mensaje el pago se estará registrando correctamente en Efectivo y no va a afectar el Saldo de Crédito de la EC.
Cintia: para que aparezca la EF en el TPV no alcanza con dar de alta solo la entidad financiera, tienes que además crear un Medio de Pago TPV (desde el perfil de Configuración de la Compañía) el cual tenga asociado la Entidad Financiera que has creado.
Los cierres de almacenes permiten tener mayor control sobre las operaciones que involucran movimientos de mercadería. Mediante este módulo, se puede realizar un control diario de las operaciones de un almacén, permitiendo crear solo documentos para una fecha determinada y obteniendo un detalle de documentos en borrador para dicha fecha, de modo que un usuario supervisor determine que realizar con ellos.
Para habilitar el Control de Cierres de Almacénes hay que hacerlo desde la ventana de Compañía, en la pestaña de Info de la Compañía. Una vez habilitado, cada vez que se quiera completar un documento que implique un movimiento de mercadería, se realizará un chequeo de los cierres de almacenes buscando si el almacén en cuestión está cerrado para la fecha del documento. De ser así, el movimiento de mercadería no se podrá completar.
La ventana de Cierres de Almacenes perbmite justamente cerrar un almacén para una determinada fecha. Al momento de realizar el cierre, se comprueba si hay remitos de salida en estado borrador para esa fecha. De haberlos, el cierre del almacén no podrá realizarse y se informará al operador cuales son esos remitos que están en estado Borrador. De esta forma, un supervisor deberá tratar estos documentos, completándolos o anulándolos para poder luego realizar el cierre de almacén.
Hola Javier:
Efectivamente el filtro es incorrecto. Investigando un poco el origen del mismo veo que ese filtro en realidad es el mismo que para un campo Payment en la pestaña de Línea de Boleta de Depósito (que tiene otra validación llamada “C_Paymento to BoletaDeposito”). Por algún error el código de esa última validación se ha “copiado” a la validación del campo Payment en la línea de extracto bancario (Validación “C_Payment not in BankStatement”).
Con lo cual, el código de la validación actual “C_Payment not in BankStatement” es totalmente erróneo y no amerita ni siquiera a una análisis del mismo. Me encargué de buscar en algunos backups el código original de la validación y ya lo he corregido para el próximo release.
A continuación copio el código original de esta validación:
Code:NOT EXISTS
(SELECT *
FROM C_BankStatementLine bsl
INNER JOIN C_BankStatement bs ON (bsl.C_BankStatement_ID=bs.C_BankStatement_ID)
WHERE bsl.C_Payment_ID=C_Payment.C_Payment_ID
AND bs.DocStatus<>‘VO’)
AND C_Payment.DocStatus IN (‘CO’,’CL’,’RE’)
AND C_Payment.PayAmt<>0 AND C_Payment.IsReconciled=’N’El tema ahora es analizar si este código es realmente correcto, o si podríamos mejorarlo. Pero eso ya es otro tema…
La verdad que es raro que el método esté definido en la interface pero no en la clase HasarFiscalPrinter. De hecho lo verifiqué y veo el método public void fiscalClose(String closeType) dentro de la clase HasarFiscalPrinter. También veo que fue agregado antes del release 10.03 con lo cual si estás usando esa versión debería estar.
En fin, dentro de ese método solo se usa el comando cmdDailyClose, con lo cual alcanza con agregarlo a la lista de comandos a verificar.
Saludos!
FrancoGran aporte Javier! Estuve haciendo pruebas y tal como lo mencionas logré reproducir el error. Como vos decís, se tienen que dar una serie de condiciones para que justo se produzca el caso que falla, y creo que por esa complejidad no haya sido detectado antes.
La solución? La misma que vos propusiste: agregar el incremento a payIdx cuando se cubre el total de una factura (rama del else).Code:} else {
//NO sobra nada del ultimo medio de pago, por lo tanto
//se debe pasar al próximo Medio de Pago
payIdx++; //Nunca “debería” generar un acceso fuera de indice sobre el vector de medios de pagos…
sobraDelPago = null;
}En principio no se debería producir un acceso fuera de índice ya que se asume que la suma de los importes de los pagos es igual a la suma de los importes de las facturas, con lo cual, en la próxima iteración si aún queda un monto por cubrir de alguna factura también habrá un pago disponible en el arreglo para cubrir esa factura. De todos modos, habría que hacer pruebas con montos que no sean enteros, que tengan varios decimales porque ahí no me queda claro si la comparación puede llegar a fallar y en ese caso intentar acceder al arreglo de pagos cuando en realidad ya se han acabado.
Este bug estará corregido obviamente en el próximo release de Libertya.
Muchas gracias por tu aporte Javier
Saludos
Franco
