[9.0][account_withholding] ¿Por qué no mantener el modelo account.voucher.withholding?

[ivantodorovich]

Veo que ha sido deprecado para ser implementado dentro del mismo account.payment.

Esta implementación me hace un poco de ruido, ya que creo que presenta algunas desventajas:

• Conceptualmente son cosas distintas.
• Las retenciones tienen un workflow distinto (en la realidad), que podría potencialmente ser implementado en el modelo. Ej: Todas las retenciones aplicadas deben ser rendidas ante algún tipo de organismo, se podrían implementar estados y wizards para registrar esto. (De hecho, es algo que venía pensando como extensión al wizard de exportación para SICORE)
• A la hora de emitir retenciones, deben ser impresas con un reporte que es específico para estas. Este reporte no tiene ningún sentido en otro tipo de account.payment.

¿Por que no mantenerlo? ¿Tal vez con otro nombre, considerando que account.voucher ya no existe: account.withholding?

Supongo que la decisión de eliminarlo viene de la mano con que cada account.payment sólo debe contener 1:1 retención, y no 1:n como era antes, y no se quiere hacer uso de un campo m2o ya que eso reduciría la usabilidad.

Sin embargo -y esto lo digo desde la ignorancia de nunca haber experimentado con esto antes- ¿no convendría hacer uso de las herencias polimórficas, tanto para este caso como para el de los cheques (siendo ambos casos similares)?

[jjscarafia]

En realidad la idea original fue tratar de eliminar los modelos account.check y tmb account.voucher.withholding. La idea era que directamente los apuntes contables, de alguna manera, sean el cheque en sí. Para cheques lo terminé viendo complicado por toda la funcionalidad que requería y no quería recargar tanto el modelo account.move.line.

Para las retenciones nos pareció que podía ir bastante más fácil ya que las operaciones con una retención son mucho más sencillas. De esta manera sería igual que las percepciones, son el apunte contable en si.

Por las dudas aclaro que la idea, es que "account.payment" en sí no sea la retención ni el cheque, son un asistente para generarlo y podría no existir (lo cual me hace pensar que, por ejemplo, podemos ocultar los campos de cheques en account.payment cuando se confirma y se genera el cheque y dejar solamente el m2o al cheque)

La rendición de las retenciones las haríamos con account.tax.settlement migrado y mejorado, de hecho hoy en el consejo lo hacemos así. Podrás ver que dicho módulo agrega de manera genérica a los apuntes contables ciertos campos que indican si el apunte se liquidó y se pagó o no. Sirve tmb para iva y demás.

Te cierra más ahora con esta data? Si te parece avanzamos con otras cosas, migro el tax.settlement y vamos viendo.

Respecto alas herencias polimórficas, imagino que te referías a heredar de account.payment, bueno, un poco por lo dicho acá es que preferimos no hacerlo

[ivantodorovich]

Mmm.. supongo que cuando lo vea funcionando, me cerrará mejor.