SAP 系统中，一些单据保存到数据库用的是 update mudule function。
命名是ME_UPDATE_* (业务说明)

例:PR save module: ME_UPDATE_REQUISITION
ME_UPDATE_INFORECORD   更新采购主记录数据

ME_UPDATE_AGREEMENT_PO更新采购凭证

ME_UPDATE_SCHEDULE_EKPO计划协议下达

ME_UPDATE_DELIVERY       更新采购凭证 ???

一些增强如果可以在单据保存时候做，在更新模块中加上隐式增强是一种方式：
不清楚是不是最好的，但是我的第一个 也是最大的项目的经历是使用了这种增强方式。

注意点：1，update module 不支持普通的调试模式，得在debug　模式下勾上＇数据库更新＇选项；

之前使用过　数据库更新选项，今天下午找了很久也没有找到，所以对于技术点的技术尤其重要。

２．此处增强后一定要非常细致的测试，我的体验，因为报错不明显，比不上ＳＥ３８编辑器的检查，
而且不会出现abap dump,而是附件邮件形式通知错误，
所以Ａ．一定确保没有影响标准更新，

Ｂ．保证达到了自己的业务目的


建议：（1）一般是隐式增强点，可以使用一个自建函数实现增强逻辑；
     （2）不用用 commit / rollback 数据库提交语句；
      (3)  尽量不要使用check, 避免检查失败 不运行其他业务逻辑。

UPDATE MODULE的类型

FUCTION MODULE 的处理类型有三种：
（1）常规函数模块，
（2）远程启用的模块，

（3）更新模块，

每种下面又包含4种分类；
a，立即开始

b，立即启动，无重启（不可重启）；

c，延迟启动；

d，集中运行；

collective run. 前两种属于V1类型，后两种属于V2类型。

UPDATE MODULE 的类型决定了其处理的模式。多有dialog程序里的V1请求都会在单独的DB LUW 里执行。只有当V1执行成功之后才会处理V2请求，

V2也会在单独的LUWS 里执行。

V2类型的 UPDATE MODULE 处理的DB changes 一般都是紧接着V1 的CHANGES（MAIN CHANGES）之后进行。

V1
（1） V1 类型的 UPDATE MODULE 分可重新启动和不可重新启动两种。V2类型的当发生错误的时候总是可以重新启动，再次处理。

（2）V1 请求都会在一个V1类型的UPDATE WORK PROCESS（UPD）作为一个单独的DB LUW来处理。

如果V1更新成功，系统会删除V1的请求和所有在V1更新任务上的锁，并设置一个DB COMMIT,然后触发V2更新。

V2

（1）V2类型的COLLECTIVE RUN是SAP内部使用。相应的V2请求并不是在V1执行之后直接执行，而仅仅是在程序RSM13005被调用之后才执行。 

(2) V2请求也是在一个V2类型的UPDATE WORK PROCESS（UPD2）作为一个单独的DB LUW来处理。如果SAP系统没有设置V2类型的UPDATE WORK PROCESS，则V2请求会在一个V1类型的UPDATE WORK PROCESS里进行处理。如果V2请求处理成功，将会从VBLOG删除相关的请求，并设置一个DB COMMIT。V2请求一般都会运行在没有锁的情况下，因为这些锁在V1完成之后就被删除掉了。因此，V2更新总是运行在没有SAP LOCKS的情况下。

如果V1 UPDATE MODULE 用一个终止消息终止了V1更新，那么V1更新任务上的锁将被删除，数据库将ROLLBACK，一个E-MAIL会发送给创建这个LUW的用户，并且V1请求在VBLOG 表中被标记为不正确。V2更新也就是不会被触发。

当然如果V2 UPDATE MODULE 终止了V2更新，同样的，数据库ROLLBACK，属于这个SAP LUW 的V2更新都不会执行，V2请求在VBLOG 表中被标记为不正确。

DIALOG 程序用_SCOPE = 2创建的锁会被传递到V1 更新任务中，在V1更新的结束，不管V1更新是否成功或者终止，都会把这些锁自动删除。
因此，在DIALOG程序中不能显式的删除这些锁（太早），或者在UPDATE MODULE里删除（没必要）。

SAP系统更新模块