Al añadir cheques falta hacer obligatorios los campos fecha de emision y fecha de vencimiento

[ckasimis]

Son datos obligatorios para un cheque por lo cual hay que hacerlos required=true

[sebastiken]

@ckasimis buenas, se dejó sin el required porque comúnmente los cheques se emiten con la misma fecha del pago. Por lo tanto, al usuario le es más rápida la carga (algo muy importante para el usuario final). Como bien dice @ivantodorovich los cheques no diferidos o al día, no requieren la carga de la Fecha de Pago. Para el caso de cheques diferidos, no estaría mal hacerlo required en la vista, teniendo en cuenta el valor del campo Tipo de Cheque. Si querés, @ckasimis podés abrir un PR para esto, sino avisanos y si otros están de acuerdo con esta definición, lo hacemos.

cc @ssaid @kloss17 @gabrielo77

Gracias por el aporte.

[gabrielo77]

@sebastiken vos decís hacer siempre requerida la Fecha de Emisión y cuando es un cheque diferido hacer la Fecha de Pago también? O sólo para la Fecha de Pago para el cheque diferido?

[ivantodorovich]

Yo trataría de simplificar el trabajo del usuario lo más posible. Ya que, en definitiva, esa es la finalidad de un sistema de gestión.

Con esa idea en mente, me haría algunas preguntas, y propondría otras mejoras:

Antes, una aclaración: no soy un usuario frecuente de este módulo, ya que nuestra empresa trabaja con la localización de ingadhoc, así que disculpen si en algunas cosas "meo fuera del tarro", o que tampoco haga una PR. Sin embargo, con el espíritu de perfeccionar el sistema propongo poner en discusión esto.. y de más está decir que me gustaría ver algún día a todos los programadores argentinos combinando fuerzas en una única localización.

Campo Tipo de Cheque

¿Cuál es el sentido de registrar si un cheque es diferido o no? Sería más fácil para el usuario no tener que preocuparse por este campo.

Si no es indispensable, dejaría el campo, pero cambiaría su valor por defecto para que sea cheques diferidos (ya que es el más utilizado, casi en la mayoría de los casos) Esto permitiría a un usuario avanzado ocultar el campo en la vista, para las empresas a los que no les interesa registrar esto, y prefieren aliviar el trabajo de sus empleados.

Campo Fecha de Pago

Usabilidad: Utilizaría la siguiente lógica (en las vistas):

• Requerido y Visible si el tipo de cheque es diferido, (valor por defecto)
• No requerido y Oculto si el tipo de cheque es al día.

Comportamiento Interno: Haría que el módulo se encargue siempre de completar este campo, sin importar si el cheque es diferido o al día, usando la siguiente lógica:

• Si el valor del campo no está presente, completarlo discretamente con el mismo valor que Fecha de Emisión.

Esto permitiría simplificar código como este:

if check.type in 'common':
                aux_payment_date = check.issue_date
            elif check.payment_date:
                aux_payment_date = check.payment_date
            else:
                aux_payment_date = check.deposit_date

Ya que cualquier módulo dependiente, o reportes del usuario, podrían confiar siempre en check.payment_date. El código anterior se simplificaría a algo así:

aux_payment_date = check.payment_date or check.deposit_date

Código de Bancos, Sucursal y Código Postal

La forma más rapida de ingresar un cheque en un sistema de gestión es leyendo el recuadro que se encuentra en la parte superior derecha del cheque:

Donde se puede leer lo siguiente:

CodBanco (3 dígitos) - CodSucursal (3 dígitos) - CodPostal (4 dígitos)
Número de Cheque
Y otro número que desconozco

En la imágen que subí:

285 es el Código del Banco Macro
745 es el Código de la Sucursal del Banco que emitió la chequera
2156 es el Código Postal
58727807 es el Número de Cheque

Un dato interesante: La combinación de CodBanco, CodSucursal + Número de Cheque garantiza que no existan cheques duplicados.

Es decir, en la práctica, pueden existir 2 cheques con el mismo número (lo cual es raro, pero nos ha pasado). Incluso pueden existir 2 cheques con el mismo número y código de banco (lo cual es muy raro), pero nunca(*) 2 cheques con el mismo número, código de banco y código de sucursal.

(*) La verdad, no se si es una restricción real, o simplemente estadística. De todas formas, en mi experiencia, es fiable.

Con eso en mente:

• El campo Banco debería solicitarse antes que el número de cheque, y debería poder ser buscado por su "Código de Banco", no sólo por su nombre.
• El campo Sucursal debería solicitarse y ser requerido. Debería estar ubicado inmediatamente después que el campo banco, antes del número de cheque. Otro dato curioso: La sucursal puede ser 000, y es válida.
• El campo Código Postal podría estar presente, opcional. Es útil cuando se quiere reportar, por ejemplo, las provincias más riesgosas en términos financieros. Un dato curioso basado en nuestra experiencia es que, en esta época, la provincias de Tucumán, Salta y alrededores tienen un porcentaje mucho más alto de rechazo que el resto. Al menos en nuestro rubro, esto es así, y saberlo nos permite organizar mejor nuestras finanzas.
• El campo Monto debería estar ubicado posterior a las fechas de Emisión y Pago, ya que ese es el orden visual que tiene un cheque, físicamente. Lo renombraría a Importe, por consistencia con el resto de los términos del sistema.
• Agregaría una regla de validación impidiendo la creación de cheques que compartan Banco, Sucursal y Número. Ya que casi seguramente se trata de un error de tipeo o de un intento de ingresar un cheque ya registrado.

De esa manera se puede ingresar un cheque navegando por los campos con TAB y usando casi únicamente el teclado numérico. Se agiliza mucho el trabajo administrativo.