openerp-community team mailing list archive

[Pedro Manuel Baeza Romero <pedro.baeza@xxxxxxxxx>]

Hi, Markus,

What Eric exposes is the reason why I didn't change the workflow.

About reconcilements, you don't have to take care of them or keep them,
because you always get the date trace with the account moves, so the
easiest operation is to delete old reconcilement, and make another one with
all the account moves, and the balance will be correct. In this way, you
can pay, return, pay again, return again, etc, with the same method, having
always a correct invoice state managed by reconcile object.

Regards.


2014-07-10 11:17 GMT+02:00 Markus Schneider <markus.schneider@xxxxxxxxxx>:

> Hi,
>
> thank you Eric for the infos of changing workflow.
>
> Now i m looking in the details. What i don't want is to delete the
> reconsile. Just want to create a reverse account.move. I found the
> module "account_reversal" and thinking to use this instead of copy the
> function. But there the account.move will be validated and maybe we need
> the change amount than it easy to adapt this one. Always not easy.
>
> Kind Regards
>
> Markus
>
> On 09.07.2014 10:08, Markus Schneider wrote:
> > Hi Pedro,
> >
> > thank you for sharing. I have a first check of the module and i like the
> > solution.
> >
> > I think of the following steps are need:
> >
> > * ported to OpenERP 7
> > * removing wizard "account_payment_order" that the module is not depend
> > on "account_payment_extension" any more (can be separate module)
> > * removing wizard "payment_order_return_import_c19_wizard" no need (can
> > be separate module)
> > * "payment_returned" as boolean on account.invoice is the simplest
> > solution, the final goal maybe to modified workflow (i need to check the
> > details)
> >
> > I will spend some time on thinking and then start working on that and
> > share if i have some working solution ;)
> >
> > Kind Regards
> >
> > On 08.07.2014 19:34, Pedro Manuel Baeza Romero wrote:
> >> Hi, Markus,
> >>
> >> I adapted some time ago a module that was made by another company a
> >> concept more or less like your requirements, but have three problems:
> >>
> >>   * Module is for 6.1, though I think you won't have too much troubles
> >>     to port it to 7.0/8.0.
> >>   * Modularity: code for importing a specific spanish file format is
> >>     mixed in the module, because the budget was very restrictive and it
> >>     was not possible to split it.
> >>   * And the main problem is that the original approach takes the invoice
> >>     as the base for the payment return, instead of the account move
> >>     lines, so it has problems with invoices with more than one payment
> >>     terms. This is much more difficult to change, and I wasn't able to
> >>     do it also in the budget I had.
> >>
> >> If you work a little in this, this can be an excellent OCA module. Let
> >> me know if you have any doubt.
> >>
> >> Regards.
> >>
> >>
> >>
> >> 2014-07-08 17:55 GMT+02:00 Markus Schneider <
> markus.schneider@xxxxxxxxxx
> >> <mailto:markus.schneider@xxxxxxxxxx>>:
> >>
> >>     Hi community,
> >>
> >>     My situation:
> >>     A customer has a order paying with a external payment gateway. We
> >>     generating a invoice and we see the money on our bank account we
> >>     reconcile the invoice as paid. Everything fine.
> >>
> >>     The problem:
> >>     Now it is possible that the customer can go to his bank and return
> his
> >>     money. In this case, we want to add a new account.move and link it
> to
> >>     the existing invoice and set them back to unpaid. (Reconsile it
> later if
> >>     he pay with a other payment method or send him payment reminder and
> all
> >>     the payment follow-up stuff).
> >>
> >>     Hint:
> >>     We don't want to modified the existing account.move and avoid
> cancel in
> >>     accounting.
> >>
> >>     Question:
> >>     Has someone implement a module doing this or something similar?
> >>
> >>     Kind Regards
> >>
> >>     Markus
> >>
> >>     --
> >>     Dipl.-Comp.-Math. Markus Schneider
> >>     Softwareentwickler
> >>
> >>     initOS GmbH & Co. KG
> >>     An der Eisenbahn 1
> >>     21224 Rosengarten
> >>
> >>     Mobil:   +49 (0)172 2303699 <tel:%2B49%20%280%29172%202303699>
> >>     Phone:   +49 (0)4105 5615613 <tel:%2B49%20%280%294105%205615613>
> >>     Fax:     +49 (0)4105 5615610 <tel:%2B49%20%280%294105%205615610>
> >>
> >>     Email:   markus.schneider@xxxxxxxxxx
> >>     <mailto:markus.schneider@xxxxxxxxxx>
> >>     Web:     http://www.initos.com
> >>
> >>     Geschäftsführung:
> >>     Dipl. Wirt.-Inf. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
> >>     Haftende Gesellschafterin: initOS Verwaltungs GmbH
> >>
> >>     Sitz der Gesellschaft: Rosengarten – Klecken
> >>     Amtsgericht Tostedt, HRA 201840
> >>     USt-IdNr: DE 275698169
> >>     Steuer-Nr: 15/205/21402
> >>
> >>     _______________________________________________
> >>     Mailing list: https://launchpad.net/~openerp-community
> >>     Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> >>     <mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>
> >>     Unsubscribe : https://launchpad.net/~openerp-community
> >>     More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >
>
> --
> Dipl.-Comp.-Math. Markus Schneider
> Softwareentwickler
>
> initOS GmbH & Co. KG
> An der Eisenbahn 1
> 21224 Rosengarten
>
> Mobil:   +49 (0)172 2303699
> Phone:   +49 (0)4105 5615613
> Fax:     +49 (0)4105 5615610
>
> Email:   markus.schneider@xxxxxxxxxx
> Web:     http://www.initos.com
>
> Geschäftsführung:
> Dipl. Wirt.-Inf. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
> Haftende Gesellschafterin: initOS Verwaltungs GmbH
>
> Sitz der Gesellschaft: Rosengarten – Klecken
> Amtsgericht Tostedt, HRA 201840
> USt-IdNr: DE 275698169
> Steuer-Nr: 15/205/21402
>