tryton-ar / payment_collect Goto Github PK

Se ha creado un modelo nuevo llamado Payment Method (Forma de Pago) y este debe ser el utilizado para pagar las facturas. Nosotros no utilizamos el modulo de account_voucher_ar, sino que llamamos a los metodos de pago de tryton de account_invoice.

Mas información:
https://docs.tryton.org/projects/modules-account-invoice/en/latest/#payment-method

Desde la versión 5.0 en tryton desarrollaron la posibilidad de procesar tareas asincrónicamente. https://docs.tryton.org/projects/server/en/latest/topics/task_queue.html

La idea es reemplazar el desarrollo que se hizo para ejecutar las tareas de forma asincrónica usando tareas programadas (cron) por las Task Queue de Tryton core.

Luego de aplicar los cambios para que el metodo post llame al super() en account_invoice_ar, éste llama a print_invoice. mas info: tryton-ar/account_invoice_ar#123

Además en consonancia con https://bugs.tryton.org/issue8462 y aplicando ese parche la llamada a print_invoice pasa a estar en background y no tiene sentido que se llame a publish_invoices.

Chequear si ya hubo una factura pagada cuando se ejecutan los cobros. Si ya lo hizo, informar y generarle un crédito a favor.

Actualmente, si la factura fue pagada previamente a través de voucher, cuando pasa el retorno de cobranzas, no hace nada. Entonces, queda "invisibilizado" un pago a través de la cobranza por payment collect.

• Genrarle crédito a favor a la factura que ya esta pagada.
• Agregar campo many2many para informar facturas a las que se les generó un crédito a favor. De esa manera, no queda invisibilizada la generación del crédito para dichos clientes.

De esa manera, se puede buscar, o distinguir rápidamente el asiento de pago de una factura.

When you have too many invoices the paying process takes a long time. Implementing cron to process the invoices makes possible to schedule the job

Revisar porque cuando una suscripcion no tiene paymode asociado, igualmente cuando se crea la factura se le agrega el paymode por default de la party.

Con algunas integraciones directamente procesamos el archivo ya con el debito creado y lo que se requiere es que generemos la facturación en base al archivo a procesar.

Es por ello, que debemos:

• Crear al cliente si no existe.
• Crear la factura. (agregar en el campo reference un identificador de movimiento). De esa manera nos aseguramos que no volveremos a crear facturas con movimientos ya debitados. Hay muchas posibilidades de que el archivo que nos procesen aparezcan debitos ya realizados.

El proceso del collect debería de continuar como siempre, contabilizar -> pagar -> publicar.