El 02/08/16 a les 20:10, Jordi Esteve (Zikzakmedia) ha escrit:
El 01/08/16 a les 11:38, Sergi Almacellas Abellana ha escrit:
El 30/07/16 a les 20:11, Jordi Esteve (Zikzakmedia) ha escrit:
No me parece bien. Como te he comentado, es frecuente tener tipos de
pago que sólo fueran para cobrar o para pagar. Por ejemplo:
Datàfono (lector de tarjetas de crédito/débito). Sólo suele ser para
cobrar.
Cheque. Muchas empresas sólo los usan para cobrar.
Pagaré. Muchas empresas sólo los usan para pagar.
A mi entender, ambos tres ejemplos se pueden usar tanto para cobrar
cómo para pagar.
Es más: Pagar es una acción recíproca, por lo que al pagar a alguien
mediante un tipo de pago habrá otra persona que realizará la acción de
cobrar mediante el mismo tipo de pago.
De todos modos, entiendo que te refieres a que la propia empresa no
usa de forma habitual el tipo de pago para cobrar o bien pagar, y para
expresar los tipos de pago utilizado ya lo definimos cómo propiedades
de los terceros, por lo que no veo problema en tener definidos tipos
de pago a cobrar o a pagar que no se utilicen de forma habitual.
Exacto, son acciones recíprocas, pero en una empresa determinada un tipo
de pago sólo se usa de una manera (sólo para cobrar o sólo para pagar) o
en algunos casos de las dos.
Es un problema el disponer como tipo de pago uno que se sabe seguro que
no se va a usar, podría ser fuente de errores por parte de los usuarios.
Nadie impide crear un tipo de pago que no se va a usar o con el tipo
incorrecto, por lo que los errores por parte de los usuarios pueden ser
los mismos.
Alguien te diria: "El usuario debe ser responsable de saber lo que esta
poniendo" :P
Por eso, para evitar usar tipos de pagos que no tiene sentido en una
determinada empresa, se diseño tal como está: poder limitar si un pago
se usa sólo para pagar o cobrar.
Por lo que estamos obligando a todos los demás a tener la información
duplicada. Además, si alguien cree que es de vital importancia definir
esta restricción se puede implementar su propio módulo con sus
restricciones de dominio, que seguramente serán mucho mas personalizadas
y potentes.
Si quieres evitar "duplicidades en los tipos de pago", se podría tener 3
clases de pago: A pagar, A cobrar y Ambos. En los dos primeros sólo
pediría como se usa la cuenta bancaria una sola vez, pero en Ambos
pediría como se usa la cuenta bancaria para pagar y para cobrar. Pero
personalmente no le veo que sea una mejora hacerlo así.
Este paso intermedio también es una opción, aunque a mi entender es
mucho mas simple quitar el tipo y que todos sean de ambos. Además esto
es mucho mas acorde con todo el diseño de tryton. Si te fijas en lo
siguientes modelos:
- Plazos de pago
- Diarios de pago
No existe ninguna clase para poder filtrar ninguno de los dos modelos,
por lo que los dos se pueden usar indistintamente para ambas cosas, por
lo que solo por coherencia con los otros maestros, los tipos de pago
deberían funcionar de la misma forma.
A parte veo una mejora en todo ello: Eliminar código y restricciones,
con lo que nos evitamos que este dominio [1] o este [2] nos obligue a
eliminar el tipo de pago al generar las facturas cuando las cantidades
son negativas.
Además podremos utilizar el mismo tipo de pago original al generar una
devolución de una factura, ya que actualmente nos vemos obligados a
poner el tipo de pago en blanco para la devoluciones ya que sino nos
salta la validación del dominio.
[1]
https://bitbucket.org/trytonspain/trytond-sale_payment_type/src/34383b6f1f79cfa8f07ffac72ea5b0a1210b3977/sale.py?fileviewer=file-view-default#sale.py-31
[2]
https://bitbucket.org/trytonspain/trytond-purchase_payment_type/src/851d26258c449e4fe04afe53de2ba4f29d68f235/purchase.py?fileviewer=file-view-default#purchase.py-34
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
