Re:Re:FiscalDocumentPrint 10.09

Inicio Foros Foro principal Desarrolladores FiscalDocumentPrint 10.09 Re:Re:FiscalDocumentPrint 10.09

#35095
Javier AderJavier Ader
Participante

Buenas Franco. Más allá de lo que decís, sigo pensando que es incorrecto. Los TotalTenders (emisiones de pagos), son para registrar pagos reales, y típicamente van precedidos de un leyenda “Recibos:” (y si uno una factura por 100$ lee “recibimos: efectivo 100”, se entiende que esta saldada, cuando esto no es necesariamente el caso con el código actual incluso cuando no se generaran automáticamente lineas de cajas). La PaymentRule pienso que se deberia usar para registrar solo la forma de pagos requeridas para pagar lo que falta saldar, no se deberia tomar nunca como un pago por el simple hecho de que tal pago no se realizo. Esto es, la PaymentRule es solo para especificar como el cliente deberia pagar lo que falta (“pagame lo que resta en efectivo; pagame lo que resta a 30 dias, etc”).

Ahora bien, si no se quiere perder esta información (que en realidad solo tendria sentido para aquellas facturas no saldadas completamente) se podria imprimir como texto fiscal antes de los items (las strings de observaciones en Document; yo actualmente estoy usando estas lineas, pero para otros datos).
Ahora bien, en las facturas no-TPV, seteadas para “generar un linea caja”, no lo probe pero deberían ser impresas y tratadas exactamente igual que facturas generadas desde el TPV y totalmente saldadas en efectivo. Si esto no ocurre (creo que no, ya que las tablas que son afectadas desde el TPV y desde la “completacion” de facturas, son distintas; en particular, creo que la ultima NO genera una AllocationLine y por lo tanto FiscalDocumentPrint no va “a ver” ningún pago), se deberia tratar como un caso especial (o modificar el codigo de MInovice.completeIt para que sea consistente con la lógica del TPV). Las facturas no-TPV, con reglas de pago “efetivo” pero sin generación automatica de la linea de caja, se deberian tratar como una factura sin ningun pago real (y como dije, si no se quiere perder la información del “acuerdo de pago”, se envia como un texto fiscal antes de los items).

En conclusión, la forma en que pienso que deberia tratarse todos estos casos serian:
1) si FiscalDocumentPrint, encuentra la menos un pago real, actua tal como hasta ahora junto con la modificación del codigo del driver para tratar correctamente “el último pago” (esto igual debería darse solo en casos bastante raros).
2) si FiscalDocumentPrint no encuentra ningun pago
2.1) si “descubre” que fue creada con “generar linea de caja”, genera un solo pago por el total utilzando la misma leyenda que usaria en 1) para pagos en efectivo (esto de paso, logra una consistencia que ahora no existe).
2.2) si no, no emite ningún pago real; a lo sumo setea la regla de pago como una observación fiscal.

En el caso 1 entran todas las facturas generadas desde el TPV con al menos un pago “real” (cualquiera de los medios de pagos que no sean “A crédito”). En el caso 2.1 entrarían solo aquellas facturas no-TPV que fueron creadas con “generar linea de caja”; en el caso 2.2 entrarían aquellas facturas TPV cuyo único medio de pago es “A Crédito”, las facturas no-TPV cuya regla de pago no era efectivo y las facturas no-TPV cuyo medio de pago sí era efectivo, pero no generaron una linea de caja por el total. En todos los casos, la regla de pago nunca va a parar a un TotalTender.

En cuanto a cuando imprimir la regla de pago en las observaciones, supongo que se podría simplificar e imprimirse siempre (el único problema potencial acá es que estas lineas son escasas; existen solo 4 en la mayoría de los documentos; de cualquier manera el código actual no esta haciendo uso de ninguna de ellas; en un versión propia se están imprimiendo por ej los números de pedidos y código del vendedor, en estos caso ya jode un poco mas darle un “linea” para imprimir este dato).

PD : tal vez, no haya que imprimir la regla de pagos como observación, si no, los términos de pagos…