Practical differences - BPC standard vs Embedded BPC (BW-IP/PAK)

[ArvindB]

I have seen a few posts contrasting the technical differences between "BPC standard model" and "Embedded BPC model" . Intent of my blog is to call out the practical differences I have noticed from a business/ Practical standpoint during the implementation that I have worked on. This is by no means a comprehensive list.

Issue		BPC standard	BPC embedded (BW-IP/PAK)
Master data & other  business consideration
Special characters in master data Many companies use "#, spaces" etc in their material#s. Example C345A76#01, C345A76#02 - to denote variation of the same basic SKU		Workaround & conversion(replace 'space' with _ or a similar character) required. Forced to display the "BW Material#" attribute in BPC reports instead of the native value. Possibility of duplicates if there are 2-spaces of many disallowed characters*	Native support Additionally MATN1 Conversion routine - that applies company's template defined in ECC for material# representation is respected. Example remove leading zeros for display purposes
Hierarchy support		Simple hierarchies, no support for duplicate nodes	Full blown support Duplicate nodes, external characteristics, also now "user-defined hierarchies"
Integration with other BW data exampl combine the SKU-level plan with "CRM promotion data" by SKU & period		Hard to do , have to bring data to unified format	Native support Full blown functionality
Time characteristics		only Calmonth, all others - such as fiscal period would have to be modeled as a another BPC dimension	Native support Full blown functionality 'Automatic time conversion from "Date" to Fiscal period, Month etc. There is a possibility to use "WEEK" and "MONTH" in the provider - this is especially applicable to Trade-promotion planning
BW statistics people underestimate the power of being able to records statistics on performance and usage. Allows companies to trim-down/eliminate less-used models/applications		not really supported	Native support Full blown functionality
File upload		Standard	need workaround
Locking		Last-person wins Desired behaviour in simple planning applications	The provider is locked with the characteristic-combination/filter. This has been a pain point for some customers
Future proof solution to take advantage of innovations on HANA platform
HANA views  & Mixed scenarios		Not standard**	Native support BW models can be pubished to HANA & fully leverage mixed-scenario
Load to BPC from aDSO and other new BW/HANA objects. i.e keep up with SAP's innovation		Not supported	Native support Additionally MATN1 Conversion routine - that applies company's template defined in ECC for material# representation is respected. Example remove leading zeros for display purposes
Dashboard & other BusinessObjects tools BICS connection, develop dashboard in design studio		no native support, but can used the generated-BW virtual providers.	Native support Full blown functionality
Available on BW/4 HANA		NO	YES
Technical capabilities
UoM Conversion		no native UoM conversion in BPC standard, needs script/formula	Push-down to HANA & native support
Prompts		limited use	Uses BE x queries, Full support - especially leverage User-exit variables
Time characteristics		only Calmonth, all others have to be modeled as a another BPC dimension	Automatic time conversion from "Date" to Fiscal period, Month etc. There is a possibility to use "WEEK" and "MONTH" in the provider - this is especially applicable to Trade-promotion planning
YTD(year to date) , PTD (period to date)		standard	Use the new delivered variables -  for YTD, MTD to achieve this
Performance for complex allocations logic		Good	Best Can be pushed down to HANA - depending upon the scenario
Navigational attribute , more complex 2-step navigational attribute		NO real support in BPC-reports. Workaround use a BE x query on virtual provider	Native support
* there is a system setting wherein you can allow BPC to use special characters - but SAP does not recommend
**It is possible to create HANA views on BPC-infocubes, but this is not a standard approach