- Este debate está vacío.
-
Entradas
-
Me he topado con otro problema, no me marca el cambio correcto con lo que me paga el cliente y el vuelto que tengo que darle en la factura. Eje, si la compra es de $11.90 y el cliente me paga con 20 en el ticket, donde dice “Recibi(mos):” me dice $11.90 y en “CAMBIO” $0.00
Por las dudas tengo una controladora fiscal P441F y estoy utilizando el driver en Libertya de la P715F
Adjunto imágenes:
[attachment:1]C:fakepathvuelto en ticket.jpg[/attachment]
[attachment=108]photo1.JPG[/attachment]
Si… es otra limitación de Libertya con la que me encontré en el pasado (lo que si, no recuerdo si encontré una solución; había pensado en alguna modificaciones, una era un pequeño hack, otra era mas de núcleo…. no recuerdo si implemente alguna de las dos, despues busco un poco….). El tema es que Libertya, aun cuando el TPV te permite “pagar” de más, no registra los vueltos (los pagos SIEMPRE igualan el monto a pagar total); al momento de la impresión fiscal se buscan estos pagos asociados a la factura, que nunca generan vuelto (salvo pequeños errores de redondeo, siempre te va generar “CAMBIO 0” en el tique).
Si mal no recuerdo, si miras la linea de caja que te genera un pago en efectivo con vuelto desde el TPV vas a ver que te registra el monto que requerirías para saldar la factura sin vuelto (esto es, no te registra el monto real que te pagan, si no el necesario para saldar la factura).
Realmente no entiendo porque el TPV no genera ese pago en efectivo por el monto real; tal vez sea una limitación general : los pagos sumados de una factura no pueden superar el monto de la misma.
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.
Que tal Franco. Si, seguro que se tiene que internamente imputar 60; yo habia pensado que tal vez se podría modelar el vuelto haciendo una entrada de caja por 100 y una de salida por 40; que también conceptualmente correcto, pero bueno, quedaría registrado como un pago “negativo” que por otras cosas que vengo mirando me parece que generaria más problemas…
El campo de la factura que decis tiene sentido, pero me preguntaba si el campo WriteOffAmt de las lineas de alocación no tienen la idea de “vuelto”; siguiendo tu ejemplo si se generaría una linea de alocación con
Ammount : 100
WriteOffAmt: -40
Asociada a una linea de caja por 60, creo que se “solucionaria” (obviamente la logica de impresión fiscal debería tener en cuenta esto).
La otra sería usar algún campo de la linea de caja, me da la sensación que debería tener alguna forma de especificar el “monto real” o el “vuelto” (ahí también hay un campo “WriteOffAmt”, pero ademas otro, que no se que idea tendrá: “WhiteoffAmt”; después miro si en algún lado se hace uso de este campo)
- Debes estar registrado para responder a este debate.
