ingadhoc / account-payment

GNU Affero General Public License v3.0
56 stars 106 forks source link

Dependencia de account_voucher_withholding_automatic al modulo account_voucher_double_validation #16

Closed ivantodorovich closed 7 years ago

ivantodorovich commented 7 years ago

Hola @jjscarafia

Estoy tratando de identificar la necesidad de esta dependencia para el funcionamiento de account_voucher_withholding_automatic, para ver si es posible removerla.

Sin embargo, no puedo encontrarla.. ya que, en teoría, este módulo podría deducir toda la información que necesita sin depender del otro.

Desde el punto de vista de la interacción con el usuario, tampoco sería necesario.. ya que podría agregarse un paso previo "Calcular retenciones" al de validación. (Similar como se hace con el "Correr operaciones" de los planes de facturación)

¿Para qué es necesaria?

Si pudiera entenderlo, tal vez podría hacer una PR con las modificaciones necesarias para remover esta dependencia.

jjscarafia commented 7 years ago

Ivan, justamente se aprovechó el double validation para definir ese paso previo, ese módulo era el único que fijaba las imputaciones para que no se cambien y, agregadas retenciones o cualquier cosa, no se cambien las imputaciones (ya que el cálculo de las retenciones requiere definir primero las imputaciones)

En la v9 estamos trabajando en un esquema más simple. Si querés hacer un PR adelante, igualmente estamos muy enfocados en la v9 y tratando de evitar cambios en la v8.

Saludos, Juan

ivantodorovich commented 7 years ago

Ah, ok entonces.

Si en la v9 se va a hacer totalmente distinto, supongo que no tiene sentido que invierta demasiado tiempo en mejorarlo.

Mi principal inquietud es evitar solicitarle al usuario el campo "Importe de Adelanto", ya que resulta muy molesto y podría ser calculado automáticamente comparando el "Importe" con el importe total de apuntes.

Pensando en un cambio menor.. ¿Estarías de acuerdo en una PR al modulo double_validation que transforme a ese campo en uno calculado y se lo muestre al usuario con fines meramente informativos, pero sin posibilidad de editarlo?

jjscarafia commented 7 years ago

Entiendo la necesidad, el tema es que ese campo se usa también para definir importes que no van contra facturas. Por ej. $1000 a cuenta o cosas por el estilo, varios clientes lo usan y mucho (y no solo para ajustar diferencias)

De hecho estuvimos hablando con el contador sobre la v9 y nos recomendó mucho no permitir los ajustes ya que no es algo legal ni correcto en sí. Si se ajusta entonces, por ejemplo, hacerlo a nivel caja

ivantodorovich commented 7 years ago

Nosotros también hacemos pagos a cuenta. Mi inquietud no es únicamente para ajustar diferencias. Con el cambio que propongo, por ejemplo, para asentar un pago a cuenta de $1000 habría que hacer lo siguiente:

  1. Ingresar en el campo Importe $ 1000.
  2. No seleccionar ningún apunte contable.

El campo calculado "Adelanto" sería igual a: Importe - Importe Total de Apuntes, por lo tanto quedaría bien registrado como pago a cuenta.

Esto funcionaría así tanto para adelantos totales, parciales o incluso si no hay adelantos. El usuario sólo debe ingresar el monto a pagar y asegurarse de elegir los apuntes contables correspondientes.

La diferencia con el funcionamiento actual, es que el usuario no debe preocuparse por ingresar explicitamente el mondo que va a adelantar. Sólo debe asegurarse de elegir bien los apuntes contables.. algo que ya es necesario hacerlo siempre, más allá de si es adelanto o no.

Esta propuesta es independiente de si es aconsejable o no conciliar el las diferencias contra una cuenta contable de "Redondeos", ya que esto no cambiaría nada en ese aspecto.