企业官网建设流程全解析

做SAP实施和运维的朋友应该都有印象，前端用户拿WPS处理的Excel文件往SAP里传，系统报一句“文档中不包含数据”，紧接着又跳“程序正在运行中”，这种工单来一次两次还好，一个月来十几次就真的很消磨耐心。尤其是现在很多企业办公软件都换成WPS，用户用得顺手，但SAP这边不认账，两边一打架，背锅的永远是做支持的我们。

这个标题里的两个报错，看起来一个是文件问题，一个是程序运行问题，实际上很多时候是同一个根因——前端文件在被SAP读取的过程中，格式不兼容、进程被占用、OLE对象没释放，导致SAP GUI读取不到文档内容，前端Excel进程又一直挂在后台，系统就认为上一个程序还没结束，于是又把“程序正在运行中”甩到用户脸上。这篇文章我就把这类问题的定位思路、处理步骤和踩过的坑完整写下来，适合SAP Basis、各模块顾问、ABAP开发，以及负责前端桌面环境管理的同事参考。我自己在用这套方法处理工单时，大部分情况能在十分钟内定位，二十分钟内解决，希望也能帮你少走点弯路。

1. 两个报错一起出现，问题往往出在前端环境

1.1 “文档中不包含数据”到底是什么在报错

先说结论：这个报错通常不是SAP核心程序发的，而是SAP GUI在前端调用Excel读取组件时，解析不到有效工作表内容后返回的通用提示。SAP有很多上传功能的底层逻辑都依赖Windows的OLE/COM机制，也就是SAP GUI在前台打开一个隐藏的Excel实例，然后按用户选中的文件路径去读取里面的单元格数据。这个机制从SAP GUI for Windows早期版本一直沿用到现在，ABAP侧主要是GUI_UPLOAD、WS_UPLOAD，S4/HANA上还能看到cl_fdt_xl_spreadsheet这类基于ABAP服务端的解析类，但前端直读的老逻辑仍然大量存在。

WPS保存的xlsx文件虽然从扩展名看和微软Office一样，但WPS在文件内部元数据、自定义属性、工作表结构上跟原生Office存在不少差异。尤其是用户在WPS里用“另存为”保存时，如果顺手勾选了“保存时压缩图片”、“加密文档”或者开启了WPS的云备份，生成的xlsx在SAP的OLE解析器看来就是“读不到任何数据”。再加上WPS默认会在打开文件时创建临时锁文件和后台进程，SAP去读文件时发现文件被占用，读出来的内容自然是空。

还有一类情况是被隐藏的工作表。SAP的上传模板有时候要求数据放在第一个sheet，用户却把数据放在第二个sheet，第一个sheet是空白的，或者第一个sheet被隐藏了。SAP的通用上传函数默认读取第一个可见工作表，读到空表就报“文档中不包含数据”，这个坑其实是业务操作问题，不是技术问题，但用户不会跟你解释这些，报错一样会飞到支持这边来。

1.2 “程序正在运行中”其实是个会话锁问题

“程序正在运行中”这个提示，在中文SAP系统里很常见，英文环境对应的是“program is already running”或者“program is being executed”。它的本质是SAP在前端或后台检测到同一逻辑单元还未结束，不允许重复执行。这个“同一逻辑单元”可能是同一个事务码、同一个ABAP报表、同一个BDC会话，甚至是同一个Excel OLE对象。

当用户在WPS里打开了一个Excel文件，然后到SAP GUI里运行某个上传事务，选择同样的文件路径去读取。SAP的OLE机制尝试去接管这个Excel进程时，Windows发现文件正被WPS占用，于是SAP的读取操作卡住或者超时，前端程序状态一直没有正常结束。用户以为程序死了，再点一次执行，系统检测到上一个实例还在，就抛出“程序正在运行中”。

还有一种更隐蔽的情况是WPS的进程没有完全退出。用户在WPS里看完文件后直接关窗口，但WPS的进程wps.exe或et.exe可能还在后台驻留，尤其是开启了“文档云同步”和“自动备份”后，后台进程会一直监测文件变化。SAP GUI去调用Excel时，系统注册表里注册的OLE绑定是Excel，但Excel进程启动后又被WPS的加载项干扰，导致整个调用链不断重试，前端表现为“一直在运行”，后台看进程就是一堆僵尸Excel进程堆着。

搞清楚这个机制之后会发现，这两个报错很多时候就是一个问题的一体两面——“文件读不到”是结果，“程序运行中”是状态没释放，根子在前端文件格式和进程管理上。

2. WPS侧处理：先把文件本身的格式和属性弄干净

2.1 文件另存与格式兼容，别直接用默认格式硬传

这一步是优先级最高的处理手段，也是我在工单回复里最常写的一条：让用户不要把WPS默认编辑状态下的文件直接传给SAP，而是先“另存为”成标准Excel格式。

具体操作路径是：WPS表格里打开文件后，点击左上角“文件”菜单，选择“另存为”，在文件类型下拉框里选择“Excel 97-2003工作簿(.xls)”或“Excel 工作簿(.xlsx)”，注意不要选“WPS表格工作簿(.et)”或者“WPS文字格式”之类的选项。.et格式是WPS私有格式，SAP的OLE解析器根本不认识，报“文档中不包含数据”十分正常。.xls是老格式，兼容性最好，SAP的老程序基本都能直接读；.xlsx在SAP GUI 7.40以上版本也能读，但要注意不要保存成“启用宏的工作簿(.xlsm)”，宏工作簿在某些安全策略下会被SAP或Windows锁定，也容易出现读取异常。

还有一个细节容易被忽略：WPS在打开文件时会显示“兼容模式”标识，说明文件是在非标准格式下编辑的。用户如果在这个状态下直接点保存，WPS会保留原文件格式，不会自动转成xlsx。所以正确的流程是：先用WPS打开原始文件，点“另存为”，选择标准Excel格式，然后再在SAP里上传这个新文件。

如果用户的数据量很大，比如几万行的物料主数据或财务凭证，我会建议他在WPS里先做一遍“数据清洗”——删除空行、空列、合并单元格，移除数据验证和条件格式，最好再检查一下有没有excel公式引用外部文件。SAP的通用上传函数在处理大文件时本来就慢，这些隐藏的格式元素会显著增加解析时间，甚至导致读取超时。实际工单里我见过一个用户的Excel文件里残留了整整几十列“无效格式”的空列，SAP读取时每个空列都要做一次格式判断，最后直接超时失败。

2.2 WPS表格的组件设置与ActiveX控件的兼容

这里要给做支持的朋友提个醒：SAP GUI读取Excel文件依赖的是Windows注册表里OLE/COM组件的注册状态，不是WPS自带的文件读写接口。换句话说，就算你电脑上只装了WPS，SAP读取xlsx时依然会在系统里寻找Excel的OLE注册信息。如果系统里完全没有安装Office套件，或Office卸载时清理了注册表，SAP去调用Excel COM组件就会失败，报出来的错误五花八门，“文档中不包含数据”就是其中典型的一种。

所以从桌面管理的角度，最稳妥的方案不是让用户把Office卸载后纯用WPS，而是在保留WPS作为日常办公工具的同时，也装一套Microsoft Office（可以不用，但组件要注册）。技术上，SAP GUI的gui_upload获取文件路径后，会通过CREATE OBJECT方式创建Excel.Application对象，这个创建动作必须依赖Office的COM组件。WPS虽然也提供KET.Application之类的COM接口，但SAP的标准代码里不会去调用它，所以WPS的卸载或缺失Office组件会直接导致读取失败。

如果公司确实不想给所有用户都装Office，考虑成本或版权因素，那就需要走另一条路线——不用前端直读Excel，改用ABAP服务端解析xlsx文件。S4/HANA环境里cl_fdt_xl_spreadsheet这个类可以在ABAP应用服务器上直接解析xlsx，不需要依赖前端任何Office或WPS组件，这是一个架构层面的解决方案，后面第三节我会专门讲。

另外WPS自身有一个需要注意的选项：在“文件-选项-通用与保存”里，有个“兼容性”相关设置，还有“保存时自动备份”的选项。如果开着自动备份，WPS会在后台持续生成临时文件，每个打开过的Excel都会留下一个~$开头的隐藏锁文件。SAP在读取目录文件时如果先扫描到锁文件，可能误判文件正在被使用。我的建议是，面向SAP操作的关键终端，把这些自动备份和云同步功能统一关掉，能省掉大量莫名奇妙的文件锁问题。

2.3 文件命名、路径和进程残留也是高频坑

文件本身的格式处理完了，接下来要检查的是文件路径和进程状态。SAP GUI对前端文件路径的解析能力没有想象中那么强，路径里如果包含中文、特殊符号、空格、全角字符，都可能让SAP的OLE解析器找不到真实路径。最典型的场景是用户的文件名里带了“（副本）”或者“最终版V2.0最终版”，这种名字看一眼就头大。

我给用户的硬性要求是：文件名只用字母、数字、下划线，最多加一个横杠，不要用中文、空格、括号、百分号、#号。路径也尽量浅，直接放到C:\Upload或桌面这类短路径下面，不要放在C:\Users\张三\Desktop\SAP上传文件2024\最终修订版\这种多层中文路径里。这个要求不是强迫症，而是SAP的ABAP程序拿到文件路径后，会把这个路径传给前端函数做Windows API调用，路径解析失败或编码转换异常时，SAP只会给你一个笼统的“文档中不包含数据”，不会告诉你其实是路径找不到。

进程残留问题是另一个高频坑。用户如果在WPS里打开过文件，即使关掉了窗口，et.exe或wps.exe进程也常常还挂在任务管理器里。SAP GUI去读取这个文件时，OLE机制会尝试去绑定文件，但Windows文件系统发现文件被进程独占锁定，OLE绑定超时，前端表现为SAP界面一直转圈，然后报“程序正在运行中”。这种情况下最简单的操作是：

1. 按Ctrl+Shift+Esc打开任务管理器。
2. 在“进程”里找到wps.exe、et.exe、wpscloudsvr.exe、excel.exe。
3. 全部结束进程。
4. 确认文件所在目录下没有~$开头的临时锁文件，有就删掉。
5. 重新打开SAP GUI，再执行上传。

这套操作解决不了大部分问题的话，再去看SAP侧配置。

3. SAP侧配置：让GUI正常识别前端文件

3.1 SAP GUI的安全设置与前端文件访问授权

SAP GUI for Windows 7.40以上版本在默认情况下对前端文件访问做了一定的安全限制。尤其是ActiveX控件和OLE对象的调用，需要在SAP GUI的“选项-安全-安全设置”里进行授权。很多时候用户换了新电脑或升级了SAP GUI版本，安全策略被重置，原来能正常上传的文件突然就报“文档中不包含数据”，检查了一圈文件没问题，最后发现是SAP GUI的信任设置没放行。

具体操作路径是：登录SAP GUI后，右键点击系统连接图标，选择“选项”，进入“安全”标签页，选择“安全设置”，找到“ActiveX控件”相关的信任项，确保允许SAP GUI调用ActiveX控件并访问本地文件。如果企业通过组策略或注册表统一下发了安全策略，那需要桌面管理团队在AD域控或注册表层面放行，单独在客户端改不一定生效。

此外，SAP GUI里还有一类上传操作是用到了前端文件选择对话框的，比如cl_gui_frontend_services=>file_open_dialog这类类方法。它们也受安全策略管理，如果文件对话框能正常弹出但点完确定后就报错，优先检查安全设置和权限。SAP GUI的安装目录下有一个saplogon.ini配置文件，某些权限管控严格的桌面环境会在里面锁定安全级别，这个文件如果被改坏，也可能导致前端文件访问异常，但重装SAP GUI就能恢复。

3.2 版本兼容和补丁更新，别让GUI Office组件拖后腿

环境里另一个常见的变量是SAP GUI本身的版本。SAP GUI for Windows 7.30、7.40这些老版本对xlsx格式的原生解析能力不太好，早期版本在读取带复杂样式的xlsx时容易失败。我在项目上见过最夸张的一次，用户用的SAP GUI 7.30，配合WPS保存出来的xlsx，上传必报“文档中不包含数据”，换成老一点的xls格式就正常，后来给用户升级到SAP GUI 7.50并打上最新补丁，xlsx也能正常读取了。

原因在于SAP GUI的Excel OLE逻辑里，有一部分是依赖前端Office组件版本的。旧版GUI在创建Excel对象时会调用旧的COM接口，新版Office或WPS环境下接口行为发生变化，旧GUI解析不了。SAP官方也在不断更新SAP GUI组件，7.50版本的兼容性改善非常明显，建议生产环境统一升级到7.50以上。

WPS版本同理。WPS 2016、WPS 2019、WPS 2023在文件保存时的内部元数据差异很大。对SAP兼容性比较好的反而是WPS 2019企业版的稳定版本；WPS 2023个人版默认开启云文档同步，文件保存后会在后台继续上传云端，这个后台任务持续占用文件IO，容易干扰SAP的OLE读取行为。企业办公如果必须用WPS，最好采购企业版并统一下发稳定的版本号，不要放任用户自己装个人版或所谓“WPS破解版”，破解版通常还会捆绑额外的后台服务，对SAP前端读取的负面影响更大。

3.3 模板与脚本标准化，从源头减少兼容性问题

在SAP侧配置之外，还有一个非常值得做的投入：把上传用的模板和流程标准化。很多企业里用户上传Excel给SAP，用的模板五花八门，有的是自己手敲的，有的是从旧系统导出的，有的是从WPS云文档里下载的，格式字段对不上还硬传，最后技术这边排查半天发现是模板问题。

标准化做法是：由SAP模块顾问牵头，针对每个常见上传事务（比如财务凭证批量导入、物料主数据导入、固定资产导入、MD07库存汇总分析、KO88结算结果导出后再导入等），制作统一的标准Excel模板，模板里固定sheet名称、字段顺序、单元格格式约束，并锁定格式禁止用户修改。模板必须用微软Office制作并保存为标准xlsx，不要用WPS生成模板，这样才能保证SAP OLE解析兼容性。

上传入口也可以做一层校验。ABAP开发可以在上传程序中增加对文件扩展名和文件大小的前置检查，文件大小超过10MB或扩展名不是xls/xlsx就主动提示，而不是等到OLE解析失败再报“文档中不包含数据”。更进一步，对于S4/HANA环境，可以彻底抛弃前端OLE读取，改用cl_fdt_xl_spreadsheet在ABAP端解析xlsx。这种方式的优点是：

• 不依赖前端Office或WPS组件，部署和运维成本低。
• 文件在ABAP服务器上读取，不受用户前端进程和文件锁影响。
• 解析性能比OLE方式高，尤其在数据量大的时候。

缺点是cl_fdt_xl_spreadsheet在ECC环境里可能不存在，且它对xlsx格式的要求比OLE更严格，某些WPS保存的xlsx在服务端解析时也会报结构异常。不过对于新实施S4/HANA的项目，这已经是我推荐的首选方案。

4. “程序正在运行中”的定位与处理

4.1 用标准事务码快速定位卡住的程序

“程序正在运行中”这个报错一旦出现，不要跑到前端去瞎猜，先在SAP系统里通过标准事务码把运行状态查清楚。我个人的排查顺序是：

• SM37：先看有没有后台作业还在运行。有些上传逻辑是异步执行的，用户在前台提交任务后，实际处理在后台作业里进行。后台作业如果因为数据量大或死锁卡住，状态一直显示“运行中”，用户再次提交就会收到“程序正在运行中”。
• SM50/SM66：看当前对话进程和工作进程的占用情况。如果某个工作进程被一个长时间运行的报表占住，CPU时间或内存异常增长，需要评估是正常跑数还是死循环。
• SM04/AL08：查用户会话列表，看当前用户是否已经有多个前台会话在执行同一个事务。用户开了三个SAP窗口，每个窗口都点了同一个上传程序，系统只允许单实例执行，就会报“程序正在运行中”。
• SM12：查锁对象。很多自开发上传程序会在执行开始时设置排他锁，防止多人同时操作同一批数据。锁对象没有正常释放，后续所有用户都会提示程序运行中或数据被锁定。

这套流程跑下来，基本能把问题定位到“是程序真的在跑”、“是程序卡死了”还是“是锁没有释放”三个方向。

如果确认是SM12里的锁没有释放，首先要判断这个锁是否还在正常业务进程中。可以用事务码SM12查看锁的时间戳和用户，如果锁已经存在很长时间且对应程序没有实际活动，可以手工删除锁。但删除锁前务必确认没有其他用户正在执行相关业务，否则可能引发数据一致性风险。我的习惯是先在SM50里看有没有对应的工作进程在跑，如果没有，说明锁是僵尸锁，可以删；如果有，说明程序真的还在处理数据，可能需要等它跑完或评估是否要终止进程。

4.2 工作进程、会话与前端Excel进程的三重检查

还有一种“程序正在运行中”与前端Excel进程高度相关。前面说过SAP GUI通过OLE调用Excel时，Excel进程是隐藏运行的。如果用户在调用过程中强行关闭SAP窗口、电脑休眠或者网络中断，Excel进程不会自动退出，但SAP GUI侧的程序状态可能没有被清理。用户重新登录SAP再执行同一事务，系统检测到前一个会话的上下文还在，就提示“程序正在运行中”。实际工单里，这种占用和锁存在于SM04或AL08的用户会话列表里是能看到的，但用户自己往往已经忘了之前开过什么窗口了。

处理方式是：

1. 在SM04或AL08里查看当前用户所有会话。
2. 找到状态为“运行中”且时间很长的旧会话，和用户确认是否还要保留。
3. 如果确认是残留会话，用SM04里的“结束会话”功能清理，或者在服务器上用AL08删除终端会话。
4. 再到前端任务管理器里结束所有excel.exe、et.exe、wps.exe进程。
5. 重新登录SAP GUI执行上传。

在服务器端如果会话删不掉，还有一种力度的操作是通过SM50直接终止工作进程里的报表，用SM66可以查看所有服务器上正在执行的ABAP程序，找到对应的进程后可以勾选终止。但千万注意优先级，生产系统中终止工作进程是最后手段，操作前要和业务负责人确认没有正在跑的重要作业，我见过同行因为误杀工作进程导致集团月结卡死的事故，事后挨通报批评都是轻的。

4.3 开发侧建议：别让上传逻辑变成“占用型”任务

从ABAP开发的角度，有些“程序正在运行中”报错其实是代码设计不合理造成的。典型场景是一个上传程序内部先锁数据、再读取Excel、再校验、再更新数据库，整个流程串行执行且过程非常长，用户在前台等待期间觉得卡了，又点了一次执行，系统直接报“程序正在运行中”。这种体验极差，但如果把逻辑改成“前台提交文件就返回成功，后台Job异步处理，处理完毕发通知”，就能彻底规避冲突。

修改思路也很明确：

• 上传程序入口只负责把文件保存到应用服务器或内容管理库，然后立即提交后台作业。
• 后台作业内部分步骤处理：校验文件、校验数据、写日志、更新数据库。
• 如果处理过程中发生错误，把错误记录写到日志表或发送邮件给用户。
• 后台作业允许重复执行，但在更新数据前检查任务ID是否已经处理过，防止重复入账。

另外在代码层面，如果用了CALL FUNCTION 'GUI_UPLOAD'这类前端读取函数，函数返回后立刻释放相关对象引用，不要保留不必要的全局变量指向Excel COM对象。必要时候可以调用CL_GUI_CFW=>FLUSH强制刷新GUI事件队列，减少SAP GUI和前端Excel组件之间的状态残留。

对于MD07、KO88这类标准事务加增强的场景，也要遵循同一个原则：增强代码里不要做太重的同步外部调用，不要在用户会话里长期持有数据库锁。SAP标准功能的锁机制本身就比较严格，增强代码如果再嵌套自定义锁，很容易造成互相等待的假死状态，最终表现就是系统提示“程序正在运行中”一直不消失。

5. 快速排查手册与避坑经验

5.1 高频场景速查表

我把实践中最常见的几个组合场景整理成了一张表，方便大家直接对照定位。注意表格里的处理动作不是唯一解，但基本能覆盖日常工单的80%情况。

这张表只是辅助判断，真正干活的时候，现场情况往往比表格复杂，但遵循“先查文件格式，再查进程占用，最后查SAP侧运行状态”这个顺序，大部分问题都能收敛到一个可控的方向。

5.2 大批量上传场景，别跟前端Excel死磕

如果用户反馈的上传场景是“每个月都要传几万行数据”，比如会计凭证、物料主数据、成本中心主数据之类的批量导入，我强烈建议不要再继续走前端Excel直读的路线。这个场景下WPS兼容性问题和OLE进程问题只是表象，本质是架构不适合。

替代方案有三种：

1. 文件放到服务器共享目录，SAP后台程序定时扫描目录并解析文件。用户只需要把文件放进共享文件夹，SAP程序自动处理并给出日志。这种方案完全绕过SAP GUI前端，不存在WPS兼容性问题和前端进程残留问题。
2. 使用LSMW或自定义Batch Input录制程序，文件先导入到SAP临时表，再通过BDC批量处理。LSMW对格式要求没有OLE读取那么苛，录入阶段也可控。
3. 让用户另存为CSV格式再上传。CSV是纯文本，SAP解析时没有Excel COM依赖和文件锁困扰。注意CSV编码要统一为UTF-8（带或不带BOM要看SAP版本），否则中文会乱码。带有BOM的UTF-8和ANSI编码在SAP GUI 7.50上的表现不完全一样，这个要靠实测确认，最好做成标准操作文档。

我去年处理过一个客户，月末结算时财务需要上传两万行费用导入数据，用户用的是WPS表格，提示“文档中不包含数据”断断续续出现了一个多月，后来我把方案改成“WPS另存为CSV + 上传CSV + 后台Job异步导入”，之后整个月结再没因为上传出过问题。用户甚至没感觉到操作流程有多大变化，只是少了两个报错弹窗。

5.3 长期落地的几条建议

最后说几条从环境管理和运维流程角度的建议，这些是减少工单量的关键。

第一，统一前端软件版本。办公室里所有SAP用户尽量统一SAP GUI版本、Office/WPS版本。不要今天这个人是SAP GUI 7.30配WPS 2016，明天那个人是SAP GUI 7.60配Office 365，不同版本组合下OLE兼容性表现差异巨大，出了问题也很难复用排查经验。实测下来，SAP GUI 7.60配合WPS 2019企业版或Office 2019/365都可以正常解析标准xlsx文件，但WPS 2023个人版默认开启云同步后问题明显增多。

第二，发布标准操作手册。把“先用WPS另存为xls/xlsx，文件放短路径，关闭文件后再上传，上传完不要关SAP窗口”这些要点写成简明图文手册，放到OA或团队知识库里。用户不是故意乱操作，是真的不知道这些细节。手册写清楚后，“文件没关闭就上传”这类问题能减少一半以上。

第三，定期清理临时锁文件。很多公司配了桌面管理工具，可以写一个计划任务，每天下班后扫描用户的临时目录和上传目录，清理~$开头和.tmp结尾的残留文件。这个任务在后台做，用户无感知，但能直接减少文件锁导致的上传失败。

第四，注意前端软件的安装规范性。WPS和Office这类依赖Windows注册表组件的软件，安装时不要图省事直接剪切整个安装目录到其他盘符，也不要手动删除安装目录再恢复，注册表信息一旦和实际文件对不上，OLE组件注册状态就会异常，SAP怎么都调不到Excel对象，这种问题重装一遍WPS或Office就能解决，但排查起来很费时间。同理，SAP GUI也不要多人共用绿色版或者随意从一台电脑复制到另一台，按标准流程安装一次就一劳永逸。

第五，业务侧培训要跟上。抽一个下午给关键用户讲一次Excel导入SAP的正确流程，包括文件模板从哪里拿、上传前要不要另存、报错以后先截图再反馈。关键用户搞清楚这些，再让他们去指导其他终端用户，能很大程度上降低SAP支持团队的工作量。

6. 这个问题的经验体会与延伸思路

我处理这类问题有一个深切的体会：SAP与WPS之间的问题，绝大多数不是WPS真的“不支持”，而是SAP GUI调用前端Excel的方式太老派，它认准的是微软Excel的OLE注册接口，而WPS从来不会去完整模拟那一套COM行为。所以不要指望WPS厂商出一个补丁就能彻底解决，解决方向还得是让文件格式和前端环境更贴合SAP的预期。

从长远来看，SAP和WPS的兼容性问题会随着SAP平台迁移到S4/HANA和Fiori而逐渐减轻。Fiori的Web上传方式走的是NWBC和浏览器，前端文件解析发生在应用服务器，不再依赖用户的桌面Excel组件。但现实是很多企业还在用GUI做日常操作，短时期内还得继续面对这套老逻辑。如果让我建议一个优先级，我会说：先把标准上传模板做出来，再把“另存为CSV或标准xlsx”写进操作手册，最后有条件的话把关键批量导入改成ABAP服务端解析，这条路线走完，你在这个问题上的工单量会断崖式下降。

最后再分享一个小技巧，如果你在工单里遇到了“文档中不包含数据”和“程序正在运行中”连续出现的情况，别急着让用户重装WPS或重启电脑，先让用户执行一遍“关掉所有WPS和Excel进程 → 用英文短文件名另存为标准xlsx → 重新打开SAP GUI上传”，这个组合拳可以解决至少一半的情况。剩下的通过SM04、SM50、SM37去定位后台进程和锁，通常也能在半小时内找到答案。做支持这份工作，很多时候拼的不是什么深奥原理，而是能把一条稳定的排查路径跑到肌肉记忆。