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 <mailto: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>
>> <mailto: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> <tel:%2B49%20%280%29172%202303699>
>> Phone: +49 (0)4105 5615613
<tel:%2B49%20%280%294105%205615613>
<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>
>> <mailto: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
<https://launchpad.net/%7Eopenerp-community>
>> Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
<mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>
>> <mailto:openerp-community@xxxxxxxxxxxxxxxxxxx
<mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>>
>> Unsubscribe : https://launchpad.net/~openerp-community
<https://launchpad.net/%7Eopenerp-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 <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
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
