openerp-expert-accounting team mailing list archive

[Thorsten Vocks <thorsten.vocks@xxxxxxxxxxxxxxxxxx>]

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" / "unpaid" of invoices.  
>From legal perspective we should be able to manage this anyway. If we want to cover this, we need a logic to check 
whether we still reported an invoice for vat declaration or not. I would propose for this a solution comparable to 
account_payment proposal (especially Button Import Open Invoices), which assists import of "all" invoices which are not vat
declared (also checking option of "invoiced" and "payed" state for gross / net declaration option, e.g. Button "Import Undeclared 
Vat Invoices".     

I see also some other additional questions in this discussion regarding
usability:

- Shouldn't we be able to have a pop up for integrated reconcilation in this flow, especially if we make a complete 
refund of a invoice with no payment (reconcilation) moves ? Up to now you have to reconcile both entries manually, 
especially if you aggreed with customer / supplier not to pay invoice because invoice was wrong.

-  for the case of a partial refund on a invoice without existing payment lines / reconcilation moves. Shouldn't we create a
reconcilation move for the original invoice automatically?

- Should we be able to choose additionally a payback proposal in case we have a payment (line) for the original customer invoice 
(refund amount + payment amount / reconcilation amount - invoice amount)? Are we able to create payback payment 
proposal for customer refunds with core Open Erp account_payment extension (pls. merge the module from zikzakmedia
which is able to provide also customer payments)?

- Should we be able to monitor supplier invoice refunds with (wrong) payments from our company (e.g. special follow 
up menu for monitoring of money to receive from supplier invoice refunds). For this additional purpose of account follow up 
process we need a clear differentation between supplier refunds followup and customer invoice followup (e.g. separated menues). 
Surely we can also reduce the next invoice of supplier, but shouldn`t there be a choice to force a real payback, especially 
if you have not recurring invoices with some partners, just for conveniance and usability?

btw we should discuss additional aspects of accrual accounting requirements (especially for the end of the year
account move flow, especially differentiation of prior period (prior fiscal year) account move logic. To avoid
a lot of manual accounting entries for this purpose i see possibilities to improve this too in a more automatical
and surely also accurate way.


Should i add this comment to the blueprint area or do others think this is wrong or too complicated?

-- 
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 a member of OpenERP's
Accounting Experts, which is a direct subscriber.

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