Thank you all for the feedback and Frédéric for the detailed explanation on the functional background for this constraint.
I'll consider preparing a merge proposal to make the check optional depending on a flag on the journal (Check Date in Fiscal Year, similar to the existing Check Date in Period). Best regards, -sbi On Mon, Mar 31, 2014 at 10:33 AM, Frédéric Clementi < [email protected]> wrote: > @ Robin @DP ... > > Posting invoices/expenses to a prior period is still allowed what we want > to block is to do this on a previous *fiscal year*. > > However, legally, you are correct there is not issue removing this > constraint since this is the period which is important not the date. > > But, saying that, I do not count the number of times customers called us > complaining about financial reports because they printed report by date and > then by fiscal year and noticed differences. > > I have also been asked many times why webkit financial reports do not > compute initial balance when date filters are used... > > It is a fact : Most of OpenERP finance users are not accounting > specialist. Users expect adequation between date and fiscalyear (even > period sometimes). > > OpenERP is great for its flexibility but for accounting purposes most > people dare to make mistake and want a work frame. > > > > > > > > Cordialement, > > *camptocamp* > > > INNOVATIVE SOLUTIONS > BY OPEN SOURCE EXPERTS > > *Frédéric Clementi* > > Project Manager > Business Solutions > > +41 21 619 10 41 > > > www.camptocamp.com > > > > 2014-03-31 9:35 GMT+02:00 Lorenzo Battistini < > [email protected]>: > > On 03/28/2014 05:17 PM, Bidoul, Stéphane wrote: >> >>> Hi experts! >>> >>> In module account_constraints, there is a check that the date of the >>> move is in the same fiscal year as the period. >>> >>> Here in Belgium I meet accountants saying that, while exceptional, it is >>> perfectly valid to enter a supplier invoice with a date in previous fiscal >>> year while forcing the period in current fiscal year. >>> >>> How would you recommend dealing with this situation? Should >>> account_constraints be split in more granular modules implementing subsets >>> of constraints so we can chose the one that are applicable in our regions? >>> >> >> Hello Stéphane, >> otherwise, you could make the constraints optional, based on company or >> user group settings. >> >> Regards >> >> -- >> Lorenzo Battistini >> Tel (CH): +41 91 210 23 40 >> Tel (IT): +39 011 198 25481 >> http://www.agilebg.com >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-expert-accounting >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-expert-accounting >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
