The process of requesting the change of customer’s credit limit has been systemized. In that process, the sales rep can create credit limit change request which will be mailed to credit rep who can approve and change the limit accordingly or forward to financial clerk for further information or just refuse it. The confirmation information will finally pass to the sales rep.

It should be great. Yes? But I find one problem which let down my interest a lot. SAP does not make any connection between the approval of request and the modification of the limit master. The process is just separated apart. You can only manually change the limit master. Don’t know the reason why SAP not doing better.

By the way, another perhaps more important thing is that the function is part of FSCM. I am not sure if it’s also part of ERP or if FSCM is shipped free with ERP.

One further topic is the functions introduced with ehp2 and ehp4 on credit limit change request handling with enterprise service. The focus is to build some standard interfaces with other applications and non-SAP systems. I will have it explained in Chinese to better illustrate the topic: the role of enterprise service or ESOA.

资料中举了三个场景来解释这些新的企业服务。

• 场景一：通过外部系统提交请求

1. 销售人员在一个非SAP的外部系统中制定销售计划。
2. 外部系统从SAP读取客户信用限额（ES: read credit account），对比，确定需要提交信用限额更改请求。
3. 外部系统提交信用限额更改请求给SAP（ES: create credit limit change request）。
4. SAP人员检查请求（ES: check create credit limit change request）。

• 场景二：其他应用读取请求信息

1. CRM系统如果需要客户限额更改请求信息，则可以通过ES: find credit limit change request和ES: read credit limit change request来实现。

• 场景三：想要由SAP来管理更改过程，但是由于有现有的惯用的外部系统，不想到SAP界面中去做。

1. SAP定期创建信用限额更改请求（ES: create …）。
2. 外部系统读取过来（ES: find…, read…），处理，将确认的请求限额向SAP发送更新（ES: update …）。

我想这应该是个很典型的SAP企业服务的实际应用的例子。通过这个，可以对SAP企业服务有更形象的认识。