SAP电子签名.docx

SAP电子签名.docx

《SAP电子签名.docx》由会员分享，可在线阅读，更多相关《SAP电子签名.docx（14页珍藏版）》请在冰豆网上搜索。

SAP电子签名

SAP电子签名

第一局部：

SAP电子签名的介绍与使用

电子签名目的就是为了保证关键的操作动作，如产品特性的数据录入，文档的变更，工程变更等等，这些需要特定权限的人才能做的事情或者说需要确保这些行为是某些人所为，可以追溯更改历程的。

SAP本身有设定账号的权限，但是这并不能保证某些特定的行为就一定是某个特定人所为，比方，A员工登陆他的SAP账号，但是他分开了PC或者分开后没有退出登录，而此时有其他的B员工登录该PC进展文档更改，他可以直接使用A的账号进展处理，那么系统最后记录的是A账号的处理记录，就不能正确反应真正做这件事的当事人。

假如在这些操作完成的时候要求进展账号验证，那就能比拟好的防止别人“盗用〞账号做事情的行为〔当然，密码被泄露了那就没方法〕。

可见，电子签名处理问题的思路很简单：

在操作完成或者需要操作的时候进展用户验证。

SAP的电子签名采用的是数字签名方法。

要实现整个流程的信息一致性，SAP要关联到主数据，处理过程和业务对象。

也就是说什么东西在什么业务下的哪个环节需要数字签名。

SAP在R/34.7版本之后开场兼容数字签名的功能，包括质量管理中的检验批次、物料批次特性、文档变更、工程变更、对象管理记录、抽样和流程制造单。

目前SAP支持的数字签名有三种实现方法：

系统已开发好的数字签名块，可以通过配置实现；通过SSF接口跟外围第三方电子签名产品进展连接配合使用；通过增强在SAP二次开发实现。

其中可配置的数字签名采用的是SAP账号的验证，但不要求签名账号必须跟登录账号一致。

那么对于企业当中多人共用同一个登录账号的数字验证，我们可以采用以下方案：

每个人在SAP创立唯一的通讯账号〔通讯账号不能作为会话登陆，只能做为通讯使用，不收费〕，需要验证的时候，每个操作人员使用自己的验证账号〔通讯账号〕进展数字验证，然后屏蔽掉公共登录账号的验证功能。

对于账号不多的企业，可以直接采用登录账号进展验证。

SAP对数字签名的整个过程都做了详细的文档记载，以便于实现审计追踪。

文档记载的内容包括签名的时间、签名者、签名的内容。

下面我们以质量管理中检验批的数字签名为例，演示可配置实现的数字签名配置步骤：

一、时间设定。

签名的文档中需要记录签名的时间，本地时间和全球时间。

1.时区设定

这个在SAP安装的时候basis都已经设定好了的。

途径：

spro->img->SAPNetWeaver->常规设置->时区->维护时区。

如图1、2所示

图1

图2

2.用户时区分配

Tcode：

SU01。

如图3所示

图3

二、定义签名方法

签名方法，也就是控制在哪个环节需要签名，通过怎样的方法进展签名，SAP内部账号签名还是外部电子签名产品签名。

途径：

spro->img->sap用户化施行指南->质量管理->环境->中央功能->权限管理->定义权限组和数字签字。

如图4、5所示。

图4

图5

我们以检查结果记录和使用决策进展数字签名为例，如图6所示：

图6

三、定义受权组

受权组跟签名的方法进展关联，这样只要拥有这个受权组的物料都将需要进展按照指定的签名方法进展签名。

途径：

spro->img->sap用户化施行指南->质量管理->环境->中央功能->权限管理->定义权限组和数字签字。

如图7、8所示。

图7

图8

图8中参数的详解：

受权组编号和短文本——自己输入；

赞同检验批——不要求同意；

在结果记录中的数字信号——终于结果记录；

使用决策的数字签名——需要制定使用决策；

确认实际采样图表的数字信号——不需要。

四、维护物料主数据的签名受权组

Tcode：

MM02/MM01。

如图9、10、11所示。

图9

图10

图11，因为这个系统配的业务属于重复制造，所以这里选择13-重复制造

五、结果测试

为了测试数字签名的效果，这里创立了一个检验批号，下面进展检验结果的录入并保存，如图12所示：

图12

从图12中可见，签字原因一栏自动带出来的是我们配置数字签名方法的操作内容，备注一栏自动带出来的是检验批号、工序号，下面还有的就是账号和密码的输入验证。

使用决策并保存，如图13所示：

图13

六、审计追踪

Tcode：

DSAL。

如图14、15所示：

图14

图15，本例中登录账号为LUFY，签名账号为DQTEST。

第二局部：

SAP电子签名的原理

SAP的电子签名使用的函数为：

SIGN_CREATE、SIGN_SAVE。

数据的保存都只IN UPDATE TASK,需要最后commit。

接口中存在第一局部中提到的七种业务参数，其中一个公共参数就是签名对象，也就是签名方法中的签名对象类型〔如图16〕，是用于决定哪些业务过程需要签名，它保存于数据域SIG_OBJ中，这个在执行过程中时需要验证的。

图16

确认数字校验的时候，系统再去判断根本对象是否拥有数字签名的受权。

例如QM中的检验批号，系统会校验物料主数据是否拥有受权的权限。

最后验证通过之后，系统将验证过程信息保存于各个模块对应的数字签名表头〔QM是TC73〕和共同数据表TC71中，以供审计追踪。

所以，总结起来说，SAP数字签名的逻辑就是根据操作模块业务去判断操作的业务对象是否拥有数字签名的受权，然后再判断确认的用户密码是否正确，验证通过之后系统产生数字签名的凭证抬头和明细并保存于数据库中。

第三局部：

增强数字签名

从第二局部分析的逻辑来看，SAP的数字签名其实很简单，我们完全可以定制化的在SAP任意地方进展数字签名增强。

只要可以清楚在哪个环节需要数字签名〔哪里需要就在哪里增强〕，哪种根本对象需要签名〔例如在物料主数据中添加一个字段/多个字段用于标记物料的数字签名需求〕，我们就可以二次开发增强施行。

按照根本的验证逻辑，验证相关联的对象是否拥有受权，调用SAP标准账号验证函数〔主程序：

SAPLCJ00屏幕1100PAI中的MODULE PASSWORD_CHECK_1000〕验证用户名和密码，通过之后，将数据保存于TC71中〔可通过tcode：

DSAL追踪〕，或者自建表〔报表需自己开发〕。

数字签名的编码对象为SIGNATURE〔tcode：

snro〕。

编号读取函数：

 CALL FUNCTION 'NUMBER_GET_NEXT'

       EXPORTING

            object                  = c_numberrange-object

            nr_range_nr             = c_numberrange-interval

       IMPORTING

            number                  = l_sign_no

            returncode              = l_get_number_rc

       EXCEPTIONS

            interval_not_found      = 1

            number_range_not_intern = 2

            object_not_found        = 3

            quantity_is_0           = 4

            quantity_is_not_1       = 5

            interval_overflow       = 6

            OTHERS                  = 7.

以下为QMlot数字签名的开发测试代码：

REPORT ZDS_TEST.

parameters:

 p_obj type sig_obj,

            p_qplos type qplos.

data:

 cs_rc73            type rc73,

      l_sign_reason_ktxt type rc71-reason_ktxt.

cs_rc73-sign_obj = p_obj.

cs_rc73-numb_cur = '01'.

cs_rc73-numb_tot = '01'.

cs_rc73-prueflos = p_qplos.

l_sign_reason_ktxt = '决策TEST'.

call function 'SIGN_CREATE'

  exporting

    object_imp                = cs_rc73-sign_obj

    key_lot_imp               = cs_rc73

    signer_imp                = sy-uname

*   FLG_COMMENT_REQ_IMP       = ' '

    flg_signer_changeable_imp = '0' "if_ex_digital_signature_ud~mc_kreuz

    sign_reason_ktxt          = l_sign_reason_ktxt

  exceptions

    cancelled_by_user         = 2

    pse_info_not_found        = 4

    password_wrong_3_times    = 5

    no_authority              = 6

    others                    = 7.

if sy-subrc ne 0.

  if sy-subrc ge 2.

    message id sy-msgid type 'I' number sy-msgno

    with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

  endif.

*--  Transaction has to be called again ...!

  leave.

  leave to transaction sy-tcode.

else.

*--  Authority check was successful -> call for update !

  call function 'SIGN_SAVE'

    exporting

      object_imp  = cs_rc73-sign_obj

      key_lot_imp = cs_rc73.

  commit WORK AND WAIT.

endif.