Hi Senoy,
your table is hard to read. I think this kind of 'feature' comparison is a misleading since you can compile a list from BPC point of view and from BW point of view; and always a lot of things are missing. This is misleading in the sense that 'features' might be missing, but in fact just have other names.
In my opinion one should compare concepts; in the end one has to solve technical and business problems. It is obvious that having different engines (BPC standard use mostly concepts coming from the MDX world and BPC embedded is based on BW concepts) you might get different solutions for the same problem.
BW developments was driven by the big companies thus you got a solution controlled by the IT; BPC NW development was driven by LOB, so it is a data mart on top of BW. The idea of BPC embedded is now to bring these two worlds closer together without paying the 'price' of the data mart. In addition, LOB enablement should not be lost.
This price is coming from the completely different data models in BW and BPC standard and thus one has to copy a lot of meta data and transaction data from BW to BPC standard (and vice versa), simply because in BPC standard another engine is used that does not understand BW concepts. This forum is full of examples.
The first step on this long road of better intergation is BPC embedded; there you can use reuse everything from BW since the BW-IP engine is used, not MDX. So the copy stuff goes away. In addition you can use BPC concepts like work status and BPFs. EPM Add-In has to 'learn' BW queries and this takes some time. In addition AO and Design Studio can be used as well.
The next steps will be BPC admin client enhancements in the area of master data maintenance with respect to BW master data and LOB versions of BW master data (extension concept, no copy!). More information about these topics will be available soon. And then we should also integrate more BW-IP modeling in the BPC admin client (aggregation level, planning functions, ...).
With respect to the feature list I also have some remarks:
'Account versus key figure model':
BW supports both models and anything in between. Observe that BW is used as the data warehouse that has to support everything back to 'old R/3' times and the Business Suite; there you can find account and key figure models as well. The real difference is that in BPC standard one can have 'calculated accounts' as master data (not base members) and this is against the BW design of master data. In BW one uses hierarchies and mostly structure elements in BW queries for this purpose; i.e. 'calculations' are modeled in BW queries, not in master data.
Currency translation:
Of course, BW-IP and thus BPC embedded supports this; there is a planning function type for currency translation and one can do this even on the fly in BW queries. Same with unit conversion. This is again an example where BPC standard and BW concepts are different; BPC standard simply does not use the BW infrastructure (unit dimension in BW InfoCubes for example) but uses another concept (master data attributes, rate cubes).
Extension concepts:
Also BPC standard and BW have many extension techniques, in BPC standard mostly based on BAPIs, in BW (since it is much older) one can find BAPIs, exit classes and not to forget the variables concept. In BW one has the full world of InfoProviders available, so some requirements maybe solved simply using another InfoProvider type where in another solution one has to implement BAPIs.
And the nice thing with BPC standard and embedded is you get both worlds in one product; so there is no pressure to do either this or that. If a data mart is ok, use BPC standard. If you also need somthing in between IT and LOB BPC embedded can be an option. This is a developer forum, not a marketing forum. Remember: 'There is not silver bullet'.
Regards,
Gregor