简介一份面向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 的归档不是直接删表而是把业务数据从活动表写入归档文件再由归档对象管理。每个业务单据都有对应的归档对象选错对象会导致“系统不让通过”。这份笔记里提到的几个对象是做后勤归档最先要背下来的业务数据归档对象活动表说明销售订单SD_VBAKVBAK、VBAP订单抬头与行项目一起归档交货单RV_LIKPLIKP、LIPS要确认是否连带物料凭证销售发票SD_VBRKVBRK、VBRP发票必须先归档对应会计凭证会计凭证FI_DOCUMNTBKPF、BSEG所有财务凭证归档的基础物料凭证根据物料类型选择MKPF、MSEG通常与交货单归档搭配我一般会先在事务码 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_exceptionSAPGUI、权限与缓冲区三个方向短转储是运行期错误最常见的是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 为例用sidadm系统用户登录执行 SQL 删除sapsid.usr02中BNAMESAP* AND MANDT000的记录提交后重新用默认口令pass登录。这里强调一下删除的是口令记录不是用户主数据SAP* 用户本身还在只是口令被重置为出厂默认值。在实际生产环境执行前先确认你有数据库级别权限否则 SQL 执行会报权限不足。操作顺序上先查询确认记录存在再删除最后提交。PB 级系统上这个操作风险较大我一般建议先备份 USR02 表或者在测试环境先验证一遍。-- Oracle 9.2.0 / SAP 4.70 环境验证过的重置方式 -- 先查询确认记录存在正常情况下显示 1 row(s) selected select * from sapsid.usr02 where bnameSAP* and mandt000; -- 删除该记录防止拼错最好从上一条 SQL 直接复制 delete from sapsid.usr02 where bnameSAP* and mandt000; 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_client800保存后重启 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 的路径不跳过日志直接改配置。希望帮到你。本文还有配套的精品资源点击获取