企业官网建设流程全解析

简介：《SAP集团拷贝（Client Copy）操作指南》是一份面向SAP Basis顾问、系统管理员及初学者的实操文档，系统梳理了在ECC 6.0环境中复制客户端的完整流程，解决测试、定制与开发环境搭建问题。资源为单个doc文档，共1个文件，压缩包大小776KB，内容以图文步骤为主，便于对照操作。已有629人学习，适用于需要在新集团中开展MM流程定制或程序开发的人员。文档从逻辑系统定义、分配客户端、参数配置到登录新集团均有详细说明，并特别整理了SAP*账号启用、跨客户端表修改等易错环节，帮助规避常见排错坑。

1. SAP集团拷贝：从复制一个测试集团开始的全链路排雷

SAP集团拷贝（Client Copy）听起来像是项目快收尾时管理员才会碰的操作，但做过业务定制的人反而最清楚，一个新环境的落地几乎都要从这个动作开始。它的价值很直白：把现有集团（通常是000）完整复制成一个新集团，比如790，然后在这个新集团里做定制、开发、测试，完全不影响生产数据。有人叫它客户端复制，有人叫它Group Copy，本质上都是同一件事。但这件事远不是“装完ECC服务器后点个按钮”那么简单：逻辑系统定义、请求号处理、SAP*默认密码策略、跨客户端表提醒，每一环节都有隐藏前提，而且很多网上资料互相转载之后已经丢失了原版的有效信息。这篇笔记拆的是ECC6.0 32位环境下一份完整的Client Copy操作流程，从账号、配置到后台复制，把关键参数和踩坑点一次说清。

2. 动手前的三道闸门：账号权限、系统变更与跨客户端数据

在真正运行SCCL之前，很多人会直接跳到“定义逻辑系统”这一节，结果复制过程中被权限和跨客户端锁卡住。我习惯先把三件事摆平：谁能做定制、系统允不允许改、跨客户端表改了会有什么连锁反应。

2.1 管理员账号的限制：为什么DDIC都未必能直接改系统

安装完ECC6.0之后，系统自带两个初始管理员账号DDIC和SAP*，密码是安装环节设定的。按官方设计，这两个账号承担的是系统初始化和紧急恢复任务，正常情况下并不鼓励拿它们去维护业务定制和集团参数。原因其实很朴素：如果所有人都用超级管理员改配置，哪天一个误操作把跨集团的表改错了，排查时连责任边界都找不到。SAP把DDIC和SAP*定位成“系统级管理员”，对Customizing动作默认受限，这属于设计如此，不是故障。

举个例子，当你用DDIC登录后运行SU01去复制一个新用户，这件事本身没问题；但你用DDIC直接去SALE里定义逻辑系统，系统不一定拦你，却可能在后面对集团属性做修改时遇到无法保存的情况。尤其在一些ECC6.0早期版本里，DDIC对客户端相关的表（比如T000、T001、T003）并不具备完全写入权限。所以标准做法是：先用DDIC登录，在SU01里复制出一个带完整权限的操作账号，之后所有Client Copy相关操作都通过这个新账号来做。

2.2 SU01复制新ID的操作细节

SU01是SAP用户维护的主事务码。在DDIC登录状态下输入SU01，进入用户维护界面。此时不要点“新建”，而是先输入一个新账号名，比如NEWDEV，然后点界面上的“复制”按钮。系统会弹出一个源用户选择窗口，让你指定要复制哪个现有用户的字段。这里选一个有SAP_ALL或完整管理员权限的用户作为模板，复制按钮才会把角色、参数文件、默认打印机、用户组这些基础设置一并带过来。

复制完成后，系统会进入该用户的详细维护界面，你需要重新设置一个初始密码。密码策略方面，新版本SAP要求最少八位且同时包含字母和数字，如果输入得太简单，保存时就会弹出密码不合规的报错。这个新账号建议放在一个独立用户组里，不要直接塞进SUPER组，否则后续限制790集团登录时会连带影响这个管理员账号。保存后再用这个新账号登录一次，确认能顺利进入系统，再做下一步。

有人会跳过复制，直接新建一个空白用户然后手配角色。我不推荐这个做法，因为一个完整的SAP管理用户往往涉及几十个授权对象，手动补齐很容易漏。复制模板用户，再按项目需要增删角色，是最稳妥的动作。

2.3 跨客户端数据：逻辑系统表不是一个集团说了算

定义逻辑系统之前，系统会弹出一行提示：Caution: The table is cross-client。直接翻译是“注意：此表是跨集团的”，但它背后的含义比字面更深。当前这张表的存储结构是数据库级别的，不属于任何一个具体集团，也就是说，你用集团790的身份去维护这张表，写进去的内容对其他集团（000、001）也立刻生效。反过来，别的集团改了这条记录，你的790也会跟着变。

正是因为这个特性，逻辑系统的定义和分配才被单独拎出来作为Client Copy的前置条件。如果你在维护逻辑系统时不小心改到了生产集团正在使用的记录，影响范围可能横跨多个环境。我曾在一次操作中，图省事复用一个已有逻辑系统名称，结果生产侧的角色同步开始报错，最后花了一个多小时才定位到是逻辑系统归属被串了。从那以后，我每次做Client Copy都先导出系统里现有的逻辑系统列表，确认要新建而不是套用一个已有名称。

2.4 系统变更选项：复制完却改不动配置的隐藏原因

另一个容易被忽略的准备工作是系统变更选项。SAP中有几个控制“是否允许修改”的总开关，尤其是针对Repository对象和跨集团Customizing对象的。如果系统当前处于“不允许修改”状态，复制完成后的790集团即使Client role设成了Customizing，你进入配置界面去改一条物料组或会计设置，保存时仍然可能被拒绝，报错往往是“对象已锁定”或“修改不活跃”。

这类总开关一般通过SE03或SE06维护，窗口名称通常是“系统修改选项”。在做Client Copy之前，先把跨集团对象修改设为允许，否则复制出来的集团只是一个“能看不能动”的空壳。如果你以后还要在790上跑SECATT自动化测试，分配集团参数时还要明确允许CATT和ECATT，不然后期录制测试脚本时会发现录制功能根本启动不了。

2.5 动手前的备份习惯

最后一个准备动作是备份。字面上，这指的是复制开始前给数据库做一次一致性备份。这不是可选步骤，而是必选步骤，因为SCCL复制过程中一旦遇到网络中断、磁盘耗尽或数据库锁冲突，目标集团可能留下一堆半成品数据。最坏情况下，传输请求队列也可能被锁住，影响后续所有传输任务。

常见的备份手段有两种：一是数据库级别的完整转储，这是最安全的兜底；二是利用SAP传输系统加表级导出做增量保护。我习惯在动手前先确认备份已完成并有日志记录，再开始后台作业调度。这个动作看着不起眼，但真到复制中断需要回滚时，它是唯一的后悔药。

3. 定义逻辑系统与分配客户端：SALE事务里的两个关键动作

准备动作扎稳之后，就进入SALE事务码操作。这一章包含两个动作：第一是定义逻辑系统，第二是把逻辑系统分配给集团。很多人把这两步混在一起做，或者干脆跳过其中一步，结果就是SCCL运行时报出各种奇奇怪怪的错误。

3.1 定义逻辑系统：命名、Request和跨集团提示的完整处理

在事务码SALE的左侧菜单里，按Basis Settings → Logical Systems → Define Logical System展开，双击进入后，系统会先弹出一条跨客户端警告。这个弹窗在多个步骤都会出现，很多新手的反应是不敢继续，其实它只是一个确认提示，按回车或点击确认即可继续操作。

进入维护界面后，点击“New Entries”，你会看到两个输入字段：Logical System和Name。前者是逻辑系统的技术名称，建议按照项目命名规范来取，比如“QASCLNT790”这样既能看出用途又不和其他系统混淆的名称。后者是描述文本，可以写“测试集团790使用的逻辑系统”这类可读性强的说明。需要特别注意的是，Name字段不要写太过随意的内容，因为后续在多个配置界面都会引用这段描述，写清楚能省掉很多沟通成本。

保存时一定会遇到请求号的选择。如果当前系统里已经存在可用的修改请求，系统会弹出列表让你选；如果是全新安装还没有创建过任何Request，系统会引导你新建一个再保存。这一步是SAP标准动作，不要图省事跳过。有些转载教程把请求号处理作为可选项省略了，这是不负责任的。在ECC6.0的默认环境下，直接保存配置表而不挂请求号，虽然偶尔能成功，但后续一旦涉及传输链或系统复制，请求记录缺失会造成版本对不上，排查起来极麻烦。

保存成功后，系统通常会给出一个请求号。建议用SE03或SE10记下这个请求号，后续做传输或系统复制时可能会用到。

3.2 Assign Logical System to Client：790集团参数逐项拆解

定义完逻辑系统后，回到SALE菜单，进入Basic Settings → Logical Systems → Assign Logical System to Client。这一步是把逻辑系统绑定到具体集团，同时维护新集团的属性。系统同样会弹出一条跨系统警告，直接确认继续。

进入界面后，左侧列表会显示系统里现有的所有集团，前三个是系统初始自带的000、001、066等。点击“New Entries”新增一行，此时系统会进入集团明细维护界面，这一界面的参数较多，建议逐项确认，不要一路回车。下面是一组我在ECC6.0环境里实测可用的参数对照：

保存时系统会弹出“当更改逻辑系统时小心”的提示，因为逻辑系统一旦绑定，就会影响集团间通信和ALE配置。确认无误后直接回车。再留意一下界面下方的保存反馈，看到“Data was saved”或类似成功提示，才算真正落库。

3.3 保存后验证：SCC4与SE03双重确认

保存完不要急着退出，先用事务码SCC4确认790集团的记录已经写入。SCC4是集团维护的主入口，如果之前在分配界面里新建过790，这里应该能看到这条Client记录。重点核对三项内容：逻辑系统是否指向QASCLNT790、Client role是否为Customizing、跨Client对象修改是否允许。只要其中一项不对，后续SCCL跑完后你就会在登录或配置阶段遇到诡异的问题。

如果SCC4里看不到790，说明之前新建的记录没有真正持久化。回SALE重新走一遍分配流程，确认请求号已经生成并保存后再回到SCC4检查。这个过程看着多了一步，但能避免后面复制完才发现集团属性设置不对而返工。

3.4 逻辑系统命名的常见约定与实际用法

很多第一次做Client Copy的人会问：逻辑系统名称到底能不能随便取？理论上，它只是一个标识符，只要在系统内唯一即可；但在实际项目中，逻辑系统名称往往与ECC服务器标识、业务用途绑定在一起。比如某公司以QAS开头表示质量保证环境，以PRD开头表示生产环境。这样命名的好处是，后续在做系统间接口配置时，扫一眼逻辑系统名就能判断数据的来源和去向。

我在这个系列资源里沿用了QAS这个名称，目的就是保持阅读视角一致。如果你所在项目已有命名规范，请按项目规范走，不要照搬这里的示例值。逻辑系统是跨集团表数据，一旦在项目中期被多个集团引用，再想改名就要动表数据，代价非常高。

4. SAP*登录受限：RZ10参数与重启启用的完整解法

第3章完成之后，790集团在系统里已经有了身份。此时你满怀期待地用SAP和默认密码去登录790，结果大概率进不去。这不是密码敲错了，而是全新安装的ECC6.0对SAP默认关闭。你需要在000集团后台通过RZ10调整参数，然后重启服务器，才能恢复默认访问。

4.1 现象分析：SAP*不能登录背后是安全参数在起作用

在ECC6.0标准安装中，SAP用户默认被限制自动登录。系统参数login/no_automatic_user_sapstar的默认值是1，表示SAP不自动注册，即不允许使用初始密码直接登录系统。这是SAP的安全设计，防止新装系统被默认密码直接攻破。

但这个设计也带来一个现实问题：你刚复制出来的790集团，还没来得及创建正式用户，除SAP以外没有其他账号能登录。要进入790，就得先把参数临时改为0，允许SAP用安装时设定的密码登录，然后重建用户数据，再把参数改回1。这个参数改完不会立即生效，必须重启SAP实例，重新读取参数文件后才会起作用。如果改完参数忘记重启，登录时依旧会提示SAP*密码错误，白白折腾半天。

4.2 RZ10导入活动服务器Profile

第一步用DDIC登录000集团，运行事务码RZ10。RZ10是SAP实例参数文件的维护界面。新装系统里，参数文件可能还没有被导入到RZ10的管理列表中，所以需要先做一次导入操作。

在RZ10菜单中，按Utilities → Import profiles → of active servers，系统会读取当前活动服务器上已有的profile文件，并导入到RZ10管理列表。导入完成后，系统会显示一条“Profile import executed correctly”的确认信息。此时回到RZ10主界面，点击Profile栏的搜索帮助，就能看到已加载的参数文件名列表了。

如果你是新装系统没有执行过上面的导入操作，那个搜索帮助通常是空的。参数文件名一般由几段组成，比如“系统标识_实例类型_计算机名”这种结构。你不用管前缀是几位字母，只要选中当前活动实例对应的那个profile即可。如果不确定选哪个，可以从文件名里找到和你系统ID一致的条目。

4.3 扩展维护与参数修改：把login/no_automatic_user_sapstar置为0

选中参数文件后，会进入参数维护界面。此时默认是显示状态，需要先选择“Extended maintenance”扩展维护，再点“Change”按钮，系统才会允许新增或修改参数条目。

点击创建参数按钮，进入参数新增界面。用搜索帮助选择参数名“login/no_automatic_user_sapstar”，然后在Parameter value字段里填入0。这里要注意，不要直接关闭Search Help后手动拼写参数名，很容易打错。填完点击Copy，系统会提示参数已添加，返回后保存这个参数文件的修改。

参数值的含义很简单：1表示SAP登录被拒绝，0表示允许SAP登录。这里改的是“允许自动登录”，而不是“永久放开SAP*账号”。等790集团里的正式账号创建好、复制过程验证无误之后，建议再回到RZ10把这个参数改回1，恢复安全默认值。

4.4 保存参数文件与重启SAP实例的先后顺序

参数保存后，系统会提示是否需要重启实例。这里不要心存侥幸，必须重启。在Unix/Linux服务器上，常见做法是执行stopsap和startsap脚本；在Windows环境下，则通过SAP服务管理器执行停止和启动操作。下面是一个Unix环境下的常规操作序列：

# 停止SAP实例，R3替换为你的系统标识 stopsap R3 # 检查后台进程确实退出，避免残留进程影响启动 ps -ef | grep -i sap | grep -v grep # 重新启动SAP实例，实例启动时会重新读取参数文件 startsap R3

这段操作里，R3是系统标识的占位符。执行stopsap后，建议等30秒左右再检查进程列表，确保所有SAP服务都已退出；如果还有残留进程，需要先清理再执行startsap，否则实例启动时可能因为端口占用而失败。

重启完成后，用SAP*和安装时设定的密码登录790集团，应该就能顺利进入了。如果仍然被拒绝，去RZ10的参数文件里确认一下login/no_automatic_user_sapstar的值是否真的改为了0，以及保存时是否选择了正确的profile。还有一种情况是参数写入了非活动profile导致未生效，这种情况需要检查profile文件的实际加载状态。

需要提醒的是，重启过程会中断其他集团的在线会话。尽量选择业务空窗期操作，并提前和项目组确认没有正在执行的传输或后台作业。

5. Client Copy避坑记录：SCCL后台作业与四个高频翻车点

登录790成功之后，SCCL才是真正开始复制数据。但在实际执行中，许多问题不在复制本身，而在准备和收尾。这些问题单看每一步都不复杂，组合在一起却容易让人反复折腾。我把高频出现的几个坑按“现象 → 原因 → 解决”的方式整理在下面。

5.1 现象：SCCL直接报错，目标集团缺少逻辑系统分配

有人直接在SCC4里创建了790集团，跳过了逻辑系统定义和分配步骤，就运行SCCL。复制作业可能立刻中止，弹出的日志里显示目标集团缺少逻辑系统分配之类的错误。这个错误出现的频率很高，原因在于SAP要求每个参与Client Copy的集团都必须绑定了逻辑系统。这是传输和ALE主数据建立的基本前提，没有它，复制流程根本走不下去。

解决方法是回到SALE，把之前定义的逻辑系统正确绑定到790集团，然后再跑SCCL。这一步看着多余，实际上却是整个操作流程里最核心的前置条件。绑定完成后，可以在SCC4里复查逻辑系统字段是否已经显示出来。

5.2 现象：后台作业一直在排队，看不到实际运行日志

在SCCL界面点击“Schedule as Background Job”后，你选了立即执行，但到SM37里看，作业一直处于排队状态，迟迟不走。这种情况常见原因有三个：一是后台作业服务器上对应的作业优先级被拉得太低；二是实例上没有足够的后台工作进程；三是系统时间不同步，作业被自动排到了未来时间。

解决方法是先进入SM37后台作业管理界面，找到对应的复制作业，查看计划时间与实际执行时间是否一致。如果确认是时间问题，可以取消后重新按“立即”调度；如果是进程不足，则换一台负载较低的应用服务器重新调度。SAP集团复制是数据库密集型操作，不建议和大量报表或接口作业挤在同一台实例上执行，否则速度会慢到让人怀疑卡死。

5.3 现象：复制到一半提示表锁或主键冲突

SCCL执行过程中，日志里出现特定表名，并伴随“lock”或主键冲突消息，多半是因为有用户正在目标集团上操作数据。SAP的Client Copy在复制数据时会占用目标集团相关表的锁，如果这个时候有人正在790集团里跑程序或维护主数据，双方就会发生锁冲突。

最常见的处理方式是：复制前先把目标集团的所有会话踢出，或者直接通过SM37设置目标集团为“登录受限”，等复制完成后再放开。SCCL本身并不强制要求目标集团无人登录，但为了数据一致性和避免锁表，这个步骤属于行业惯例。我在做过一次因用户在目标集团跑报表而导致复制中断之后，就再也没跳过这个动作。

5.4 现象：复制日志显示成功，但登录后部分配置是空的

这是最让人头痛的情况——SCC3日志里全绿，看起来复制很成功，但进入790后，某个IMG配置节点却是空的，比如物料管理后台的一些参数没过来。排查之后才发现，问题出在复制类型的选择上。SCCL复制类型很多，有只复制定制数据的，有只复制用户主数据的，也有复制全部应用数据的。如果启动前选错了复制类型，那定制的表可能复制了，业务数据和项目特定参数却没有跟着过来，日志自然不会报错。

在ECC6.0的Client Copy场景里，最常见的完整复制类型是SAP_ALL，它会把定制和应用数据一并复制；但如果你只需要复制定制给开发顾问用，选SAP_CUST反而更快。所以启动复制前，务必明确这次复制的目标范围，而不是默认选完整复制。发现配置缺失之后，核对SCCL界面里选择的复制类型，再补跑缺失部分即可。

5.5 现象：网上教程互相矛盾，照搬旧步骤总是卡住

最后一条，专门说给喜欢沿用旧教程的人。网上关于Client Copy的资料来源高度重合，大量转载没有验证过，甚至把错误原样放大。比如请求号处理、逻辑系统定义位置、SAP*密码重置方法，不同版本之间经常互相矛盾。遇到这种资料时，坚持以当前系统版本的报错信息和界面提示为准。

尤其要注意“忽略警告”和“忽略必填字段”的区别。系统弹窗提示“跨集团表”时，确认后继续是安全的；但如果是保存时提示必填字段未维护，那就得补上再保存。我的习惯是，每到一个新版本服务器，先手工在SAP里点一遍最小路径——比如从定义逻辑系统到分配集团——确认界面无误后，再把完整流程写成项目内部笔记，供团队复用。这个过程能拦住至少一半的“复制后登录失败”和“复制后配置缺失”问题。

6. 复制后验证与定制收尾：SCC3日志阅读的固定三步

SCCL作业跑完之后，最后都要靠SCC3来验明正身。SCC3这个事务码，查看的是Client Copy的日志，但如果你只是看一眼“作业完成”，就认为拷贝百分百成功，迟早要吃教训。

我一般会在SCC3里固定做三步。第一步，看整体状态，列表里复制作业的状态应该显示“完成”或绿色标识。第二步，点进作业明细，逐表看复制行数，尤其是用户主数据表和物料基础表，例如USR01、USR02、MARC、MARA这些关键表。如果某张表的已复制行数和源集团不一致，先别急着认为复制成功，要么重新补一次表级复制，要么检查是否存在传输范围排除导致的部分表未复制。第三步，确认日志记录时间和实际执行时间吻合，防止作业是在参数文件重启之前启动，导致它读到的还是旧参数。

这三步操作花不了几分钟，但能捕捉到绝大部分隐患。确认790集团的配置和数据都完整复制之后，再继续后面的定制和开发。从这以后，我每次给新服务器复制集团，都会强制走一遍“SCC3三步验证”，而不是看到作业结束就退出——验证这一步，才是保证后续所有定制工作不白做的根基。

希望这份从准备到执行的笔记，能帮你在下一次Client Copy时少走几个弯路，少翻几次车。

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