企业官网建设流程全解析

简介：一份面向SAP系统使用者与初学者的操作学习笔记（docx格式），围绕归档数据查看、后台作业管控、物料账与会计账开启、物料主数据设置等高频实务展开。笔记整理了SAP关键事务代码（如SM37、F-60、OMSY、MMPV、OX18、FBN1）的实际用法，并针对销售订单、交货单、物料凭证、会计凭证等对象的归档顺序与查看方法给出具体指引，可帮助读者避免常见操作错误，提升数据审计与日常运维效率。内容还涉及后台作业Active状态的停止与强制取消、英文环境下物料主数据单位的处理，以及公司代码下PLANT列表的查询，均为真实工作中容易卡壳的细节。资源为1个docx文档，压缩包仅96KB，轻量易用，适合作为工作中随时查阅的速查手册。目前已有199人学习浏览，内容源于真实工作场景中的问答与排错经验，对希望快速熟悉SAP核心操作的读者具有较强参考价值。

1. 这套 SAP 学习笔记，为什么值得照着归档、作业和权限三个方向重做一遍

严格来说，这份“SAP学习笔记”不是一本系统教程，而是把十几年前一批运维人员在实际系统里反复试错后留下的问答记录汇总在一起。里面没有长篇原理，全部是真实操作：归档销售订单看不到数量、SM37 里的 Active 进程怎么都删不掉、物料账开不了、SAP* 口令忘记怎么办。这些场景放到现在的 S/4HANA 或 ECC 环境里依然成立，因为核心事务码和表结构没有根本性变化。如果你正在做 SAP 后勤或 Basis 运维，这份笔记最值钱的地方在于：帮你把别人踩过的坑提前踩完，尤其是归档顺序、后台作业强杀和系统参数修改这三块。

2. 数据归档与后台作业：从归档对象到 SM37 强杀的完整闭环

2.1 归档对象怎么选：SD_VBAK、RV_LIKP、SD_VBRK、FI_DOCUMNT 的对应关系

SAP 的归档不是直接删表，而是把业务数据从活动表写入归档文件，再由归档对象管理。每个业务单据都有对应的归档对象，选错对象会导致“系统不让通过”。这份笔记里提到的几个对象，是做后勤归档最先要背下来的：

我一般会先在事务码 SARA 里查看归档对象的完整列表，确认对象名称拼写。归档对象名称容易记混，比如 FI_DOCUMNT 末尾是 “UMNT”，不是 “UMENT”。一旦输错，系统直接提示对象不存在，在测试环境可以用事务码 SARA 的 “归档对象” 输入框里敲 F4 帮助选择，不要凭记忆硬敲。

归档会话结束后，每个归档对象都有一个管理功能入口，选中某次会话后点击“√”，系统会按日期排列列出该会话归档的全部单据。这就是查看已归档数据的最直接方式。另外，归档文件生成后一般还会要求做归档文件管理，把文件从应用服务器拷贝到归档存储，这一步千万别漏，否则重查历史数据时文件已经不在线。

2.2 归档顺序的硬约束：先会计凭证，再发票，最后交货单

笔记里反复提到归档顺序，实际执行时这是一个硬约束。归档发票时，系统会检查发票对应的会计凭证是否已经归档，如果没归档就拒绝执行；交货单归档时，如果对应的物料凭证还没归档，同样会报错。我遇到过最典型的情况：先归档交货单，结果物料凭证仍在活动表，系统提示 “有未归档的后续凭证”，整批会话中断。

正确顺序是：先归档会计凭证，再归档销售发票，然后归档交货单，最后归档销售订单。为什么销售订单放在后面？因为销售订单被交货单、发票引用，如果先归档订单，后续单据还在活动表，引用关系会断。数据一致性检查会根据归档对象内部配置的依赖关系自动提示，但系统不会替你重排顺序，你必须先做一遍依赖关系梳理。

提示：正式执行前，先在测试客户端跑一次完整归档链路，确认每个对象都能生成写入请求，再放到生产环境。归档会话一旦提交，后悔药只能靠还原备份，代价很高。

查看归档数据时出现“数量字段为空”，这个问题在原笔记里被反复追问。大部分情况下不是数据丢了，而是归档显示程序的字段目录里没有包含数量字段，或者读取程序版本与归档文件结构不匹配。可以先在 SARA 里查看该归档对象的“管理”下的“归档文件显示”，换一个显示程序试试；如果显示程序本身有 bug，也可以用事务码 SARA 的“写入”和“删除”两阶段模式，重新生成一次归档文件，但前提是源数据还没被删除。

2.3 计量单位显示 ******：语言环境与基本计量单位的问题

这份笔记里有一个特别容易被忽视的细节：物料主数据里的计量单位显示成******，无法使用。现象是在归档数据显示界面中，单位字段不是正常文本，而是一串星号。原因通常是当前登录语言环境下没有为该计量单位建立文本描述，或者物料主数据是在英文环境下维护的，中文语言包里没有对应单位描述。

解决思路分两步。第一步，检查物料主数据所在的语言环境，用事务码 MM03 查看基本计量单位，然后去事务码 CUNI（单位维护）里确认当前语言下是否存在对应文本。第二步，如果单位描述缺失，可以登录到创建该物料的语言环境，或者在后台配置里补充单位文本。SM30 维护视图里可以给单位补充多语言描述，具体视图是 T006A。这个问题的根源是主数据语言与登录语言不一致，跟归档本身没有关系，所以即使重做归档文件，星号依然存在。

2.4 SM37 里 Active 进程清不掉：STOP、CANCEL 之后还能做什么

后台作业挂在 SM37 里，状态一直是 Active，运行时间已经远超正常范围，STOP 和 CANCEL 都点了，作业还是纹丝不动。这是典型的“作业卡死”。首先要明确一个区分：如果 SM50 工作进程里看不到这个作业，说明它已经不在某个具体的工作进程中运行，SM37 里的 Active 状态只是没有收到作业结束信号，这时候 STOP 和 CANCEL 确实可能无效。

常规处理顺序是这样：先在 SM50 里找到占用该作业的工作进程，直接右键“结束进程”；如果 SM50 看不到，回 SM37 选中作业后依次执行“作业 → 状态检查”，让系统重新读取后台作业状态。状态检查后如果仍然 Active，下一步检查作业日志和作业调度表，看是不是表里残留了不良数据。原笔记里有人建议用 SM65 做表一致性检查，这是 SAP 系统内部检查工具，可以检查后台作业相关表是否损坏。最后的手段是重启应用实例，但重启前一定要确认没有其他活动作业，否则会把正常作业也打断。

注意：不要在生产系统上一上来就重启实例。先试 SM50 结束进程，再试 SM37 状态检查，最后才考虑 SM65 检查表和重启。以我的经验，大部分卡死的 Active 作业是作业状态表 TBTCO 里的标志位没有更新，导致系统误判为 Active。

3. 物料账与会计账开启：OMSY、MMPV、F-60 三个事务码的分工与踩坑

3.1 OMSY、MMPV、F-60 分别解决什么问题

物料账和会计账的期间开启，是 SAP 里最容易让新手懵的操作。笔记里提到三个事务码：OMSY、MMPV、F-60。它们解决的不是同一个问题。

OMSY 是物料账初始化设置，用于把物料账的当前期间一次性设置到目标月份。它只在系统刚开始启用物料账时使用，一旦该公司代码下已经有物料移动或物料账凭证，OMSY 里对应公司代码的记录就锁住不允许再改。这也是笔记里“第一条记录改为 2005 后，其它记录却不能修改”的原因。MMPV 则是逐月打开物料账期间，必须在每个月月底或下月月初手动执行，把物料账期间往后推。F-60 是会计账的期间设置界面，显示的是会计凭证的过账期间，和物料账是两条线，但两者必须保持同步，否则物料移动和财务过账会出现期间错位。

这三个事务码的分工如果不清楚，最容易翻车的地方是：用 OMSY 强行改期间，结果系统提示公司代码已有业务数据；或者用 MMPV 开物料账，但会计账 F-60 没同步开，导致物料凭证能过，会计凭证不能过。

3.2 MMPV 报“no MARV record”的排查顺序

MMPV 运行时提示Company code 8000 has no MARV record; no conversion here，意思是该公司代码在物料账控制表 MARV 里没有记录。这个报错排查顺序要固定：先查 MARV 表，用 SE16 输入表名 MARV，按公司代码查有没有对应记录。如果记录不存在，说明物料账还没有初始化，需要用 OMSY 先建一条记录；如果记录存在但期间不对，看控制记录里的当前期间和要打开的期间是否连续。

另一个常见报错是The current period (month/year) of the control record is 04 2002，表示控制记录的当前期间停在 2002 年 4 月，而你想开 2005 年的账。中间隔着几十个月，MMPV 一次只能开一个月，需要连续执行多次。我一般会写一个循环调用，或者手动逐月执行，不能用 OMSY 直接跳，因为 OMSY 的初始化条件很严格。

实际工作中我还遇到过 MMPV 成功但报表数据异常的情况，最终查出来是 MMPV 执行时没有选对“公司代码”和“期间”，导致开账期间错位。MMPV 界面上必须明确输入公司代码，不能只输入工厂，否则系统按默认公司代码处理，容易开到别的公司代码上去。

3.3 公司代码与工厂的对应关系：用 OX18 看组织结构

笔记里问“怎么看到每个公司代码下包含哪些 PLANT”，答案是事务码 OX18。OX18 是分配公司代码到工厂的配置事务，进入后以列表形式显示工厂与公司代码的对应关系。这个事务码在配置里属于“企业结构 → 分配 → 后勤 → 分配工厂到公司代码”。输出界面里，每一行是一个工厂，每一列是公司代码，打勾表示归属关系。

我在看组织结构时会习惯同时打开 OX18 和 OX02/OX10。OX10 定义工厂，OX02 定义公司代码，OX18 负责分配。如果物料账开启后工厂和公司代码对应错乱，回来复查 OX18 是最快的定位方式。归档销售订单时也一样，订单所属的公司代码和工厂必须与归档对象的范围一致，否则归档会话会提示组织范围不匹配。

3.4 个人参数默认值：让 CAC、公司代码、工厂自动带出

和期间相关的还有一类高频操作：在操作界面反复输入公司代码、工厂、成本控制范围。笔记里提到通过“系统 → 用户参数文件 → 个人数据”设置默认参数，这个功能很实用。在 Parameters 标签页里，参数代码 CAC 代表成本控制范围，填入默认值后，几乎所有需要输入成本控制范围的界面都会自动带出。类似的参数还有 FWD（公司代码）、WRK（工厂）等。

设置个人参数时要留意参数代码的大小写和有效期。CAC 是成本控制范围，BUK 是公司代码，WERKS 是工厂。填错代码系统不报错，只是界面不会自动带出。另外，如果用户被分配到多个公司代码下，个人参数默认值反而会影响操作，因为有些事务码会强制用默认值，想改别的公司代码还得手动覆盖。我一般在测试环境先设一组，确定不影响再推广。

4. 数字范围与短转储：两个运维高频故障的定位思路

4.1 FBN1 补数字范围：RF_BELEG 1000 报错的处理

做 MB1C 或采购申请时，系统报错For object RF_BELEG 1000, number range interval 49 does not exist。这个报错的意思是编号对象 RF_BELEG 在数字范围 49 上没有定义区间。RF_BELEG 是物料凭证的编号对象，1000 是公司代码或工厂编号，49 是年度。当年份切换或新公司代码启用时，数字范围没有自动生成，就会出这个错。

处理方式是用事务码 FBN1 维护数字范围。进入后选择编号对象 RF_BELEG，点击“间隔”，查看现有区间列表。如果是年度区间缺失，新建一条记录，填入编号范围、年份和当前编号。关键参数是“当前编号”和“外部/内部编号分配”。一般情况下物料凭证使用内部编号分配，系统自动取区间内的下一个号；如果你填了外部编号，系统会要求业务单据手工编号，容易引发冲突，除非特殊需求否则不建议。

注意：FBN1 的修改会直接影响编号分配，错误配置会导致编号重复或跳号。改完以后，用 SM37 里没有正在运行的物料凭证后台作业，再执行一次 MM02 或 MB1C 验证编号能正常生成。

4.2 短转储 raise_exception：SAPGUI、权限与缓冲区三个方向

短转储是运行期错误，最常见的是raise_exception，翻译过来就是 ABAP 程序主动抛出了一个未捕获的异常。笔记得出的结论是：SAPGUI 客户端问题、权限不足、日志缓冲区大小不够，都可能导致这个错。我在实际排错时按这个顺序查：

第一步，换一台电脑重试同样的操作。如果别的电脑正常，说明当前电脑的 SAPGUI 有问题，重装 SAPGUI 或修复网络配置。第二步，看短转储的具体异常类名。在 ST22 里打开短转储记录，异常类如果是权限相关的，用 SU53 检查授权缺失，缺失的权限对象可以在 PFCG 里补。第三步，检查系统日志 SM21，看是否有缓冲区或进程相关问题。短转储记录不完整时，ST22 里也会提示“短转储没有完全存储”，这种情况通常是日志空间满了，需要先扩展日志文件。

有一种情况容易被忽略：ABAP 程序本身有问题，重新生成一次程序就好了。可以用 SE38 打开程序，执行“生成”，或者用 SGEN 批量重生成。笔记里说“有可能程序再 generate 一遍就好了”，这不是玄学，ABAP 生成版本和当前代码不一致时，运行期就会抛出异常。

4.3 SM21 与 ST02 的关系：表空间不足和缓冲区不足要分开看

系统日志 SM21 里出现ORA-01653: unable to extend table，同时 ST02 里出现RSTG chain defective，这两个错误表面像是一回事，实际要分开处理。ORA-01653 明确是 Oracle 表空间不足，比如tablespace PSAPBTABD无法再扩展，需要给表空间增加数据文件或用命令行扩展。ST02 里的缓冲区错误是 SAP 缓冲区配置不足，例如 nametab 条目数不够，需要修改参数rsdb/ntab/entrycount并重启实例。

这里最容易踩的坑是对着系统日志去改 SAP 缓冲区参数，结果发现SQL错误依旧发生，因为根因是表空间已经满了，缓冲区参数再大也无济于事。反过来，ST02 里出现大量缓冲区替换和溢出，SM21 里没有数据库错误，这时才应该调整缓冲区参数。我一般先看数据库错误码，再对照表空间使用率。Oracle 下用select tablespace_name, sum(bytes) from dba_data_files group by tablespace_name查数据文件大小，再结合dba_free_space查剩余空间。

5. 系统维护常见问题避坑清单：口令重置、表空间、默认登录与权限组织级别

5.1 SAP* 口令忘记后的恢复路径：直接操作 USR02 而不是猜口令

SAP* 口令忘记是 Basis 人员早晚会遇到的问题，原笔记里针对不同数据库给出了完整方案，核心思路是删除或更新 USR02 表中 SAP* 用户的记录。以 Oracle 为例，用<sid>adm系统用户登录，执行 SQL 删除sap<sid>.usr02中BNAME='SAP*' AND MANDT='000'的记录，提交后重新用默认口令pass登录。这里强调一下，删除的是口令记录，不是用户主数据，SAP* 用户本身还在，只是口令被重置为出厂默认值。

在实际生产环境执行前，先确认你有数据库级别权限，否则 SQL 执行会报权限不足。操作顺序上，先查询确认记录存在，再删除，最后提交。PB 级系统上这个操作风险较大，我一般建议先备份 USR02 表，或者在测试环境先验证一遍。

-- Oracle 9.2.0 / SAP 4.70 环境验证过的重置方式 -- 先查询确认记录存在，正常情况下显示 1 row(s) selected select * from sap<sid>.usr02 where bname='SAP*' and mandt='000'; -- 删除该记录，防止拼错，最好从上一条 SQL 直接复制 delete from sap<sid>.usr02 where bname='SAP*' and mandt='000'; commit;

这段 SQL 的逻辑是绕过 SAP 层的口令校验，直接从数据库层重置口令。<sid>是实例名，比如 PRD、QAS、DEV，替换时要注意大小写。执行完成后再用 SAP* 口令 pass 登录，登录后立刻在 SU01 里把口令改成强密码。顺便提一句，原笔记里还有一段 ABAP 更新 USR02 的计划，原理相同，但我更喜欢 SQL 方式，因为更直接，也避免了 ABAP 程序在系统状态异常时跑不起来的问题。

5.2 自定义权限组织级别：PFCG_ORGFIELD_CREATE 与不能传输的限制

用户权限里想在组织级别增加“成本中心”字段，但 PFCG 的标准界面里没有这一项。笔记给出的方案是运行程序PFCG_ORGFIELD_CREATE，填上成本中心的字段名KOSTL，系统会把成本中心作为新的组织级别字段加入到权限结构里。运行后需要重新生成权限角色，在 PFCG 里做权限数据传输，否则新字段不会出现在角色维护界面。

这里有两个限制要记住。第一，这个变更是基于当前客户端的，不能通过传输请求传到其他客户端，必须在每个客户端分别运行一次。第二，生产客户端运行前要做完整的权限回归测试，因为新增组织级别字段后，旧角色中的权限参数文件如果没包含新字段，用户可能会因为权限结构不完整而无法访问部分事务码。

创建自定义权限对象的方式也可以：事务码 SU21 创建对象，在对象里添加组织和值字段，然后放到角色里。另一个方法是事务码 OOSP 创建类型为 “O” 的组织级权限参数文件，再用 OOSB 分配给用户。这个方法适合组织单元数量多、不想逐个维护角色字段的场景。

5.3 默认登录 Client 设置：RZ10 参数与重启的边界

每次登录默认 Client 是 000，想改成常用的 800。标准做法是用 RZ10 修改实例参数文件，添加参数login/system_client=800，保存后重启 SAP 实例。重启前用 RZ10 的“检查”功能验证参数文件没有语法错误，否则实例可能无法启动。

# RZ10 扩展维护中新增的参数 # 参数名称：login/system_client # 参数值：800 # 修改保存后必须重启实例

用 RZ11 修改运行中实例参数可以马上生效，但重启后失效。login/system_client这类登录参数建议用 RZ10 写进持久配置文件，而不是 RZ11 临时修改。另外，修改默认 Client 只影响登录界面的默认值，不影响权限，用户仍然可以在登录界面手工切换 Client。生产系统上不要设成 000 之外的值，否则管理员登录容易误进生产 Client。

5.4 汉字显示成 ####：代码页设置与语言包检查

中文显示成####的问题有三层原因：SAPGUI 代码页设置错误、语言包不完整、字符集配置不对。笔记里给的解决路径是：登录界面属性 → 高级 → 语言首选项 → 取消“缺省代码页”，把代码页编号改成8400。这个 8400 是简体中文字符集编码。

改完代码页后如果仍然乱码，检查系统里是否安装了中文语言包，用 SMLT 查看。EASY ACCESS 主界面问号右侧那个按钮是设置入口，界面里还有字体设置，默认字体是“新宋体，常规，11”。代码页设置属于客户端本地配置，换一台电脑要重新设置，不能随用户信息自动同步。

6. 一个值得养成的检查习惯：用 SM21 系统日志逆向定位性能故障

6.1 三步检查法：看时间、看对象、看关联参数

遇到系统变慢或事务卡死，我最常做的不是直接看 ST03N 负载，而是先打开 SM21 系统日志。SM21 里的错误记录时间点往往就是故障起点。具体三步：先看错误发生的时间段，是否集中在某个业务操作之后；再看错误对象，比如 DB02 数据库错误、ST02 缓冲区错误、DIA 进程错误；最后关联检查对应事务码和参数。

这本质上是逆向排查：从日志反推是哪一层出了问题。比如日志里连续出现Database error 1653，对象是DB02，说明数据库层有空间或扩展问题；如果同时出现RSTG chain defective，说明应用层缓冲区也受到了影响。这时候我不会急着调参数，而是先解决根因，再回头看参数是否需要调整。

6.2 从一次真实故障复盘检查顺序

之前在一个测试系统上，用户反映 MB1C 过账特别慢，偶尔报错。我先开 SM21，看到多条ORA-01653: unable to extend table，指向表空间PSAPBTABD。再查 ST02，发现缓冲区分区有大量替换。如果只调缓冲区参数，表空间满了的问题仍然存在，过账还是会失败。正确顺序是先扩展表空间，然后观察缓冲区是否恢复正常，最后再考虑参数调整。

这套检查顺序后来被我固化成习惯：任何性能问题先查数据库空间和系统日志，再查 SAP 缓冲区，最后才动参数。从那以后，每次遇到类似的慢操作，我都强制自己先走一遍 SM21 → ST02 → RZ10 的路径，不跳过日志直接改配置。希望帮到你。

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