简介：SAP集团拷贝（Client Copy）实操手册面向SAP Basis运维人员、ECC系统管理员及需要搭建独立测试环境的顾问，重点解决在不影响生产集团的前提下，从000集团复制出790测试集团并用于定制、开发与测试的问题。压缩包内共1个doc文档，约776KB，以图文步骤形式组织，便于按章节查阅和对照操作。已有630人学习下载，具备一定的实务参考价值。手册围绕ECC 6.0 32位系统展开，覆盖管理员账号准备与SU01复制ID、SALE中定义逻辑系统并分配至客户端、设置集团角色与跨集团修改选项、RZ10调整SAP*登录参数、SCCL后台排程拷贝以及新集团登录验证等关键环节；同时提示数据一致性、权限与网络资料时效性等常见问题，并延伸至MM流程定制与经典程序收集。读者可据此掌握从环境准备到拷贝验证的完整路径，形成可复用的集团拷贝检查清单与排错思路。
1. 从 000 拷出一套 790：为什么老手不在样板集团里直接做定制
一套刚装好的 ECC6.0 摆在面前，最省事的做法是直接登 000 开干。但 000 是交付时的样板集团，DDIC、SAP*、本位币、逻辑系统全是安装默认值，任何一处改动都会顺着跨 Client 表扩散到所有集团。所以标准动作是先做一次 client copy（集团拷贝），把 000 整盘克隆成独立 Client，比如 790，再在 790 里做 MM 流程定制、流程数据导入和程序开发。
这条链路按顺序是：SU01 建管理号、SALE 定义逻辑系统并挂到 790、RZ10 放开 SAP* 登录、SCCL 排后台作业、SCC3 看日志。中间有几处被转烂了却没人验证的坑，比如 SAP* 登录不了、RZ10 的 Profile 搜索帮助为空、SCCL 目标 Client 灰掉。适合刚接手 Basis 日常的 ABAP 和 MM 顾问，也适合要把测试环境从零搭起来的人。
2. 复制 DDIC 之外的管理账号：SU01 复制 ID 与三个必补项
2.1 DDIC 和 SAP* 的边界在哪里
安装 ECC 时定下来的两个账号，DDIC 和 SAP*，密码是安装过程中设的，属于系统保留账号。DDIC 是数据字典和安装维护用的，SAP* 是超级用户，登录时绕过权限检查。这两个号的问题不在于能不能用，而在于不可追溯：多人共用、密码一旦被改恢复路径很少、后续所有定制和传输请求都挂在同一个名字下，出了问题查不到人。
行业里的常见做法是先复制出一个 Z 开头的管理员 ID，把定制、传输、排程都记在它名下。复制的好处是能把模板用户的登录数据、地址、用户组、参数一并带过来，省去逐项填。风险也在这里：如果拿 DDIC 当模板，SAP_ALL 会一起带过来，这个号一旦泄露等于系统裸奔。所以复制完必须做三件事——改密码、改地址和用户组、把角色收敛到实际需要的范围。
2.2 SU01 复制用户的实操路径
SU01 是 GUI 操作，路径不复杂，但每一步都有个容易漏的字段。
- 事务码 SU01，输入模板用户 DDIC，回车进入维护界面。
- 工具栏点「复制用户」（Copy），弹出目标用户输入框，填 ZDEV_ADM。
- 系统提示是否复制用户主数据，确认后进入新用户界面。
- 在「登录数据」页签改初始密码，用户类型保持 A（对话用户）。
- 在「角色」页签检查带过来的角色，只保留需要的，多余的删掉。
- 在「参数」页签补 SPDB、SP01 输出控制，语言和日期格式按团队习惯设。
- 保存。
用户类型这一项值得单独说。USTYP 有四个值：A 是对话用户，D 是服务用户，B 是系统用户，C 是通信用户。管理员用 A，因为要登录 GUI 做配置；后台 RFC 用 B 或 C；D 一般给不需要改密码的对话场景。复制时如果模板是 DDIC，USTYP 大概率是 A，不用动。
用户组 CLASS 决定 CUA 集中管理时的归属，单系统环境里影响不大，但填上「超级用户组」对应的值比较稳妥，后面接中央用户管理时不用返工。
2.3 用 BAPI 建号，比手工复制更可控
如果要批量建号，或者想把建号动作固化成一段可重复执行的逻辑，用 BAPI 比 SU01 手工点更靠谱。ECC6.0 的 ABAP 是 7.0 版本，语法按老式写，不要用内联声明。
DATA: ls_logondata TYPE bapilogond, ls_password TYPE bapipwd, ls_address TYPE bapiaddr3, lt_return TYPE TABLE OF bapiret2. ls_address-lastname = 'ADMIN'. ls_logondata-ustyp = 'A'. " A = 对话用户 ls_logondata-class = 'C'. " 用户组 ls_password-bapipwd = 'Init@2024'. " 初始密码，须满足当前密码策略 CALL FUNCTION 'BAPI_USER_CREATE1' EXPORTING username = 'ZDEV_ADM' logondata = ls_logondata password = ls_password address = ls_address TABLES return = lt_return. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = abap_true.逻辑说明：先组装登录数据、密码、地址三个结构，再调用 BAPI_USER_CREATE1，最后必须显式 COMMIT，否则 BAPI 只在内存里改了，回滚掉什么都不剩。参数上，USTYP 决定账号类型，CLASS 决定用户组，BAPIPWD 里的密码要满足 profile 参数 login/min_password_lng 定下的长度和下划线规则，不满足时 BAPI 会在 RETURN 表里返回 E 类型消息，不会抛异常，所以调用完必须遍历 RETURN 判断。
这段代码只建用户主数据，不分配角色。角色要用 PFCG 或 SU01 另外挂，SAP_ALL 和 SAP_NEW 建议只在建号阶段临时挂，日常定制换成 Z 角色。
2.4 复制完必须补的三件事
第一件是密码策略。SU01 里设的初始密码是明文录入的，首次登录会被强制改。如果希望管理员账号不过期，得把 login/password_expiration_time 调大或者对特定用户组关掉过期，这个参数在 RZ10 里改，属于实例级配置。
第二件是地址和用户组。复制过来的地址是模板用户的，后续做传输、看请求日志时显示的都是别人的名字，排查时会误导。用户组则影响 SE09 里看到的请求范围，CUA 环境下尤其明显。
第三件是锁定 SAP*。等 790 拷完、ZDEV_ADM 能正常登录并具备所需权限之后，回 SU01 把 SAP* 锁掉，或者改一个只有值班人员知道的密码。这是防止误用超级用户最便宜的一道保险。
提示：DDIC 的密码不要跟着改。ECC 里部分维护事务和字典激活动作仍然依赖 DDIC，改掉之后某些操作会静默失败，表现成「点了没反应」。
3. 定义逻辑系统 QAS：SALE 里那张跨 Client 表到底改了什么
3.1 逻辑系统的角色
逻辑系统是给「这个 Client 扮演什么角色」贴的标签。它本身不存业务数据，但在三处被引用：ALE/IDoc 的路由配置、RFC 目标（SM59）里的目标系统标识、传输管理里的系统路径。如果逻辑系统没定义就去做拷贝，拷出来的 Client 在 ALE 和传输场景里是「无名氏」，后面补配置要回头改一堆地方。
命名上常见两种风格。一种是简单的系统标识，比如 QAS；另一种是带 Client 后缀的，比如 QASCLNT790。前者短，适合单 Client 场景；后者在多 Client 环境里更清晰，ALE 配置时一眼能看出是哪个 Client。原文用的是 QAS，能跑通，但如果后续要接 ALE，建议按第二种补一个带 CLNT 后缀的逻辑系统，不要事后改，改逻辑系统要动所有引用它的配置。
3.2 SALE 路径与跨 Client 警告
操作路径是：事务码 SALE，展开 Basis Settings，进 Logical System，点 Define Logical System。系统会先弹一句 Caution: the table is cross-client，回车确认后进入维护界面。
这句警告不是吓唬人。逻辑系统清单存在跨 Client 表里，所有 Client 共享同一份数据，在 000 里加一条 QAS，790 里立刻能看到，反过来也一样。这意味着两件事：一是改之前要确认没有别的 Client 在依赖这条记录；二是这个动作会落传输请求，不是本地改完就算了。
进入界面后点 New Entries，填两个字段：Log. System 填 QAS，Name 填描述，比如 Test of Logical Systems。保存时系统弹请求号输入框，没有现成请求就新建一个。请求号记下来，下一步 Assign 到 Client 还在同一个请求里，释放的时候一起走。
| 字段 | 示例值 | 说明 |
|---|---|---|
| Log. System | QAS | 逻辑系统标识，全系统唯一，建议大写 |
| Name | Test of Logical Systems | 描述，写清用途和归属 |
| Request | 新建或选现有 | 跨 Client 改动必须落请求 |
3.3 Request 的选择：本地请求还是传输请求
搭建阶段有个取舍。逻辑系统和 Client 参数这类配置，如果只是在当前系统里用，可以落 $TMP 本地请求，释放时不生成传输文件，省事。但一旦这套配置要往测试系统、生产系统复制，就必须用可传输的请求，否则到了目标系统还得手工再点一遍。
我一般这样分：纯本机搭建阶段用 $TMP，等环境稳定、要把配置固化下来时，切到正式请求，按 DEV 到 QAS 到 PRD 的路径放开。这样既不会在搭建期被传输卡住，也不会把临时配置带进生产。
注意：跨 Client 表的改动一旦释放，目标系统里同名逻辑系统会被覆盖。释放前用 SE09 看请求里的对象清单，确认没有夹带别的改动。
3.4 用 SE16 校验 T000 和逻辑系统清单
定义完别急着往下走，先确认数据真的落库了。SE16 查 T000，看 790 那行的 LOGSYS 字段是不是已经填上。T000 是 Client 表，字段不多但都很关键：
| 字段 | 含义 | 拷贝前的正常值 |
|---|---|---|
| MANDT | Client 号 | 790 |
| MTEXT | Client 描述 | Test of Logic System |
| ORT01 | 城市 | 按实际填 |
| MWAER | 本位币 | RMB |
| CCCATEGORY | Client 角色代码 | 对应所选 role，F4 可看取值 |
| LOGSYS | 逻辑系统 | QAS |
如果 LOGSYS 是空的，说明 Assign 那一步没做成，或者保存时请求报错被回滚了。这时候不要继续做 SCCL，目标 Client 在拷贝工具里会显示不全。
4. 把 QAS 挂到 Client 790：Assign 参数的逐项拆解与角色选择
4.1 一个反直觉的点：Assign 不等于拷贝
很多人以为在 SALE 里把逻辑系统挂到 790，790 就有数据了。不是。Assign 这一步只是在 T000 里建了一条 Client 记录，写的是元数据——Client 号、描述、城市、本位币、角色、逻辑系统。真正的数据拷贝在后面的 SCCL 里做，两者是分开的。
这个区分很重要，因为参数填错的时候，补救成本不一样。元数据填错，改 T000 就行，前提是还没开始拷数据；数据拷完之后再改本位币或者 Client 角色，代价会成倍上升。所以 Assign 这一步值得慢下来逐项看。
4.2 Assign Logical System to Client 的操作步骤
路径是 SALE，Basic Settings，Logical Systems，Assign Logical System to Client。点进去同样弹跨 Client 警告，回车确认后能看到系统里所有 Client 的清单，前三条是系统自带的 000、001、066 之类。
点 New Entries 进入明细界面，逐项填：
| 字段 | 建议值 | 为什么这么填 |
|---|---|---|
| Client | 790 | 000 到 999 之间，避开已存在的号 |
| Client Name | Test of Logic System | 描述，建议带用途和负责人 |
| City | 按实际 | 影响地址类单据和税码判定 |
| Logical system | QAS | 上一步定义的，F4 搜索帮助可选 |
| Std currency | RMB | 集团本位币，定了之后改代价极大 |
| Client role | Customizing | 可选 Customizing、Test、Production、Demo、Training |
| Automatic recording of changes | 勾选 | 自动记录定制更改，便于追溯 |
| Changes to Repository and cross-client Customizing allowed | 选中 | 允许改跨 Client 对象 |
| Protection level | 0 | 0 无保护，1 不允许覆盖，2 不允许外部覆盖 |
| eCATT and CATT allowed | 勾选 | 后续要跑 eCATT 脚本时必须有 |
保存时系统再弹一次「更改逻辑系统时请小心」，回车，提示 Data was saved，回到清单能看到 790 那行。
4.3 Client role 和 Protection level 的真实语义
Client role 决定的是「这个 Client 允不允许被改」。Production 角色下，定制和跨 Client 对象都被锁死，只能跑业务；Test 角色允许改定制但不允许改跨 Client 对象；Customizing 角色两者都放开。Demo 和 Training 是给演示和培训用的，数据可以随便造。
Protection level 是另一层闸门，跟角色叠加生效。0 是不设保护；1 是不允许被覆盖，比如传输进来同名的定制对象时拒绝；2 是不允许外部覆盖，连系统间的传输都挡。搭建阶段选 0，等 790 稳定下来、开始接收从开发系统传过来的请求时，再考虑调到 1。
这里有个常见误用：把测试 Client 设成 Production 角色，理由是「怕人乱改」。结果是传输进来之后想调个配置都改不动，还得回 SCC4 改角色再重启相关服务。角色应该按用途定，保护靠权限和传输流程来管。
4.4 本位币和城市：两个一次定终身的字段
MWAER 是本位币，建 Client 时定下来，所有金额字段按它存。后面要改，得跑币别转换，涉及所有含金额的表，几百万条数据起步，还得停业务。所以在 790 上填 RMB 之前，先确认这套系统的业务范围是不是只涉及单一币种；如果要多币种，本位币选主业务币种，外币在业务单据里单独带。
ORT01 是城市，影响地址、税码判定、部分单据的打印格式。填的时候按实际运营地写，不要图省事写个「测试」。有些税码的计算规则跟地区绑定，城市填错会导致后续 MM 采购订单的税算不对，排查起来很绕。
提示：Assign 保存后，用 SE16 再查一次 T000，确认 790 那行的 CCCATEGORY 和 LOGSYS 都落了值。如果 CCCATEGORY 是空的，多半是 Client role 没选或者保存时报错被吞了。
5. Client Copy 前的常见问题排查：五个翻车点与 RZ10 参数修正
5.1 现象：790 用 SAP*/PASS 登录，提示用户名或密码错误
原因有两个层面。一是 ECC6.0 新装系统里，profile 参数 login/no_automatic_user_sapstar 的默认行为会让 SAP* 不自动创建或被禁用；二是 SAP* 的初始密码是系统硬编码的 PASS，跟 DDIC 的安装密码不是一回事，很多人拿 DDIC 的密码去试，当然进不去。
解决要走 RZ10 改参数，步骤不能省：
- 事务码 RZ10，菜单 Utilities，Import profiles，of active servers。
- 执行导入，看日志确认出现 Profile import executed correctly。
- 回 RZ10 初始界面，Profile 字段点 F4，选当前实例的 profile，名字格式是
<SID>_DVEBMGS<NR>_<主机名>。 - 选 Extended maintenance，点 Change。
- 点 Parameter 新建一行，Parameter name 填 login/no_automatic_user_sapstar，值填 0。
- 点 Copy，弹框回车确认，保存。
- 点 Display 确认参数已经在列表第一行。
- 完全停掉 SAP 实例，再启动，参数才生效。
注意：RZ10 保存时会问存到 Database、File 还是 Both。选 Both，否则下次操作系统层 profile 文件被别的工具覆盖时，这个参数会丢，症状是「重启之后 SAP* 又登不上了」。
如果 SAP* 已经被锁，先用 DDIC 或 ZDEV_ADM 登录 000，SU01 里解锁并重置密码，再去 790 试。
5.2 现象：RZ10 里 Profile 的 F4 搜索帮助是空的
原因是新安装的 ECC 没有执行过 profile 导入。profile 文件在操作系统层是存在的，但没进数据库表，RZ10 的搜索帮助读的是数据库，所以看到空白。
解决就是 5.1 里的第 1、2 步，Utilities 里跑一次 Import profiles of active servers。执行完看日志，三行都显示正确再回 RZ10。这个动作在每次新装系统后都应该做一次，属于装机收尾的固定动作。
5.3 现象：SCCL 里目标 Client 下拉找不到 790，或者 790 是灰的
SCCL 的目标 Client 清单是从 T000 读的，读不到说明 790 在 T000 里不存在，或者存在但关键字段没填全。最常见的原因是 SALE 里 Assign 那一步保存失败，被请求锁或者跨 Client 警告挡住，操作者以为点过回车就成功了。
解决：回 SALE 重做 Assign，保存后 SE16 查 T000 确认 790 在；退出 SCCL 重新进入，让工具重新读一次 T000。如果 T000 里有 790 但 SCCL 还是灰的，检查 LOGSYS 是否为空，有些版本对逻辑系统为空的 Client 会禁用拷贝目标。
5.4 现象：保存逻辑系统时报「请求被用户锁住」或「跨 Client 对象不允许更改」
前者是请求锁，SM12 里能看到锁条目，通常是上一个会话异常退出留下的。解决是 SM12 选中自己的锁删掉，或者等锁超时。后者是 Client 角色的限制，当前 Client 如果是 Production 角色，跨 Client 对象的更改被禁止。
解决：SCC4 或 SALE 里确认当前 Client 的 role 和「Changes to Repository and cross-client Customizing allowed」选项，改完保存再重试。注意这个改动本身也是跨 Client 的，会再落一个请求。
5.5 现象：SCC3 日志跑到某一步停住，或者后台作业一直显示已调度不执行
三种可能。作业没释放，SM37 里状态是 Scheduled 而不是 Released，需要手工释放；目标 Client 的表空间满，拷贝到一半写不进去，SM21 和 DB02 里能看到；并行进程数开太大，ECC6.0 32 位系统单进程寻址有限，并行度拉高之后内存撑不住，进程被 OS 杀掉，日志就停在那一行。
解决顺序是 SM37 看作业日志和假脱机输出，SM21 看系统日志有没有 ABAP dump 或数据库错误，DB02 看表空间余量。并行进程数在 32 位环境里建议控制在 4 到 8 之间，不要照着 64 位系统的经验值填 16 以上。
6. 从 SCC3 日志到可用测试集团：四个校验点与拷贝后的收尾动作
SCCL 排完作业不是结束，SCC3 里的日志要按顺序读，不然看到「已完成」也不知道到底成了没有。
第一个校验点是作业整体状态。SM37 里看作业是否已经 Finished，返回码是不是 0。如果状态是 Canceled，直接看假脱机，那里有 ABAP dump 的摘要。
第二个校验点是 SCC3 日志本身。日志头部会写源 Client、目标 Client、拷贝 Profile、开始时间，往下是各阶段的执行情况。不要只看最后一行的总体状态，要逐段看有没有黄色警告，特别是 Dictionary 激活和表拷贝这两段，警告积累多了会在后续使用时变成零散的短转储。
第三个校验点是数据行数。登录 000，用带 CLIENT SPECIFIED 的查询对比几个关键表的行数：
DATA: lv_src TYPE i, lv_tgt TYPE i. SELECT COUNT(*) FROM t000 CLIENT SPECIFIED INTO lv_src WHERE mandt = '000'. SELECT COUNT(*) FROM t000 CLIENT SPECIFIED INTO lv_tgt WHERE mandt = '790'. WRITE: / '000:', lv_src, '790:', lv_tgt.CLIENT SPECIFIED 是必须的，不加的话 Open SQL 会自动补上当前登录 Client 的条件，查出来永远是 1。把 T000 换成 USR02、T001 这些表，对比源和目标的条目数，差异在合理范围内才算拷贝成功。
第四个校验点是用户和权限。如果拷贝 Profile 选的是 SAP_CUST 或 SAP_APPL，用户主数据不会带过来，790 里只有 SAP* 和 DDIC 这类系统账号，ZDEV_ADM 得从 000 手工复制或者用 SCCL 单独跑一次 SAP_USER。这一步漏掉的表现是「790 登进去什么事务码都没有」，看着像权限问题，其实是用户根本没拷过来。
拷贝 Profile 的选择直接决定拷什么，常见几个的标准含义如下：
| Profile | 内容 | 适用场景 |
|---|---|---|
| SAP_ALL | 全部 Client 数据、定制、用户 | 整套克隆，最慢但最完整 |
| SAP_APPL | 应用业务数据 | 只要单据数据 |
| SAP_CUST | 定制配置 | 只要配置，不要业务数据 |
| SAP_USER | 用户主数据和权限 | 单独迁移用户 |
| SAP_PROF | 权限参数文件 | 权限体系迁移 |
收尾动作有四件。改掉 SAP* 的密码或者锁掉；SCC4 里把 790 的角色从 Customizing 调到 Test，等不再做跨 Client 更改时再收紧；把这次拷贝落的请求号记进环境文档，后面搭 QAS 和 PRD 时照着重放；最后跑一次 SM37，确认没有残留的后台作业还在跑。
血泪经验是拷贝前一定要做一次 Simulation。SCCL 里有模拟选项，不实际写数据，只跑一遍检查表空间、权限、锁冲突，几分钟的事，能提前挡掉大部分中途失败。我现在的习惯是每次动 Client 级操作之前，先 Simulate 一遍，再看 SM12 有没有残留锁，两个动作加起来不到十分钟，比拷到一半失败再回滚划算得多。希望帮到你。
本文还有配套的精品资源，点击获取
