企业官网建设流程全解析

月末最后一天晚上十点，办公室里还剩三个人，其中一个就是负责总账的会计，她正在总账记账界面里做第五张费用分摊凭证：借方六个成本中心行、贷方一个待分摊科目，科目、成本中心、比例全公司都一模一样，每张凭证只有金额和日期在变。这种活干一两次没问题，连着干两年就一定会出事——要么出错，要么人跑。我第一次接触 SAP 的科目分配模型（Account Assignment Model）就是为了收拾这类"结构固定、数值浮动"的重复记账场景，它本质上是一张"预先搭好骨架、调用时才填肉"的凭证模板，把记账从"每次重新敲一遍"变成"调模板 + 补两个数字"。

需要先说明一点：这篇文章里提到的事务码和菜单路径，以 ECC 6.0 和本地部署的 S/4HANA（SAP GUI 界面）为参照，不同版本、不同补丁级别、以及 Fiori 界面里入口位置会有差别，请以你自己系统里的实际菜单为准。但底层逻辑——模型存了什么、调用时系统怎么算、字段状态为什么"不生效"——这些年基本没变过，这也是为什么这套东西到现在还在被大量使用。

适合谁来读：刚接触 SAP FI 的顾问和关键用户，可以照着第 3 节直接上手建第一个模型；已经会用模型的财务同事，建议重点看第 4 节的组合玩法和第 5 节的踩坑表，这里面有几条是我自己在项目上被生产数据教育出来的。全文尽量说人话，但该有的机制解释一个都不省，因为模型这个东西最坑的地方恰恰是"看起来太简单"——按钮一按就出来一张凭证，所以没人去深究它为什么出来的是这张凭证。

1. 先搞清定位：科目分配模型到底解决什么问题

1.1 一个真实的月末场景

我拿一个具体例子开场，比讲定义清楚得多。假设某公司每月要把"制造费用-间接人工"这个科目上的金额，按 30%、30%、40% 的比例分摊给三个生产部门的成本中心，分摊源科目固定、目标科目固定、成本中心固定、比例固定，唯一变的是每月总额。不做任何优化的做法是：打开记账界面，逐行录入借贷方、科目、成本中心、金额，一张一张手工做，或者用 Excel 算好之后批量粘。前一种方式慢且容易敲错成本中心，后一种方式在粘贴过程中金额错位、借贷不平时有发生。

科目分配模型要做的事，就是把这七行"永远不变"的信息存进系统里，人工只需要在调用时补上月度总额和过账日期。它的价值不在于"能自动过账"——账还是人过的，凭证还是人生成的，签字责任还是人的；它的价值在于把重复劳动从录入压缩成填空，同时用系统固化结构，减少人为随机错误。这两点听起来不性感，但在财务共享中心这种一天过几百张凭证的地方，效果是立竿见影的。

顺带说一句，科目分配模型是 client 级别的数据，不是每个公司代码独立一套孤立的东西，一个模型可以被多个公司代码调用（前提是打开跨公司代码标识）。这个特性在集团下属多家公司科目表一致的情况下非常省事，比如一套"银行手续费计提"模型可以给十几个公司代码共用，但科目表不一致的时候就是灾难，后面第 5 节会专门讲这个坑。

1.2 它和几个"近亲"到底有什么区别

SAP FI 里做"少录一点"这件事的工具不止一个，新手最容易混的就是这一堆：科目分配模型、样本凭证、经常性凭证、快速输入、持有凭证。我见过有人把经常性凭证当模型用，结果设完循环参数之后发现每期金额要手动改，改了又发现改的是模板不是当期凭证——来回折腾半天。下面这张表是我自己整理的对照，建议直接存下来：

判断规则很简单，你只要问三个问题：这张凭证每个月都要做吗（是→考虑模型或经常性凭证）；金额每期都不同吗（不同→模型；相同→经常性凭证）；结构是不是完全固定（不固定但大差不差→快速输入或干脆用 Excel 上传）。三个问题答完，工具基本就定下来了。

1.3 什么场景该用它，什么场景不该

适合用模型的场景，我总结成四类：

• 分摊与计提类：制造费用分摊、管理费用分摊、水电费按面积分摊，分摊科目、成本中心、比例长期不变。
• 薪酬与社保类：工资、社保、公积金的计提凭证，借方按部门拆分，贷方应付科目固定。
• 摊销与折旧类：长期待摊费用摊销、无形资产摊销、预提费用的月度计提。
• 外币与费用类：银行手续费、利息、汇兑损益结转，科目固定、金额和外币金额浮动。

不适合的场景也要说清楚，不然容易滥用：

注意：只要分摊比例、成本中心、科目这三样里任何一样每个月都在变，就不要硬做模型。我见过一家公司业务调整频繁，一年改了八次分摊比例，结果模型库里躺了三十多个"某年某月专用"的模型，谁都不敢删——这是典型的用错工具，这种情况应该上分摊循环或者干脆用替代增强去算。

另外，科目分配模型只解决手工凭证的录入效率，它管不了采购发票校验、评估类与总账科目的自动记账逻辑，那是另一套机制（OBYC）。两者边界不要混：自动记账解决"系统自己生成的分录对不对"，模型解决"人手工敲的分录快不快"。

2. 核心机制拆解：模型里的每个字段都在做什么

2.1 抬头层：公司代码、凭证类型、货币、日期

模型维护界面分成抬头和行项目两大块，抬头部分决定了这张凭证的"身份"。我逐项说：

公司代码决定模型的默认适用范围。如果勾了跨公司代码标识，这个模型在所有公司代码下都能被调用；不勾，则只能在维护时选定的公司代码里调用。这里有个反直觉的点：跨公司代码模型最常挂在科目上，而不是挂在公司代码上——如果 A 公司和 B 公司用的科目表不一样，模型里预置的科目在另一个公司代码里根本不存在，调用时直接报"科目不存在"，所以跨公司代码这条便利要建立在集团科目表统一的基础上。

凭证类型建议固定成 SA（总账凭证）或你自定义的专用凭证类型。这里面有个实用技巧：如果你们给不同业务用了不同凭证号段，那么给模型配一个专用凭证类型，事后查账时一眼就能看出"这些凭证是模型批量生成的"，做审计抽凭和异常排查特别方便。

货币和汇率类型决定外币业务的行为。我的习惯是模型里只固定"凭证货币"，汇率留到调用时取当期，因为汇率是每月波动的，写死在模型里就是给自己埋雷。如果确实要用固定汇率（比如集团内部约定汇率），那就在模型里写死汇率值并在描述里注明，别让下一个人猜。

日期我的建议是全部留空。凭证日期、过账日期、翻译日期这三兄弟，只要有一个在模型里被写死，就一定会有人在某个深夜忘了改，然后生产环境里出现一批日期是三个月前的凭证，冲销起来非常难受。留空之后，调用时系统会默认当天，这也是最不容易出错的默认值。

2.2 行项目层：记账码、科目、金额、文本

行项目是模型的主体。每一行包含记账码、科目、金额、以及一大堆可选字段（成本中心、内部订单、WBS 元素、税码、特别总账标识、付款条件、基准日期等）。维护的时候注意几点：

记账码决定借贷方向和字段状态。40 是总账借方、50 是总账贷方，这是最基础的。借方如果要挂成本中心，就一定要用带成本中心控制的记账码（40 本身支持，前提是科目的字段状态组允许）。很多人遇到的"成本中心字段灰掉了"，根因往往不在模型，而在科目主数据的字段状态组设置。这一点在第 5 节会展开。

科目要选"经常性发生"的那个。我见过有人把模型的科目设成了新准则下的细分科目，结果第二年科目改名，几十个模型全废。所以我的原则是：模型尽量挂科目层级里较高层级的、稳定的科目，细分留给用户在调用时自己选——如果业务确实需要细分，那就把细分科目也做进模型，但要在模型描述里写清楚适用范围和废止条件。

每一行都可以展开明细。模型维护时，行项目都有明细入口，可以把成本中心、内部订单、付款条件、基准日期、税码、付款方式、特别总账标识这些一起存下来。这一步千万别省，因为你省下来的每一次点击，都会在调用时变成一次手工补录，久而久之就没人用模型了——模型好不好用，直接决定它有没有人用。

行项目文本值得认真写。我习惯在行文本里写上模型用途和归属部门，比如"模型生成-间接人工分摊-生产一部"。这样凭证一旦生成，看行项目就知道来源，事后做账龄分析和科目余额表导出时也能一眼分辨，比生成后再去补抬头文本靠谱得多。

2.3 金额的三种填法：固定值、留空、百分比

这是模型里最需要动脑子的部分。金额栏可以填三种东西，行为完全不同：

第一种是固定金额。适合金额长期不变的场景，比如每月固定 5000 元的软件订阅费摊销。调用时系统直接带出金额，用户只要确认日期就能过账。缺点是容错性差，一旦金额变了而没人去改模型，就会连续几个月都记错金额——所以固定金额的模型一定要在描述里写明"金额调整需同步维护模型"。

第二种是留空。适合金额每期都变的场景，调用时用户手工录入。这是最常用也最安全的填法，缺点是每次都要算、要抄，容易抄错。我的做法是留空的同时，在行文本里写清"此处填当期总额，来源见 XX 台账"。

第三种是百分比。这是分摊场景的核武器，但也是最容易出问题的一种。百分比的含义是"占凭证总额的比例"，所以只有借贷两边的百分比各自合计都是 100% 时，这张凭证才是完整的。举个实际例子：借方三个成本中心分别填 30%、30%、40%，贷方分摊源科目填 100%，这才是可用的模型。

关于百分比模型的实际体验，我要说句实在话：不同版本里"基数从哪里来"这件事的表现不完全一致。我第一次用的时候，是在借方第一行填了当期总额，结果系统没有按我预期的比例分摊，改成在贷方分摊源科目上填总额，各行才正确带出。所以我的建议是——第一次上线百分比模型，先在测试系统里用一笔小金额（比如 1000 元）跑通全流程，确认哪一行是"基数输入行"，再放到生产上。不要拿真实的月度分摊金额去做第一次测试。

还有一个细节：百分比分摊在四舍五入时会产生分位差。30%、30%、40% 分摊 1000.01 元，很可能出来 300.00、300.00、400.01，也可能是 300.00、300.01、400.00，取决于系统的取整逻辑。如果差额落在最后一行，凭证能平；如果不落，就会出现借贷不平、无法过账。处理办法是：把最后一个分摊行的金额留空，让系统自动轧差，或者手工把最大那一行的金额倒挤出来。这个技巧我在五六个项目上都用过，屡试不爽。

2.4 字段状态：模型最被低估的能力

如果只能保留科目分配模型的一个功能，我会选字段状态。模型维护界面里可以针对每个字段设置"隐藏 / 显示 / 必输 / 可选"四种状态，调用模型时就会生效。

这个功能解决的是治理问题。举个我亲身经历的例子：某公司费用分摊模型里有六个成本中心，本来是想让会计只填金额，结果总有"聪明人"顺手把成本中心改成自己部门的，改完之后分录还平，系统也不报错，等到月末做部门费用分析时发现数据对不上，回头查了三天。后来把成本中心字段在模型里设成"隐藏"，问题当场消失——不是靠制度，是靠系统不给机会。

但字段状态有个必须知道的规则：SAP 里字段的最终显示状态是多个来源叠加的结果，取的是"限制最强"的那一级，优先级大致是 隐藏 > 必输 > 显示 > 可选。参与叠加的至少有四个来源：模型的字段状态、记账码的字段状态（OB41 一带）、科目主数据里的字段状态组（OBC4）、以及屏幕变式。所以经常出现"我在模型里设了可选，调用时字段却看不见"的情况——因为字段状态组把它设成了隐藏。搞清楚这个优先级，90% 的"字段状态不生效"问题就自己解决了。

我的经验是：能用模型字段状态解决的，就不要去动全局的字段状态组和记账码配置。全局配置是大炮，一改全公司所有凭证录入都受影响，风险和收益完全不对等。

2.5 跨公司代码标识与命名规范

前面提到跨公司代码标识，这里补充一句实操建议：如果一个模型只有一家公司会用，就不要勾跨公司代码。原因很简单，模型列表是全局的，勾得越多，列表越乱，找一个模型的成本越高。我在一个集团项目上看到过两百多个模型，一半勾了跨公司代码但实际只有一家公司在用，找模型的体验堪比大海捞针。

命名规范我建议三段式：业务类型 + 部门/范围 + 序号。比如FEE-ADMIN-01表示管理费用类第 1 号模型，ALLOC-PROD-03表示生产分摊第 3 号。模型描述用中文，写清楚"用途 + 借贷方科目 + 调用频率 + 维护责任人"。这几行字多花两分钟，能省掉未来无数次的"这个是干嘛的"。别用 "test1" "aa" "临时不要删" 这种名字，模型库烂掉基本都是从这几个名字开始的。

3. 动手实操：从零建一个可复用的分摊模型

3.1 创建前的准备工作

在动 FKMT 之前，我一般会先花十分钟确认下面这几件事，做完之后建模过程会顺畅很多：

• 确认科目已存在且未被冻结。借方分摊目标科目、贷方分摊源科目，都要在公司代码下建好，字段状态组设置正确，成本中心字段不是隐藏状态。
• 确认目标成本中心已存在且在有效期内。成本中心有有效期，模型里存的是成本中心编号，如果成本中心在调用时点上已经失效，过账会报错。
• 确认凭证类型和号段。如果打算用专用凭证类型，先确认号段已分配。
• 确认调用的用户有权限。模型的调用最终受过账权限控制（公司代码级、科目级），模型本身不会给你多一分权限。这一点在共享中心场景下尤其要注意，不然模型建好了没人能用。

准备阶段还有一件事容易被忽略：先在测试系统里建，不要直接在生产上试。模型是 client 级别数据，建错了删掉虽然成本不高，但在生产上留下几十个废模型，清理起来比新建麻烦得多。

3.2 分步操作：维护一个分摊模型

下面是我自己做过的标准流程，按顺序执行即可：

1. 进入维护界面。输入事务码进入科目分配模型维护（创建）。如果你不确定当前版本的具体菜单路径，从"会计核算 → 财务会计 → 总账 → 过账"这一层往下找"科目分配模型"即可，修改和显示通常在同一条路径的相邻条目里。另一条更省事的路子：直接在记账界面先把一张标准凭证录好，然后用界面上的保存为模型功能存下来，比从头录快得多。
2. 录入模型标识和描述。模型标识建议按上一节的命名规范来，描述写清用途。这一步系统会要求指定公司代码，除非你打开跨公司代码标识。
3. 设置抬头。凭证类型填 SA 或专用类型，货币填凭证货币，汇率类型保持默认，各种日期全部留空，参照字段我习惯填模型标识，这样生成的凭证可以用参照字段反查来源。
4. 录入行项目。先录贷方分摊源科目（记账码 50），金额填总额占位或留空；再依次录借方各分摊行（记账码 40），金额按百分比填。每录完一行，进明细把成本中心补齐。
5. 设置字段状态。用界面上的字段状态功能，把成本中心、科目、记账码这些不该被改的字段设为隐藏，把金额、日期这些必须填的设为必输。这一步按第 2.4 节的优先级规则来检查一遍。
6. 保存并做一次空跑验证。保存之后立刻在记账界面调用一次，用 1000 元这种小金额试一下，确认各行是否正确带出、字段是否按预期锁定。验证完不要过账，直接退出；如果要过账测试，记得在测试系统里做。

整个流程熟练之后五分钟以内能完成一个模型。如果超过十分钟还在调，大概率是准备工作没做够，回头看看第 3.1 节。

3.3 调用与过账：模型怎么被用起来

调用动作发生在记账界面上。在总账记账入口（FB50、F-02 这类界面）上，工具栏里通常都有调用模型的功能按钮，有的是一个图标，有的在编辑菜单下面。点开之后输入模型标识，系统会把行项目一次带出。

调用之后有几件事要特别注意：

• 模型不会被修改。你在调用界面上的任何改动，包括金额、日期、甚至把某一行删掉，都只影响这张凭证，不影响模型本身。这一点让人放心，但反过来也意味着：如果有人发现某行数据不对，改了当期凭证是没用的，下次调用还是错的，必须回到模型维护界面去改。这是最常见的沟通误解，值得在团队里强调一次。
• 带出来的日期通常是当天。如果模型里日期留空了，调用后系统一般默认当天，你可以手工改成需要的过账日期。
• 调用后行项目可以继续手工新增。比如某个部门这个月多发生了一笔，可以在模型带出的基础上直接加一行，最后把凭证配平即可——前提是"完整过账"的校验逻辑要求借贷平衡，这是逃不掉的。
• 抬头文本建议统一。我习惯在调用后把抬头文本统一写成"模型标识 + 期间"，比如ALLOC-PROD-03 202503。这样月底用科目行项目报表（FAGLL03 或旧版本的 FBL3N）导科目余额表时，按抬头文本一筛就能把所有模型生成的凭证捞出来核对，做月度复核效率极高。

3.4 复制扩展：一次建十个模型的正确姿势

模型维护界面一般都有复制功能，这是提升效率的关键。当你要建十个类似的分摊模型（比如十个部门各一个，只是成本中心不同），正确的做法不是从零录十次，而是：

1. 完整建好第一个模型，确认可调用、可过账。
2. 用复制功能生成第二个，只改成本中心和描述。
3. 依次生成剩余的，每生成一个就在记账界面空跑验证一次。

这样做的成本是每个模型大约一分钟，而从零录一个需要五到十分钟。我做过一次十二个部门的费用分摊，用复制的方式建完全部模型花了不到二十分钟，其中大部分时间花在验证上。另外提醒一句：复制出来的模型，描述一定要改，不然十个模型九个叫"XX分摊-副本"，三个月后就没人分得清谁是谁了。

3.5 结果校验：三张报表搞定复核

模型生成凭证之后，怎么确认它做对了？我固定用三个检查动作：

第二步是最重要的。用科目行项目报表按"参照字段"或"抬头文本"筛出当期所有模型生成的凭证，跟手工台账逐条对一遍金额。这一步做完，模型相关的账务基本就锁死了。我还习惯把筛出来的清单导成表格存档，月度归档的时候一起放进底稿，审计问起来随时能调。

4. 进阶玩法：把模型用出组合拳

4.1 模型加替代与校验，堵住手工改动的口子

模型解决"快"，替代和校验解决"对"。这两者组合起来才是完整的方案。具体说：

校验（Validation）用在入口拦截。比如你希望所有走模型的费用分摊凭证，借方成本中心必须在指定清单里，就可以配一条校验规则，一旦不在清单里就直接报错、不许过账。这比在制度里写"禁止使用其他成本中心"有效得多。

替代（Substitution）用在自动补全。比如模型调用后，系统自动根据借方成本中心推导出所属利润中心并回填，避免用户手工选错。这个在启用了凭证分割的环境里特别有用——凭证分割需要利润中心、段这类特征，模型里如果全靠人工填，出错概率很高，用替代自动推导是最稳的做法。

我的配置原则是：模型负责结构，替代负责派生，校验负责兜底。三层都装上之后，同一个模型可以被几十个人用，出错的概率依然极低。

4.2 模型加批量输入，一次过几百张

单个模型解决的是单人单次录入效率，如果一个月要过几百张结构相同的凭证（比如几百个门店各一张费用凭证），就得靠批量输入或者 LSMW 这类工具。这里有一个我踩过坑的重要结论：

用批输入（BDC）批量过账时，不要去调用模型，而是把模型"展开"成固定的行项目直接录进批输入数据里。

原因有两个。第一，模型调用在批输入录屏里表现为额外的屏幕跳转，屏幕序列一多，录屏就脆，换个补丁版本可能就跑了。第二，更关键的，模型里的字段状态设置会干扰录屏——你在批输入数据里给某个字段赋了值，但因为模型把它设成了隐藏，这个值根本进不去，而且系统不一定报错，可能就静默丢弃了。后果是批量过完账之后发现成本中心全空，只能全部冲销重来。

所以正确的做法是：先用模型把行项目结构确定下来，然后把结构翻译成批输入数据模板，用 BAPI 或批输入程序批量过账。如果一定要用 BAPI 走程序化过账，那就是另一套接口了，科目分配模型在这条路上帮不上忙——它本质上是给人工界面服务的工具。

4.3 模型加外币业务，汇率和金额怎么处理

外币场景下模型的使用有几个要点。首先，模型的凭证货币要设成外币，这样调用时汇率字段才会被激活；其次，汇率类型要跟你们的外币评估政策一致，通常用 M 类型（标准汇率）；第三，也是最容易踩的坑——调用之后一定要确认汇率取得是当期汇率，而不是模型里残留的旧汇率。我见过一次汇兑损益结转，模型里保留了上期的汇率，会计直接过账，结果当期凭证用的是两个月前的汇率，差异虽然不大，但月度汇兑损益分析和账面数差了三十多万，最后只能冲销重做。

另外，外币场景下模型的金额填法建议"外币金额留空、本币金额自动计算"，让人工只录一个数。如果两边都留空，很容易出现外币填了、本币忘了，然后系统按默认汇率算出一个意料之外的数字。

4.4 模型与凭证分割、利润中心的相互影响

启用了凭证分割之后，凭证里的清账行会被自动补充特征（利润中心、段等）。这会带来一个连锁反应：你的模型里如果预置了利润中心，而自动生成的清账行又要求填另一个利润中心，两边不一致时过账就会报错或者被拦下来。

处理思路有两种。一种是在模型里把利润中心字段留空，交给替代规则或字段状态自动推导；另一种是在模型里把所有行的利润中心显式写清楚，并且确认自动生成的清账行能取到同样的值。我个人推荐第一种，因为凭证分割的推导规则是全局统一的，模型里写死反而容易跟全局规则打架。这个问题在很多项目里都是在测试后期才暴露出来，建议在模型上线前专门跑一轮带分割的测试凭证。

4.5 模型加特别总账标识，处理预收预付

客户和供应商行上的特别总账标识可以在模型里预置。这个用在预收、预付、应收票据这类业务上效果很好，比如"每月固定计提某客户预收款"这种业务，把特别总账标识固定好，调用时只填金额和客户，效率提升明显。

但要注意的是，特别总账标识会影响科目确定和清账逻辑，改起来牵连比较广。如果模型里预置了特别总账标识，建议在模型描述里明确标注，并且定期检查：一旦科目确定配置有调整，这些模型要跟着一起复查。我有一个客户就是调整了特别总账标识的科目确定，结果三个模型默默生成了一批挂错科目的凭证，跑了两个月才发现。

5. 踩坑实录：常见报错与排查速查表

5.1 调用后金额不出来的几种原因

这是遇到频率最高的问题，通常有三个原因：

第一，模型里金额本来就是空的。这是设计如此，不是故障。如果希望金额自动带出，就得在模型里填固定金额或百分比。

第二，金额字段在模型里被设成了隐藏。隐藏状态下字段既不显示也不能录入，用户自然看不到金额。这种情况往往伴随另一个现象：调用后凭证的借贷方显示为零，无法过账。

第三，调用时选错了模型。这个听起来很蠢，但在模型数量超过五十个之后真的很容易发生，尤其是在模型命名没有规范的情况下。解决方法是回到第 2.5 节，把命名和描述做好，能省掉大量这类"幽灵问题"。

5.2 字段状态不生效的真相

再强调一次优先级：隐藏 > 必输 > 显示 > 可选。当模型的字段状态跟记账码、字段状态组、屏幕变式的设置冲突时，系统取限制最强的那一个。所以你设了"可选"却看不见字段，很可能是字段状态组设了隐藏；你设了"必输"却可以跳过，很可能是字段状态组设了隐藏导致字段根本不显示，必输校验也就无从触发（这是一个经典的逻辑陷阱）。

排查顺序我建议这样走：先看科目主数据的字段状态组，再看记账码的字段状态，再看模型的字段状态，最后看屏幕变式。一层层往上比对，基本三分钟能定位。

5.3 与科目、公司代码相关的报错

5.4 百分比模型的分位差与不平

前面提过，这里给一个可以直接照做的处理流程：调用百分比模型后先不要急着过账，看借贷合计是否相等；如果差几分钱，把金额最大的一行手工改掉，让差额落在它身上；或者干脆把最后一行清空重填。如果差额不是几分钱而是明显的大额差异，那就不是取整问题，而是百分比合计不等于 100%，回到模型维护界面检查一下。

5.5 系统迁移与 S/4HANA 落地时的坑

这是最近两年问得最多的一类问题。几个要点：

第一，模型跨 client、跨系统的搬运。模型是 client 级数据，正常走传输请求不会把它带走；如果你做的是整个 client 拷贝，它会跟着过去。所以在系统迁移项目里，一定要单独排一项"模型盘点与重建"的工作，否则新系统上线第一天，财务就会发现"我的模型全没了"。我建议的做法是先把生产上的模型导出成清单，迁移后按清单重建，重建完做一轮对账验证。

第二，S/4HANA 界面的变化。经典的总账记账界面在 S/4HANA 里依然可用，但 Fiori 端提供了基于模板的新做法，逻辑跟科目分配模型相似——都是预存一个凭证骨架供调用——但对象不同、存储位置不同，不能直接迁移。如果你们准备往 Fiori 走，建议在过渡期两条腿走路：GUI 侧继续用模型保生产，Fiori 侧同步把高频模型重建一遍，等大家都适应了再切换。

第三，字段状态的差异。不同版本对某些字段的默认显示状态有微调，原来靠默认值工作的模型，迁移后可能出现某个字段突然变成必输。这类问题在测试阶段很难靠人工发现，建议迁移后把所有模型逐个空跑一遍，用清单打勾确认。

6. 维护与治理：让模型库十年不烂

6.1 命名与描述规范

规范不用复杂，但必须统一。我推荐的最小规范是：模型标识用大写字母加连字符，格式为"业务域-范围-序号"；描述用中文，固定写成"用途｜借方科目｜贷方科目｜维护责任人｜最近复核日期"。五个字段看起来多，但真的能让接手的人三分钟看懂一个陌生的模型。我见过最糟糕的情况是一百多个模型只有编号没有描述，新来的会计只能靠一个个点开试，试到第八个的时候已经放弃用模型了。

6.2 变更与下线机制

模型最大的风险不是建错，而是过时了但没人删。业务变了、科目改了、部门撤销了，模型还在那儿，下次有人稀里糊涂调用，就生成一张科目已经作废的凭证。我的做法是每半年做一次模型盘点：把模型清单导出，按"最近 6 个月是否有凭证生成"标记一遍，无使用的模型标注待观察，连续一年无使用且有替代者的直接删除。删除前先用显示功能确认内容，别看见名字不对就删——我在一个项目上就差点删掉一个一年只用一次的年度计提模型，后来发现是年结专用，幸好删之前多看了一眼。

盘点这件事可以借助于报表来做：用科目行项目报表按抬头文本或参照字段统计各模型的使用频次，导出来排序，一目了然。

6.3 权限与审计的关注点

模型本身不授予任何权限，它只是一个模板。所以审计问"谁有权限用这个模型"的时候，答案其实是"谁有对应公司代码和科目的过账权限，谁就能用"。这是需要在制度层面说清楚的一点，别让人误以为模型是权限控制的工具。

审计上真正需要关注的是两件事：一是模型内容本身的合规性，比如预置科目是否符合会计准则、分摊比例是否有依据、字段状态是否锁住了不该让人改的字段；二是模型生成的凭证是否有复核痕迹，这个就靠抬头文本和参照字段的规范填写来实现。把这两点做好，审计抽查时能省掉大量解释时间。

6.4 我个人在实际操作中的体会

用了这么多年模型，我最大的体会是一句话：模型的价值不在技术，而在纪律。技术上建一个模型五分钟就够了，难的是让它持续被正确使用——命名不乱、描述完整、过时删除、字段状态锁死、每月复核。这五件事里任何一件放松，半年后模型库就会变成一堆没人敢碰的垃圾，然后大家重新回到手工敲凭证，白折腾一场。

再分享两个小技巧。第一个是关于调用体验的：如果你们团队的会计习惯在同一个界面连续做多张凭证，可以把高频模型的名字写在一张便签贴在显示器边上，比每次去列表里找快得多——这不是开玩笑，实际效果比任何技术优化都明显。第二个是关于复盘的：我习惯每个月把模型生成的凭证清单导出来，只看两个数——张数和总金额，跟手工台账对一次。这两个数对上，基本就能放心了；对不上，再往下钻明细。一分钟的检查，能挡住绝大多数问题。

如果后续要扩展，我觉得有两个方向值得投入：一是把高频模型跟替代规则打包成一套"标准记账包"，业务变了只改替代规则的参数表，不用动模型本身；二是把模型清单做进月结检查表，让盘点从"半年一次"变成"每月顺带完成"。这两件事的效果，往往比再多建十个模型要大得多。