A refund should not have the same date as the invoice

[Numérigraphe]

In the current 5.0-bzr, when you get a customer invoice and press the "refund" action button, it seems the refund invoice gets the same date as the initial invoice.
Our users think it should get no date at all, since the date of the original invoice can be in an accounting period than is closed.
Lionel

[Numérigraphe (numerigraphe)]

Dear accounting experts, could you please confirm this ?
Lionel.

[Jan Verlaan (jan-verlaan)]

A refund invoice should be handled as a normal invoice.
The refund invoice based on a original created invoice has the advantage to copy all the necessary data that will prevent typing mistakes and speedup the refund invoice creation.
Only not all data should be copied, like the date and period mentioned.
I do agree that the original data from the original invoice should not be used, instead use the creation date (today's date) for the refund as basis. If user want's to shift that date forward or backwards, he/she is able to do so.

[Ferdinand (office-chricar)]

Jan +1
and of course the payment / reconciliation related data as well as associated account moves + lines must not be copied

[Alain Rivet (alain-rivet)]

Hallo,

I suppose the best is to propose the date of the refund as default date. Mostly, it will be right.
Regards
Alain

[Nhomar - Vauxoo (nhomar)]

+1

Is a Bug, the refund must copy only lines and partner data, the date
proposed should be the actual date not the invoice_date

Agree to with ferdinand the payment / reconciliation should not be the same
neither.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Experts,

I think, setting the current date as the default date would be the best way.

Suggest us please.

Thanks.

[Nhomar - Vauxoo (nhomar)]

+1 Agree with jay

2010/3/29 Jay (Open ERP) <email address hidden>

> Hello Experts,
>
> I think, setting the current date as the default date would be the best
> way.
>
> Suggest us please.
>
> Thanks.
>
> --
> A refund should not have the same date as the invoice
> https://bugs.launchpad.net/bugs/550742
> You received this bug notification because you are subscribed to
> OpenObject.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> In the current 5.0-bzr, when you get a customer invoice and press the
> "refund" action button, it seems the refund invoice gets the same date as
> the initial invoice.
> Our users think it should get no date at all, since the date of the
> original invoice can be in an accounting period than is closed.
> Lionel
>
>
>

--
Saludos Cordiales

Nhomar G. Hernandez M.
[phone]
[phone]
[phone] ext 124
[phone]
Web-Blog: http://geronimo.com.ve
Servicios IT: http://openerp.netquatro.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>

[Alain Rivet (alain-rivet)]

I agree too

[Jan Verlaan (jan-verlaan)]

if default date = creation date of refund invoice I agree too.

[Claude Brulé (claude-brule-syleam)]

The refund generated form an invoice is in draft state (at this point).
According invoices in draft state has no date, and according the date of
the invoice document is setted by moving workflow form draft to open, it
should have no date at all.

So when refund is copied form invoice, default_date_invoice = False, and
that's it.

Thanks in advance
Claude Brulé

Jan Verlaan (Veritos) a écrit :
> if default date = creation date of refund invoice I agree too.
>
>

--
SYLEAM
27 avenue Jean Mantelet
61000 Alençon
tel : [phone]
fax : [phone]

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Guys,

I have attached a patch here.
Would you please try and check?

@Claude Brulé,
I agree with you for default date to be false for a newly created DRAFT invoice, but this is a case where its a REFUND invoice,being created today itself having a linked to paid invoice. so date is necessary.

Thank you for the feedback.

[Claude Brulé (claude-brule-syleam)]

Jay (Open ERP) a écrit :
> Hello Guys,
>
> I have attached a patch here.
> Would you please try and check?
>
> @Claude Brulé,
> I agree with you for default date to be false for a newly created DRAFT invoice, but this is a case where its a REFUND invoice,being created today itself having a linked to paid invoice. so date is necessary.
>
> Thank you for the feedback.
>
> ** Patch added: "refund_date.patch"
> http://launchpadlibrarian.net/42386750/refund_date.patch
>
>
Refund is linked to an open invoice. No one has said wheter it is paid
or not ...
You can create refund on non paid invoices, can't you ?

As refund and invoice are the same object, they should have the same
maner (way of working) : if it is a complete refund, then it is "open"
and it would have a date (you are right).
If it is a partial refund, so it is in draft state, and its date will be
setted at opening/confirm

--
SYLEAM
27 avenue Jean Mantelet
61000 Alençon
tel : [phone]
fax : [phone]

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Claude Brulé,

Yes, you have a point here.

Date has to be set based on the state of main invoice.

We need more opinions here from our experts.

Thanks.

[Thorsten Vocks (OpenBig.org) (openbig.org)]

imho generally the proposed date of the invoice makes sense for the refund of invoices, if period of
original invoice is not closed and if you do not want to use different date and periods option
(future journal option as discussed on workshop last week in belgium).

In this case the income or expense account move lines will be reversed in the right fiscal period
to get the right financial result for this period. Especially for the last period of the year this
situation seems to be very important (right fiscal year).

the problem i see with the existing account flow is the tax / vat declaration if you have already
declared your official taxes (vat) for a period which is still open. If your accounting department decided not
to close fiscal period e.g. for internal period reporting you might not be able to take into account reversed
vat moves for the next vat declaration (period of refund creation) or you have to remind to add these positions
by hand in addition to Open ERP vat report, which is really difficult to track.

(Workaround) solutions for this:

- As Jan and other proposed "current date" seems to be the solution for the vat declaration because you
will be able to take this move into upcoming declaration. But then you have to correct income /expense accounts
manually with an account move in the prior period to correct periods balance and income/expense statement (accrual
accounting), if you want (or have) to do this. imho this way is inconveniant and as a result not the perfect
solution especially if you decide to have always same date and period for invoice and refund accounting. This might be
another example as reason not to mandatory fix date and period in journals (1:1) as discussed on accounting workshop
in belgium last week).

- "Current date" with choice of different period could solve both (right period for the balance, profit loss
reporting) and also vat declaration (if we would create tax declaration with choice of "from date" and "to date",
which is currently not possible). Maybe this option is enough and may avoid further, more complex solutions
but for this we will need also the "from date" "to date" possibility for vat reporting. To prevent future
problems we should discuss if there is a problem to take "date" instead "period" for vat declarations
(e.g. different accounting base for balance profit & Loss report and vat reports, problem of ).
Anyway entering separatley date and period on refunds is imho also inconveniant but should fix both problems
if vat report wizard allows to choose "from and to date" .

Alternative solutions:

- A possibility (option) to decide if you want to report "tax reverse account moves" of
prior periods for vat reporting. But how do we see in this case which invoices to add from prior periods
and to avoid overlappings with prior vat declarations? With only a report functionallity this seems to
be impossible. Maybe we have to extend the process for vat reporting for this and also other reasons (usability).
Do we need a revision system for vat reports if we would decide to go this way? Do we need a state for
invoices and refunds like "vat declared" similar to "paid" / "u...

[Alain Rivet (alain-rivet)]

Oups !

Well, at the moment, we have different cases : full refund or partial refund, linked or unlinked to a specific invoice, already paid (and cleared ?) or not paid (and uncleared ?), invoice & refound in the same posting period or not and for this last case, invoice posting period still open or not, VAT to be paid on different status (In France VAT on Services becomes only payable when the invoice is paid, but VAT on goods becomes payable as commonly when invoice is simply posted)

I propose to keep it as simple as possible ! Could we not simply stay on the common accounting rules ?

Accounting rules request to define the accounting date in accordance of document creation. A posting date is necessery posted in the corresponding period (we discussed this on the community days and the default customizing will be period check on). It's the easyest way to avoid tax problems

Regarding this proposal, is there a difference at the accounting point of view for :

partial or full refounding ? NO !
linked or unlinked to a specific invoice ? NO !
Already paid or not ? NO ! It simply possible that we also have to repay the refund amount
Invoice in the same period ? NO !
Invoice in a closed period ? NO !
VAT in specific status ? NO !

Perhaps should I risk a specific comment about this : It's not the OpenERP job to solve all the "possible requests" that accountant can imagine to reduce tax or other fiscal advantages with playing in the past or other systems !

We not only have to satisfy our customers, we also have to provide a fair system to garantee that the tax controllers & other country authorities will not reject OpenERP as accounting system in one or another country because of some specific adaptations ! It should probabily be the end of the product... I crossed this kind of problems many years ago.

Sorry if my approach or if my last comment offend somebody. It's only a point of view from an old accountant.

Kind regards
Alain

[Thorsten Vocks (OpenBig.org) (openbig.org)]

@Alain

i agree to this point of view, especially to keep it as simple as possible.
My intention was to list some consequences for different cases. To cover all
wishes of comfortibility and different aspects of accrual accounting or additional
wizards to create paybacks or something else isn`t maybe the right way to go
for Open ERP accounting.

Indeed we should be able to create all account moves and paybacks and reports
we need without additional or new functionality and surely more complexity.
Yo convinced me regarding refunds workflow.

I vote for: "the date of the refund as default date"

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Lionel,Jan,Thosten,Alain,

Thank you for your valuable feedbacks.
It has been fixed by revision 2691 <email address hidden>.

We would like you to create another bug(thread) for this and post your precious suggestions there; so we can treat that as a wishlist for 6.0 and come up with a delighful solution.

Thanks again.