上周考了Service的Professional认证：SAP Certified Application Professional – Service with SAP EHP1 for SAP CRM 7.0。相比起Associate认证，难度提升了不小。试题主要考察系统配置和Troubleshooting，因此没有实战经验，光靠背CR700是过不了的。好消息是如果你有一定的基础，基本上可以忽略CR300，CR410，CR500，CR580，CR600等，复习的范围不算太大。
记得去年考C_TCRM20_70交卷时，觉得只是分数的问题；今年P_CRMSRV_71交卷时，心大心细啊，还好又见到久违的Congratulation。
就Partner Determination，一直有个疑问：多个Partner Functions的determine次序是怎样的呢？我们知道Access Sequence有10，20，30的先后次序，但是在Partner determination procedure中我们没法指定Sold-to，Ship-to，Contact Person的次序。之所以有这样的疑问，是因为Partner function之间往往是有关联性的，比方说我们通过Sold-to决定Org，再通过Org Structure决定Responsible Employee。
就此深入研究，发现Partner Function的determine确实是有次序的，但是这个次序不是简单的从上到下，或者按字母、数字排序，而是根据Access Sequence的内容计算得来的。因为Access Sequence中的Details on the Source，Mapping/Restrictions等字段反映了Partner Function的相关性。
相应代码为Function Module: COM_PARTNER_DEADLOCK_CHECK_CB中的Form: DEADLOCK_CHECK_ON_FUNCTION。计算的结果就是Determination Path，当中的DETERM_LEVEL决定了determine的先后次序。
认识到这个机制的存在，我们可以放心的定义Partner Function和Access Sequence，先后次序的问题则交给系统考虑。同时也解释了为什么我们无法人为指定Partner Function的determine的次序。
题外话，Partner Determination是通过Event Handler触发的，Callback Function为：CRM_PARTNER_DETERM_INITIAL_EC。
两个BADI可以用来做Partner Determination，传统的是COM_PARTNER_DETERM，需要在View: COMV_PARTNER_DOR中创建条目。CRM中现有的Access Sequence，也是通过这个BADI来Implementation。
另外一个叫COM_PARTNER_BADI，对应Access Sequence中Source的COM_PARTNER_X, Y, Z。
上述两个BADI，可以在Function Module: COM_PARTNER_DETERM_STEP_ONE_OW中看看是怎么一回事。
转眼间，在SAP已经四个月了。这是我SAP之路的一大台阶，还真to SAP了。这真是一个难得的机会，我既希望在SAP得到沉淀，也寄望在SAP得到飞跃。
Blog将继续慢慢……慢慢……更新……
CRM WebUI的单点登陆可以参考这篇文章：How to – SSO to CRM WebUI via SAP GUI for Windows
简单来说，就是通过Report: BSP_WD_APPL_STARTER 创建变式，分配到CRM_UI。
注意：需结合STRUSTSSO2的配置。
CRM中Pricing不是必须的，Item Categories中摘掉Sales Transaction Category中的Pricing-rel就行了。如果所有Item都是非定价相关的，那就不会去determine pricing procedure了。参见Note 702735，关掉IPC部分内容。
但是如果Item的产品是可配置的（Configurable）的话，项目必然是Pricing-rel的，即便你摘掉该选项。Note 743918提到：The configuration only works correctly if pricing is performed for the header。相关Note还有851523，832436。
程序可参考FM: CRM_PRIDOC_UPDATE_EC
近日在处理IC的Last Interactions问题的时候，无意触及这么一个东西Reporting Framework，它用于订单的搜索，即输入查询条件点击搜索后，Reporting Framework就上场了。常规的订单读取方式，包括权限检查，显然无法满足检索性能（Performance）的需要。那Reporting Framework是如何工作的呢？主要分两步：
这里用到两个表：CRMC_REPDY和CRMC_REPDY_DB，来构建检索的SQL语句。
权限检查发生在Selection阶段，跟常规的一张订单一张订单检查又有不同。简单来说，Reporting Framework会根据用户的User Profile去构建检索语句，把权限检查前置，从而减少了对数据库的访问。例如用户只有TA订单类型的权限，那么检索的语句会根据User Profile加入这个限制，而不是把订单检索出来，再去做权限检查，再过滤掉非TA的订单。也正因为如此，订单搜索和单张订单的权限检查不完全一致的，请参考Note 1305096。
其他有用的Notes: 1318262, 615670, 1226594
BTW，由于Performance的原因，R3AC6里头Reporting Framework的参数（CRMRF）很多，建议多查查Notes。