企业官网建设流程全解析

简介：面向SAP Basis运维、实施顾问及ECC系统学习者的《SAP集团拷贝 client copy》操作文档，聚焦在ECC 6.0 32位环境中复制现有客户端、搭建独立测试与开发集团且不影响生产系统的需求。压缩包共1个doc文件，约776KB，以图文步骤和配置说明为主，适合作为集团拷贝流程的案头参考。文档围绕逻辑系统定义、逻辑系统与客户端分配、新客户端参数设置、SAP*登录及SCCL后台拷贝等环节展开，并补充RZ10参数调整、权限与数据一致性等常见问题的排查思路，帮助读者理解跨客户端配置的影响边界，掌握从000生产集团向测试集团复制时的操作要点与风险控制。已有630人学习，适合需要梳理Client Copy流程、对照配置细节和积累排错经验的中级SAP从业者。

1. SAP Client Copy 集团拷贝：从 000 到 790，先把“能不能动生产”这个问题答了

刚装完一套 ECC 6.0，摆在面前的现实问题往往不是“怎么配”，而是“敢不敢配”。000 集团里躺着 SAP 的标准参考数据，直接在上面做 MM 的定制、写 ABAP、跑测试，一旦改坏，重装一次的成本远比想象中高。SAP Client Copy（集团拷贝）解决的就是这件事：把 000 整包复制成一个独立集团，比如 790，之后所有定制、开发、测试都在这份“副本”里折腾，改烂了删掉重来，源集团毫发无伤。

这套流程适合三类人：刚接手一套 SAP 系统、需要自己搭测试环境的 Basis 新手；要在独立集团里做业务流程定制和程序开发的顾问；以及被“网上资料同出一源、错误一起转载”坑过、想要一份能照着敲的参数清单的人。需要说清楚的是，它不是备份工具，也不是数据库层面的克隆，而是一次带业务语义的集团级数据搬运，搬什么、不搬什么，全看你选的那个 Profile。

2. 拷贝前的准备工作：SCCL、SCC9、SCC8 怎么选，逻辑系统为什么是跨集团的

在真正点下 SCCL 的排程按钮之前，有两件事必须想明白：一是用哪种拷贝方式，二是目标集团在系统里到底“算什么东西”。这两件事如果选错，后面日志里出现的报错往往看不出根因，只能靠猜。我见过不少人上来就开 SCCL，跑到一半发现源和目标不在同一个实例，白等几个小时。

2.1 三种拷贝路径的边界：本地、远程、导出导入

SAP 提供的集团拷贝入口不止一个，名字相近但走的链路完全不同。选错的代价不是报错，而是“跑得完但对不上”。

判断标准很朴素：源集团 000 和目标集团 790 在同一套 ECC 实例里，就是 SCCL，没有第二种选择。SCC9 的价值在于跨系统，但它是把数据通过网络一段段推过去，中间任何一个 RFC 超时都会让整件事重来。SCC8 的路子更像“先打包再邮寄”，适合要把一套配置分发给多个系统的场景，代价是请求管理和传输目录必须提前理顺，否则导入阶段会卡在依赖顺序上。

我一般会建议：第一次做拷贝，就用 SCCL 在同一个实例里练手，把参数页的每一栏都搞明白；等这套流程走顺了，再去碰 SCC9 和 SCC8。原因很简单，SCCL 出错时日志指向明确，SCC9 出错时你分不清是数据问题还是网络问题。

2.2 逻辑系统为什么是跨集团的：SALE 里那条警告不是吓唬人

在 SALE 里点“Define Logical System”时，系统会弹一条警告，大意是“此表是跨集团的”。很多人直接回车跳过，但这句警告恰恰解释了后面一连串诡异现象的来源。

逻辑系统存放在跨集团表里（TBDLS 一类），它对整个实例的所有集团共享。也就是说，你在 000 里定义了一个叫 QAS 的逻辑系统，790 立刻就能看到它；反过来，你在 790 里改了它的描述，000 那边看到的也变了。这就是为什么系统要拦你一下——这个操作的影响面是整个系统，不是一个集团。

逻辑系统本身不参与业务数据，它只在需要“标识数据从哪来、到哪去”的场景里被引用：ALE/IDoc 的收发方、RFC 目标、BDLS 批量转换、以及集团之间的数据分发。如果你的规划里根本没有跨系统集成，逻辑系统可以只定义不启用；但只要将来要做 IDoc 或者跨系统 RFC，这一步就必须在拷贝前定好，因为后面再改，涉及的表要重新对齐。

至于集团角色（Client Role），那是另一回事。它决定了这个集团“是什么身份”：生产、测试、定制、演示还是 SAP 参考。角色不同，系统对“允不允许改跨集团对象”的默认态度就不同。790 的定位是定制和测试，选 Customizing 或 Test 都合理；选 Production 会让系统按生产环境的规则收紧权限，后面做定制会处处受阻。

2.3 用 SCC4 和 T000 交叉核对：别只信界面上显示的那几行

SCC4 是集团管理的总入口，SALE 里“Assign Logical System to Client”打的是同一张底表 T000，只是入口不同。两个入口改的是同一份数据，从哪个进去都能改，但改完一定要从另一个入口复核一遍——这不是多此一举，我遇到过界面显示已保存、实际字段没落库的情况，多半是没走完保存确认。

要批量核对，开个临时报表比一屏屏翻界面靠谱：

" 临时报表：批量核对集团主数据，SE38 新建后直接执行 REPORT zcheck_client_list. DATA: lt_t000 TYPE TABLE OF t000, ls_t000 TYPE t000. SELECT mandt mtext ort01 mwaer cccategory logsys FROM t000 INTO TABLE lt_t000 WHERE mandt IN ('000','790'). LOOP AT lt_t000 INTO ls_t000. WRITE: / ls_t000-mandt, ls_t000-mtext, ls_t000-cccateg, ls_t000-logsys. ENDLOOP.

这段代码做的是从 T000 里把两个集团的关键字段拉出来并排打印。MANDT是集团号，MTEXT是集团描述，ORT01是城市字段（填内部厂区代号即可，别填真实地址），MWAER是集团货币，CCCATEGORY是集团角色，LOGSYS是刚分配的逻辑系统。执行前把WHERE里的集团号换成你自己的；字段名以 SE11 里 T000 的实际定义为准，不同版本可能有细微差异。

核对的重点是三项：LOGSYS是否真的写进去了、CCCATEGORY是否和规划一致、MWAER是不是你想要的币别。这三项里任何一项为空或者不对，后面 SCCL 跑完都会留下隐患——逻辑系统为空，将来的 IDoc 找不到归属；角色填错，跨集团对象改不动。

3. 动手前的环境准备：SU01 建专用账号、RZ10 解锁 SAP*、重启前先验三个点

拷贝本身只要点几下，真正花时间的是准备。准备工作没做到位，最典型的翻车方式是：SCCL 排完程，去 790 登录，发现 SAP* 进不去，然后开始满网找“SAP* 密码是多少”，找到的资料互相打架。这一节把账号和参数这两件事拆开讲清楚。

3.1 为什么不该硬用 DDIC 做拷贝，而要用 SU01 复制一个专用账号

DDIC 和 SAP* 是系统装完就带的两个管理员账号，密码在安装过程中设定。问题在于，DDIC 是给“系统级维护”用的，很多定制操作在权限设计上就不鼓励用它，而且它是 000 集团里的用户——如果你在拷贝时选了带用户主数据的 Profile，000 的用户会被一并搬过去，密码策略、锁定状态、角色分配全跟着走，到时候 790 里一堆用不上的账号，清理起来很烦。

常见做法是用 SU01 复制一个专用账号，比如叫 CUS01，专门用于拷贝和后续定制。步骤不复杂，但每一步都有讲究：

复制用户时最容易忽略的是“用户类型”。如果复制出来的账号是 System 类型，后面用 SAP GUI 登录会失败，因为它不允许交互登录。另外，复制过来的角色是源用户的角色快照，DDIC 身上那些角色未必覆盖所有定制事务码，SCCL 排程之前先用 CUS01 跑一遍 SALE、SCC4、SCCL，能提前发现权限缺口。

还有一个边界要提：如果你在 SCCL 里选的 Profile 是 SAP_USER 或 SAP_ALL，目标集团里的用户主数据会被源集团覆盖。这意味着你在 790 里提前建好的账号，跑完拷贝可能就没了，或者密码被重置成源集团的。所以顺序一定是“先拷贝、后建账号”，反过来做等于白做。

3.2 RZ10 里那个参数：login/no_automatic_user_sapstar

新装的 ECC 系统，SAP* 在某些集团里是登录不了的。原因不是密码错，而是系统参数把“自动创建 SAP*”这个行为关掉了。控制它的参数是login/no_automatic_user_sapstar，值为 1 时禁止自动创建，为 0 时允许。

这个参数的设计意图是安全：生产系统里绝不应该存在一个密码公开的 SAP* 账号。但在刚装好的开发/测试系统里，你需要它来进 790 做第一次登录。取值和生效方式如下：

改参数的路径是 RZ10 → 菜单 Utilities → Import profiles → of active servers。这一步很多人跳过，直接进 RZ10 就找 Profile，结果搜索帮助里一片空白——因为活动服务器的参数文件还没导入到当前会话里。导入之后，用 Profile 的搜索帮助选中当前实例的参数文件，名字形如<SID>_DVEBMGS00_<主机名>，进“扩展维护”（Extended maintenance），点修改，新建一行参数，填名字和值，保存。

保存完不要急着去登录 790。RZ10 保存的只是参数文件，实例还没重新读取它。正确顺序是：保存 → 确认参数已写入活动参数文件 → 停实例 → 起实例 → 再验证。

3.3 重启之前先确认三件事，别把时间浪费在反复重启上

重启一套 ECC 实例在生产环境是要走流程的，在测试环境也不轻松，动辄十几分钟。所以重启前把能验的都验掉：

第一，用 RZ10 的 Display 模式打开参数文件，确认新加的那一行确实在列表里，值没有多余空格。参数名和值里混进空格是常见的手误，系统不报错，但参数不生效。

第二，用 RZ11 查这个参数的“当前值”和“当前值来自哪个 profile”。RZ11 显示的是运行中的实例实际在用的值，如果它还是 1，说明参数文件没被读进去，重启也是白重启。

第三，确认没有其他参数文件也在定义同名参数。SAP 的参数可以出现在多个 profile 里，后加载的会覆盖先加载的。如果 DEFAULT profile 里也有一份login/no_automatic_user_sapstar = 1，你改的那个实例 profile 可能被覆盖。

提示：改完参数重启后，用 SM21 看一遍系统日志，确认启动过程中没有参数解析相关的警告。有些参数写错格式不会阻止启动，只在日志里留一行，很容易被忽略。

4. 从 000 到 790 的实操：SALE 定义逻辑系统、SCC4 落参数、SCCL 排程、SCC3 盯日志

准备工作做完，进入正题。这一段的顺序不能乱：先定义逻辑系统，再把逻辑系统挂到目标集团，然后确认集团角色和币别，最后才是 SCCL。每一步保存时都会问你要 Request，这是正常现象，不是报错。

4.1 SALE 里定义逻辑系统：两个 New Entries 的区别

执行 SALE，路径 Basis Settings → Logical System → Define Logical System，系统弹出跨集团表警告，回车继续。点 New Entries，填两列：逻辑系统名（比如 QAS）和描述。描述随便写，但建议写成“用途 + 建立日期”，将来别人看到能判断该不该删。保存时会要求指定一个定制请求，新系统没有现成请求就新建一个，命名上带个日期前缀，方便追溯。

第二个 New Entries 在 Assign Logical System to Client 里。这一步是把逻辑系统“挂”到某个集团上，本质上就是改 T000 的 LOGSYS 字段。界面上会列出系统里所有集团，前三个通常是 000、001、066 这类系统自带的，不要动。点 New Entries 新增一行，把集团号填成 790，描述、城市、货币、集团角色一并填上。

这里有个细节值得注意：这个界面和 SCC4 的界面长得非常像，因为它们改的是同一张表。如果你先在这里建了 790，再进 SCC4 看，会发现 790 已经存在；反过来也一样。所以不存在“两边都要建一次”的问题，但要养成“建完从另一个入口复核”的习惯。

保存时系统会再弹一次“更改逻辑系统时请小心”之类的提示，回车即可。看到 “Data was saved” 才算真正落库。

4.2 SCC4 里的参数：角色、保护级别、跨集团修改权限

如果 4.1 里已经把参数填全，这一步是复核；如果没填全，在 SCC4 里补齐。关键字段的含义和取值如下：

币别这一项需要特别说明。原文里填的是人民币，这在本地化项目里合理，但要确认源集团 000 的币别和它是否兼容。集团货币影响金额类字段的解读方式，拷贝完成后如果发现金额显示异常，第一件事就是回来看这里。

保护级别选 0 是测试集团的常规做法，意味着系统不对“改跨集团对象”设额外限制。如果这个集团将来要承接接近生产的验证，可以把级别调到 2，代价是每次改跨集团配置都要走请求。

4.3 SCCL 参数页：Profile、源集团、目标集团，以及那个容易被忽略的 Test Run

执行 SCCL（Local Client Copy），界面上的字段不多，但每一个都影响结果：

Profile 的选择是这一步最需要想清楚的：

• SAP_ALL 拷全部，包括定制、应用数据、用户主数据。适合“我要一个和源集团一模一样的副本”。
• SAP_CUST 只拷定制，不拷业务数据和用户。适合“我要一套干净的配置做参考”。
• SAP_USER 只拷用户主数据。适合“配置我自己做，但用户和权限想复用”。
• SAP_APPL 拷应用数据，通常和 CUST 配合用。

第一次做，我建议先勾 Test Run 跑一遍。模拟运行会完整走一遍权限、RFC、目标集团状态的检查，几分钟出结果，比排了后台作业等两小时再失败划算得多。模拟生成的日志同样在 SCC3 里看，日志里会明确写“这是模拟运行”。

模拟通过后取消 Test Run，点 Schedule as Background Job。系统会让你选立即执行还是定时执行，选立即，然后一路回车。最后系统会告诉你用 SCC3 看日志，这句话是整个流程里最重要的一句提示。

4.4 SCC3 日志怎么读：三个阶段和几个关键字

SCC3 的日志不是一条流水账，它按阶段组织。看懂阶段划分，就知道现在该等还是该处理。

第一阶段是准备：检查目标集团状态、检查源集团可用性、检查 RFC 连接、计算要拷的表清单。这一段通常几分钟内结束，如果卡住，八成是目标集团不为空，或者并行处理的 RFC 服务器组没配好。

第二阶段是表拷贝：日志里会滚动显示正在处理的技术表名和对数。这个阶段最耗时，与数据量强相关。判断“是不是卡死了”的方法不是看日志不动，而是去看 SM37 里作业状态是不是还在运行、SM50/SM66 里有没有活跃的后台进程。日志按批次刷新，不动几分钟很正常。

第三阶段是后续处理：生成索引、激活程序、重建缓存。这一段容易被误判为“已经跑完”，其实还有收尾工作。日志最后出现“Client copy completed successfully”一类字样才算真正结束。

注意：日志里出现黄色的警告行不要一律忽略，尤其是提到“table could not be copied”的行。某些技术表拷不过去不影响启动，但会影响特定功能，事后排查成本很高。

5. 避坑排查：Client Copy 里最容易翻车的五个现场

这一段是血泪经验密度最高的部分。下面五条都是“现象 → 原因 → 解决”的顺序，照着对号入座，能省掉大量搜索时间。

5.1 现象：790 里 SAP* 登录提示用户或密码错误

原因通常不是密码错，而是三个条件里缺了一个：参数login/no_automatic_user_sapstar没生效、790 里已经存在一个叫 SAP* 的用户（那就不会自动创建，而是用已有密码）、或者实例根本没重启。

解决顺序是倒着查：先用 RZ11 确认参数当前值是不是 0；再回 000 用 SU01 查一下 SAP* 是否存在、是否被锁定；最后确认实例重启时间晚于参数保存时间。如果 790 里已经存在 SAP* 但密码未知，用 000 的 DDIC 登录后执行 SU01，把 790 的 SAP* 删掉或重置密码，再重新登录。这里有个前提：删除用户需要跨集团权限，如果你连这个都没有，说明账号权限本身就没配够。

5.2 现象：SCCL 报目标集团已有用户数据，拒绝执行

原因是 790 不是“空集团”。SCCL 的语义是往一个干净集团里灌数据，目标集团里只要有业务数据或用户数据，系统就会拦。常见触发场景是：先建了 790，随手用 SAP* 登进去建了几个账号，然后再去跑拷贝。

解决办法是在 SCCL 里把目标集团清空，或者在拷贝前就不要往 790 里写任何东西。清空用的是 SCC5（Delete Client），删之前确认选的是 790 不是 000，这个事务码没有回收站。删完再重新走一遍 SCC4 的参数确认，因为删除会重置部分字段。

5.3 现象：拷贝跑到某个表就不动了，SM37 显示作业还在运行

原因可能是真卡住，也可能是正常的大表处理。区分方法是看 SM50/SM66 里有没有活跃的后台进程在跑，以及数据库层面有没有对应的长事务。如果进程在动、只是日志不刷新，等着就行。

如果确认是真卡，最常见的原因是并行处理配置有问题：RFC 服务器组里的目标服务器不可达，或者并行进程数和系统资源不匹配。解决方式是取消作业，把 Parallel Processing 关掉，用单进程重跑一遍验证数据是否正常，再逐步加并行度。另外，源集团 000 里如果有被锁定的表或者正在进行的重组操作，也会让拷贝停住，跑之前用 SM12 看一眼锁。

5.4 现象：拷贝完成后业务单据号跳号或者撞号

原因是编号范围。编号范围对象的定义是跨集团的，但当前编号级别是按集团存的。拷贝会把源集团的编号级别带过来，如果目标集团之前已经产生过单据，或者同一个号段被两个集团同时消耗，就会出现跳号甚至重复。

解决办法是拷贝完成后立刻核对关键编号范围对象：用 SNRO 查对象定义，用 SNUM 看当前级别，重点看 MM、SD、FI 相关的单据类型。发现异常的，用 SNUM 手工调整到安全区间，或者干脆在测试集团重置信封。这件事必须在业务测试开始前做，等业务单据跑起来再改，清理成本翻几倍。

5.5 现象：拷贝后 ALE/IDoc 报“逻辑系统未定义”或“伙伴参数缺失”

原因是逻辑系统只在 SALE 里定义了一半：定义了系统，但没挂到集团上，或者挂了但没在伙伴参数里引用。拷贝过程中 T000 的 LOGSYS 字段如果没有正确落库，新集团就是“没有身份”的状态。

解决办法是回 SALE 复核两处：Define Logical System 里 QAS 是否存在，Assign Logical System to Client 里 790 那一行的 LOGSYS 是不是 QAS。然后到 WE20 里检查伙伴参数，确认逻辑系统被正确引用。如果做过 BDLS 转换，还要确认转换后的逻辑系统名和当前定义一致——BDLS 改的是存量数据里的逻辑系统名，不会自动更新配置表。

6. 拷完别急着交付：用 SCC3 日志加表比对做一次十分钟自检

拷贝跑完、日志显示成功，很多人就直接把集团交给业务了。我的习惯是再花十分钟做一次自检，成本极低，能挡掉大部分“交付后第一天就出问题”的尴尬。

自检清单按优先级排：

如果想把逻辑系统这一项查得更彻底，可以再跑一段查询，把集团和逻辑系统的对应关系打出来：

" 交付前核对：集团与逻辑系统对应关系 REPORT zcheck_client_logsys. DATA: lt_t000 TYPE TABLE OF t000, ls_t000 TYPE t000. SELECT mandt mtext logsys cccategory FROM t000 INTO TABLE lt_t000 WHERE mandt = '790'. LOOP AT lt_t000 INTO ls_t000. WRITE: / 'Client:', ls_t000-mandt, 'LogSys:', ls_t000-logsys, 'Role:', ls_t000-cccateg. ENDLOOP.

这段只查 790 一个集团，输出三列：集团号、逻辑系统、集团角色。LOGSYS为空说明 4.1 那步没落库，CCCATEGORY不对说明角色选错。两个字段都可以在 SCC4 里直接改，改完记得保存并复核。

我踩过最贵的一次坑，不是拷贝失败，而是拷贝“成功”了但没验逻辑系统，结果两周后做 IDoc 接口联调时才发现 790 没有身份标识，所有消息都发不出去，回头补配置又得重新对齐伙伴参数。从那以后我每次做完 Client Copy，不管日志多漂亮，都强制把 T000 这三列打出来看一眼再交付。希望帮到你。

本文还有配套的精品资源，点击获取