Equity method of Consolidation

If the Consolidation Algorithm is Standard then the PCON=0 will ensure nothing gets as far as the C#Elimination stage, because the internal DataBuffer for C#Share (dynamic calc) will be empty.

If you change the Cube's Algorithm Type to [Custom] then you can override how the C#Share and C#Elimination gets processed, but this has a big performance impact because it writes the C#Share to the database, which creates about +25%-30% database size, and approx 25-30% longer consolidation times. (maybe more, depending on how big you data units are).  So that's not a good option either.

What you could do, by keeping your Consolidation Algorithm Type to [Standard], and thus benefitting from the performance of Dynamic Calc C#Share, is to have a calculate pass which reads directly from the child entity's C#Translated data unit (parent currency before the C#Share allocation) and not try to read from C#Share (which would be empty if PCON=0).  You would also need to set the cube setting to [Calculate Elimination Member if NoData] = True.

I don't know what's inside your EqutiyAccountCalculation() function, so we can't really provide any more details.

Another way to do this, by totally removing the need for a custom calculation pass, and removing the need for any custom consolidation, is to simply have a member formula, or Allocation Journal, on the Holding Company's base entity which has an interest in the non-consolidated joint-venture.  Then you just 'pick-up' the P&L result from the JV and post it into the Holding Company's base entity. You would probably Debit the A#[Investment] (Asset), and Credit the A#[Income From JV] (Income Statement).

An Allocation Journal will automatically apply the %interest. Alternatively a member formula that runs on the base entity, and you put the reference to the JV on the Text property of the holding company's base entity.