Chart of account: incorrect consolidation computation

the rule is correct, but I see problematic impacts if an account with children accepts post because it's not easily possible to filter moves of this account. It usually confuses users even f it is technically possible.
IMHO "consolidation accounts" should be views - that's the way I am setting up chart of accounts.

I'd vote for enforcing the rule "views shouldn't accept posts". When you can't allocate a move to a child account, you should create a "Others" child account. Those "don't fit anywhere" moves are usually trouble and the accountant/auditor/manager will be glad to have those very explicit.

However, we know that the chart of accounts is not static. For instance, when growing a company want to split it's "CASH" account into multiple "CASH/Head Quarters" and "CASH/Branch" accounts. So, there should be a "Convert to view" button that would:

1) Create a sibling view account
2) Move the account to the newly created sibling as child
3) Rename ex-sibling, now parent to the account's name
4) Rename the account to something like "Child1"

+1 "views" and "consolidation" accounts should never accept posts

The problem with "consolidation" accounts is that it is not really consolidation account => in fact consolidation account should view the sum but we should not have the list of children account because if we print the balance sheet, it will not be interessting..... and not useable.

@Cloves Almeida "Convert to view"

we have to think about the naming
typically the new view should be called "account name" + Consolidation
and the old should keep it's name - no autogenerated name will generally fit

and it's not "convert to view" but "insert consolidation account"

D'accord :)

Ferdinand @ ChriCar escreveu:
> and it's not "convert to view" but "insert consolidation account"
>
>

As the function *_get_account_values* is removed by this patch, I ask c2c if any of their module will be broken by this patch.

Fixed by revision <email address hidden>.
Thanks.

Hi All,
  I am Sandra and very much interested in this medical and related modules like medical_icd10, medical_lab, medical_lifestyle, medical_socioeconomics, medical_surgery, profile_medical, medical_genetics, medical_gyneco.
Can you please describe me the working of all these modules in open erp 5.0.11. I have so many doubts regarding the invoice and payments of patients. How can we invoice using these modules? Or any other modules related to these to perform this? Or How can we integrate these modules with the existing account_invoice or account module? How can we do the patient billing? Can you please make clear these doubts.
I am waiting for your kind reply........

Thanks and regards
Sandra

Hello sandra....

This is not the correct place where put your question, if you can see this
is a bug-tracking system, please check in the official page for these
project, or contact the developers or a partner that can help you......

http://openerp.com/forum/

Regards

--
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
+58-212-6615932
+58-212-9536734 ext 124
+58-212-9512643
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://openerp.netquatro.com
Linux-Counter: 467724
Correos:
<email address hidden>
<email address hidden>

Dear Sandra,

my name is Thorsten. We are german partner with experiences in healthcare
(hospitals) sector since 1996.
As we discovered few weeks ago there is no bridge to billing and accounting.
Billing and accounting is very specific to
each country. In germany we have DRG system (diagnosis related groups) for
billing process.
For example to be able to adopt OpenERP in our country we should be able to
group patients data
(especially diagnosis and procedures together with some other informations
like duration of patients
residence, age, types of hospitalisation, different types of diagnosis and
procedures) . These informations
we need to group to a DRG which is comparable to a sales product in OpenERP
terminology. In germany we
have round about 1000 of different DRGs. Most proprietary systems have an
existing interface to a certified
DRG grouper for example to 3M grouper for germany. The system receives the
DRG for billing from this external DRG
grouper. A lot of other countries have also DRG billing and patients
grouping system but every country with some
specific kind of dialect and with different organisation of their healthcare
financing system...

Another specific point we need to cover in germany is paperless data
exchange with insurance companies to
request costs coverage, diagnosis, procederes exchange, billing exchange ...
Difficult to handle is also
a lot of small changes in catalogues and grouping logic from one year to
another. Maintenance of the system
as a provider is not very easy.

Best regards

Thorsten Vocks
openbig.org

2010/7/1 Sandra <email address hidden>

> Hi All,
> I am Sandra and very much interested in this medical and related modules
> like medical_icd10, medical_lab, medical_lifestyle, medical_socioeconomics,
> medical_surgery, profile_medical, medical_genetics, medical_gyneco.
> Can you please describe me the working of all these modules in open erp
> 5.0.11. I have so many doubts regarding the invoice and payments of
> patients. How can we invoice using these modules? Or any other modules
> related to these to perform this? Or How can we integrate these modules with
> the existing account_invoice or account module? How can we do the patient
> billing? Can you please make clear these doubts.
> I am waiting for your kind reply........
>
> Thanks and regards
> Sandra
>
> --
> Chart of account: incorrect consolidation computation
> https://bugs.launchpad.net/bugs/504824
> You received this bug notification because you are a member of OpenERP
> Accounting Experts, which is a bug assignee.
>
> Status in OpenObject Addons Modules: Fix Released
> Status in OpenObject Addons 5.0 series: Fix Released
>
> Bug description:
> Computation of fields *credit*, *debit* and *balance* are incorrect when
> child accounts are *Consolidation* account with child accounts (real child,
> not the one specified in "Consolidation Children" field)
>
> In fact the rule is simple:
> credit = credit of me + credit of all of my direct children
>
> In case of consolidation accounts, that include the consolidation children.
>
> Can the accounting expert team confirm:
> 1/ The rule
> 2/ The attached patch
>
>
>
> _________________________...