openerp-india team mailing list archive

["Nhomar Hernandez \(Vauxoo\)" <nhomar@xxxxxxxxx>]

Wao.

Cristian, this time you are losing the point of this bug, and i think
you are giving a real closed opinion.

I don't know if you know how accountant works in real Big
implementations.

But several Accountants needs make correction to back in time, when:

- Loading External moves.
- Loading corrections for audit process.
- Correction Initial and closing balances.

If we block to accountants to do this kind on moves you are locking all
the capacity to audit and dedicate the correct time to make corrections.

IMHO. Exactly as the comment of #29 said .

>>-- leave the choice to the user (e. g. accountant) if no other good reason precludes that choice;
>>-- give freedom of choice/change on lower hierarchical levels, that's what they are for.

Even this option cover more value when you have a tool as OpenERP that
need to cover all scenaries, we in this point can not be lock-in.

If we allow all scenaries, we need to put triggers to avoid brake
backward compatibility with your data, for this is the field: "state" in
account.period, one time your period is audited and full loaded (it can
happend several month from the exact execution of the amounts) you can
lock it and NOTHING can happend.

BTW:

If we talk about Sale Invoice (for example) we need to be sure they
needs to be applied "in date" BUT if you applied them in a centrilized
way (I mean as a POS work MAKING ACCOUNTING TO and FORM AND EXTERNAL
STORE), you need make differents dates (exactly on date) in same period
() and DIFFERENT from account.move.

As this example we have AM for payroll, expenses adjust, cost adjust,
MRP, etc etc etc.

IF OpenERP should be a tool where EVERYTHING works fine out of the box
Your assertment should be absolutly TRUE but the reality is.......
NOBODY no SAP no JDEdwars No Bigs and No smalls is perfect around this
especific issue. We need from time to time CONFIGURE how my country
manage this kind of issues, and simply load configuration and
automations for journals and periods on simply XML configuration data.

Is easiest, and less dangerous technically speaking make a server action
than make a self.pool.get('account.period' or 'account.period' or
WHATEVER).write (XXXXXXX, {state:done}) IF something(your specific
buusiness condtions).... than OVEWRITE original lazzy constraints for
every single customer, constraintS without accounting real support,
accounting formal concepts and in a constant change.

I mean.

If we have :

Case A 
Case B 
Case C
And EVERY BODY knows are real and they are JUST this three cases, WHY DEVELOP A MODULE FOR EVERY single one, if this kind of intelligence is embebed on core, and we re-evaluate from time to time from experts in some time we will have a really trustworthy ERP and not a joke where you need 10 experienced developers for every single mid-size implementation, THIS kind of BASIC stuff MUST to be on core...............................

M;y 2 cents and OPENSOURCE ROCKS..... OpenERP WILL be the Best ERP
around the world....

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/519133

Title:
  Effective Date of Move and Movelines has to be the same?

Status in OpenERP Addons (modules):
  Opinion
Status in OpenERP Addons 5.0 series:
  Fix Released

Bug description:
  Hello

  When modifying an entry line in a centralized journal
  (journal.centralisation=true), all the entry line dates get modified
  and take the modified entry line value.

  The entry line dates should not be changed

  I guess the solution is in the write function in account_move_line.py
  where we should find some 'if journal.centralisation:...' as it is in
  the create function.

  Regards

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/519133/+subscriptions