Incorporar Clase comprobante

[GoogleCodeExporter]

Realizar una clase comprobante
que uno pueda cargar
y cuando termine de cargarse
se use comprobante.imprimir()

Ventajas. 
-Fácil implementación
-Validación en la misma clase
-Fácil de incorporar nuevas caracteristicas.

Desventajas:
-Especificar marca y modelo de impresoras para imprimir.

Original issue reported on code.google.com by dmlistap...@gmail.com on 24 Aug 2012 at 6:28

[GoogleCodeExporter]

Interesante.
Aunque le veo ciertas desventajas:
1. Duplicación del modelo. Yo almaceno en mi base de datos comprobantes, así 
que tendría que ir copiando dato por dato al nuevo comprobante. 
2. Se pierde flexibilidad con la api de la biblioteca. Pej, llarmar ciertas 
funciones, como status, o pagos parciales. Además si la función .Imprimir() 
imprime todos los items de golpe, esto puede bloquear la máquina y ser 
ineficiente. La opción sería implementar la OPCION de ir imprimiendo los 
items a medida que se agregan.
3. Habría que tener la opción para asignar la impresora al crear el 
comprobante, algo que se ve un poco feo nomas.
4. La api tiene que estar super pulida para que no haya codigo de "If modelo == 
" en la clase comprobante.
5. La clase Comprobante debería estar bien diseñada para ser lo más 
eficiente y resiliente posible.
6. Hay que tener mucho cuidado con el seteo de propiedades, si el Comprobante 
está ligado a la interfaz es normal que el usuario cambie varias veces los 
valores o incluso empiece algo y no lo termine... Pej, si el usuario cambia el 
tipo de comprobante, la clase Comprobante podría querer abrir 2 comprobantes o 
en el peor de los casos intentar cambiar el comprobante. En el mejor de los 
casos abre un comprobante y lo cierra y abre otro..

Aaaaaaaaaaaauuuunqueeeee:
Si se crea esta clase en un modulo _aparte_* se puede usar en programas que no 
requieran mayor complicación. Y hacer que la biblioteca sea mucho más fácil 
de usar, además de ser más sólida porque la clase Componente se encargaría 
de controlar el estado correcto y el orden de las operaciones.
*O sea que no sea imprescindible usar la clase Comprobante, sino que sea algo 
opcional.

Así que +1.
En mi app yo estoy haciendo algo así, pero por la base de datos que estoy 
usando no puedo meter la lógica del comprobante en la clase que uso, sino que 
lo hice al revéz, tengo una clase impresora que se le pasa un comprobante por 
parámetro.

Original comment by jerobarr...@gmail.com on 24 Aug 2012 at 9:40

[GoogleCodeExporter]

1- Al imprimirlo (con el sistema actual) si o si tendrías que sacar dato por 
dato  (así que es lo mismo)
2 - Si se hace una clase FiscalPrinter (o lo que sea) que ténga métodos, la 
cosa se facilita a 
  if FiscalPrinter.readytoprint:
             comprobante.Imprimir()

3- Si, es lo que me da vueltas todavía
6- Se validaría todos los datos, el usuario que haga lo que quiera, no habría 
problemas en que no lo termine (porque no se envía nada al controlador hasta 
que no esté completo). A parte se supone que "el usuario" sería el 
programador no el usuario final.

Otra ventaja que (en mi versión .NET) encontré es que la clase Comprobante 
podría asumir automáticamente el Nro de comprobante impreso. Así eliminé 
discordancias, porque siempre coincide la base de datos con el nro de 
comprobante real.

-----------------
if comprobante.impreso:
          para_la_base = comprobante.nro_comprobante

Original comment by dmlistap...@gmail.com on 24 Aug 2012 at 9:51

[GoogleCodeExporter]

6 - Por usuario me refiero al usuario final. Ciertas veces suelen cambiar el 
flujo normal de una aplicación. Es Cierto, aunque se asume que estás 
imprimiendo solo después de haber "cerrado" el comprobante (en la UI). Las 
impresoras no son muy rápidas y si imprimís todo junto tu programa queda 
bloqueado hasta que la impresora termine (a menos que uses (bien) threads) (lo 
que pasaba cuando imprimias algo por LPT en windows 95). 
Aunque una opción sería poner en la clase la alternativa de un modo "live" en 
el que se puedan ir imprimiendo los items a medida que se van cargando; que es 
como funcionan las impresoras, por ejemplo, en los supermercados. 
Obvio en ese caso complica bastante el código de la clase (son dos 
comportamientos diferentes en la misma clase). Personalmente, para aprovechar 
la impresión "en caliente" (live) yo crearía una clase aparte (quizás que 
hereden de alguna en común), ComprobanteLive, que no permita pej, cambiar de 
cliente o tipo de comprobante.

Por lo del número, yo ahora tomo el número que devuelve cerrarComprobante, y 
me resulta bastante útil.. Me gustaría un comando para conocer el último 
número impreso (se que es un status) pero no he tenido tiempo de leer bien el 
código ni averiguar cual es el comando exacto (aunque tengo el log de como 
hacerlo)

Original comment by jerobarr...@gmail.com on 24 Aug 2012 at 11:08

[GoogleCodeExporter]

Si, estamos de acuerdo en lo de la velocidad de impresión, yo le agregué un 
delay después del send para evitar "atascos" de buffer, no se me ocurrió otra 
manera de hacerlo.
Con lo de cambiar comprobante no habría problema. Porque la idea es 
estandarizar el envío de comprobantes, por ejemplo... 
1º - Se envía todos los items con IVA (o sin)
2º - El método imprimir discriminaría cómo le enviaría los datos al 
controlador.
3º - Si después de haber creado el comprobante, lo cambia de tipo (obvio de A 
a B o viceversa, no de DF a DNF o cosas así) no habría inconveniente porque 
.imprimir() lo enviaría de la manera correcta y sólo si cumple la validación.
4º - El nro de comprobante se obtiene de status (no recuerdo en hasar). Me 
parece que no hay otra

Original comment by dmlistap...@gmail.com on 27 Aug 2012 at 10:19