企业官网建设流程全解析

孟繁光 2026-10-03

消费者看到的是便当、牛奶和面包可能便宜一些。SAP 顾问看到的，却可能是一张横跨财务、采购、销售、主数据、接口和测试团队的影响清单。

“把税率从 8% 改成 1%，不就结束了吗？”

如果企业只有一笔现金交易，问题或许容易处理。但真实业务里，有上个月的订单、下个月才到的货、按月汇总的账单，还有减税以后退回来的旧商品。

SAP 不仅要算对今天这笔税，还要解释清楚昨天的交易，并让所有关联单据保持一致。

本文就日本官方公开资料，从 SAP 实务角度拆解这次变化。

信息核对日期：2026 年 10 月 3 日。国税厅 9 月 15 日发布的特设页面明确说明，资料介绍的是内阁决定大纲中的改正案，以法案经国会审议、可决成立为前提。本文据此分析拟议方案，不将其表述为已经生效的法律。国税厅：消费税率下调特设网站

01｜先看清楚：哪些降到 1%，哪些不变？

官方公布的方案拟在2027 年 4 月 1 日至 2029 年 3 月 31 日，将符合范围的饮食料品消费税降至 1%。食品适用范围沿用现行轻减税率的食品范围；酒类、外食仍为 10%，符合条件的报纸定期订阅仍为 8%。1% 是国税 0.78% 与地方消费税相当部分 0.22% 的合计。国税厅：税率下调说明手册，第 1—3 页

这意味着，企业面对的并非“8% 消失、1% 接班”，而是需要同时管理1%、8%、10%，以及本来就存在的其他税务处理类别。

对消费者而言，假设税前价格不变，一件税前 1,000 日元的食品，含税价会从 1,080 日元变成 1,010 日元，便宜 70 日元。相对原含税价，降幅约为6.48%，而非直接便宜 7%。实际售价是否同比例下降，还取决于企业定价。

为什么讨论中会出现 1%，而不仅是 0%？系统改造是背景之一。日本财务大臣在 2026 年 4 月 28 日记者会上提到，收到过“1% 情况下，制度细节确定后需要约 5—6 个月改造”的报告，同时指出部分系统跨税率退货仍需人工处理。金融厅：记者会记录

这只是当时汇报的改造估计，不能直接当作某家企业 SAP 项目的工期承诺。

02｜不卖食品的公司，也可能需要改

首先提醒：零售、超市、食品相关商社会受到直接影响，但其他行业不能简单判断“与我无关”。

制造企业可能采购会议便当、饮用水和员工福利食品；能源企业的附属门店可能销售饮料；综合商社可能同时经营食品和非食品。

企业的主营行业，不能代替每一笔交易的税务判断。

对于食品零售商，影响可能集中在销售定价、收银和开票；对于普通制造企业，则可能更多落在采购、费用报销和供应商发票校验。

所以，项目的第一步应当是找出哪些业务实际用到了食品相关税务处理，再判断涉及哪些 SAP 对象。只按公司所属行业筛选，很容易漏掉费用端。

03｜新建税码只是起点，税码怎么被选中才是关键

手工凭证可以由用户选择税码，但采购、销售链路中的税码往往需要系统自动确定。

这里要区分两个概念：

• 税码：承载计算、进销项等税务属性。
• 税务确定逻辑：决定当前业务应该使用哪个税码、哪项税条件。

SD 可能涉及客户与物料税分类、条件记录、定价日期和复制控制；MM 则需要检查采购订单税码的来源、默认逻辑、相关主数据及增强。具体取决于企业现有设计，不能统一归结为“修改物料主数据就行”。

例如，同一款商品经过正常销售、退货、重新开票，税务处理可能不同。若程序只根据物料上的“食品”标识强制选择 1%，就可能误处理旧交易。

商品分类回答“这是什么”，交易场景和适用规则回答“这次怎么计税”。两者必须一起看。

税码维护也要考虑产品版本。SAP S/4HANA Cloud 的日本本地化文档介绍了时间相关税率功能（TDT），同时明确提醒：日本存在过渡处理，新税率需要定义新的税码。不能看到系统支持有效期，就直接覆盖旧税率。SAP Help：Japan — Processing VAT

对 ECC、S/4HANA 本地部署及不同云版本，应分别核对可用功能和本地化支持。实施时，进销项、科目确定、申报映射与销售定价记录也需要一并检查。SAP 的税码配置说明同样提示，新建税码后还需维护相关税务属性，并单独维护销售定价记录。SAP Help：Defining Tax Codes for Time-Dependent Taxes

04｜最容易出问题的，是跨期订单和旧货退回

最值得关注的例子，是“3 月发生的业务，4 月才完成后续处理”。

一张订单可能有下单日、出库日、交货日、验收日、开票日和过账日。它们并不总在同一天，甚至不在同一个月。

因此，不能把“4 月以后录入 SAP”直接等同于“按 1% 处理”。也不能为了配置方便，自行在几个日期中任选一个。

应先确定税务上适用的规则，再让系统日期、单据继承和重新计价逻辑实现这些规则。

国税厅拟议方案的 Q&A 对此给出了具体场景：切换前按 8% 销售的食品，切换后退货仍按 8% 调整；一定的定期供给合同、通信销售还存在过渡处理。对于买卖双方计上基准不同的情况，Q&A 也专门说明了买方依据卖方适用税率处理进项抵扣的情形。国税厅：税率下调 Q&A，问 1-4 至 1-6

换成一个简化的 SAP 测试案例：

3 月按 8% 销售税前 10,000 日元食品，收取 10,800 日元。4 月发生全额退货，如果系统按当前的 1% 生成退款，金额就会变成 10,100 日元，少了 700 日元。

问题不在乘法，而在于退货有没有正确继承原交易的税务信息。

需要检查的不只是退货订单，还包括贷项凭证、原单引用、税条件复制，以及冲销后重新开票。历史已过账凭证通常不会因为配置改变自动重写，但后续重新计算、重开票和报表取值可能受到影响。

这也是为什么旧税率必须保留，并且要有明确的使用边界。

05｜发票能打印出“1%”，不代表已经改完

对于日本的インボイス制度，即适格请求书制度。对 SAP 项目来说，发票输出往往是最容易低估的工作之一。

原来只预留“8% 合计”和“10% 合计”的模板，新增 1% 后，是否能正确扩展？一个月度账单中混有切换前后的交易，是否仍能分组汇总？财务凭证正确，输出程序会不会仍显示旧标签？

这些问题可能藏在 Smart Forms、Adobe Forms、电子账单平台，也可能藏在一段多年未改的 Z 程序里。

还要检查舍入。国税厅规定，适格请求书上的消费税额出现不足 1 日元的尾数时，应以一张适格请求书、每个税率一次为单位处理，不能逐商品舍入后再把结果相加作为该税额。国税厅：No.6371 端数计算

用一个测试例子就能看出区别：两项商品各 50 日元，税率 1%，假设采取舍去小数的方式。逐项计算会得到 0＋0＝0 日元；按同税率合计 100 日元计算，税额是 1 日元。

验收时，应把订单、账单、财务凭证和最终输出放在一起核对。只看页面上有没有“1%”，远远不够。

06｜SAP 改好了，外围系统可能还在用 8%

另一个现实问题：企业的税率逻辑很少只存在于 SAP 内部。

POS、电商平台、EDI、费用报销系统、仓储系统和数据仓库，都可能传递或使用税务字段。部分接口只传“轻减税率”标识，接收方再把它解释成固定的 8%；部分程序直接写着金额 × 0.08。

税率变化以后，这些旧假设就需要逐一验证。

可以沿着一笔交易检查：

前端订单 → 接口消息 → SAP 单据 → 财务过账 → 发票输出 → 报表对账。

每一站都要弄清楚，传递的是税率、税码、税务类别，还是已经计算好的税额；由谁决定适用规则；发生差异时由谁负责。

另外，配置可以提前部署，业务规则则按适用条件生效。如果企业在 3 月就开始接受 4 月交付的订单，相关系统可能需要提前识别新税码。不能等到切换日凌晨，才发现接口拒绝所有带新代码的单据。

07｜测试重点：新税率、旧业务和异常处理一起跑

这类项目最容易出现的假象是：新建一张 1% 发票成功，于是宣布测试通过。

真正有价值的测试，需要覆盖业务边界：

此外，方案只有两年期限。项目设计时还应预留期满后的再次切换，以及期间交易在期满后退货、调整的处理能力。

与其把“1%”写成新的固定值，不如借此把税率、适用日期和业务类别之间的关系整理清楚。

08｜给 SAP 顾问的一点启发

对项目团队而言，现在就能开展的工作，是盘点食品相关交易、税码使用情况、发票模板和接口中的固定税率；把尚待法律和官方细则确认的内容，单独列为设计前提。

等实施要求明确后，再据此完成配置、改造、联合测试与切换。

消费者最终关心的是少付多少钱。企业必须保证的是：这笔钱在收银台、供应商账单、SAP 凭证和税务报表里，都有一致、可追溯的解释。

从 8% 到 1%，数字只变了一处；围绕这个数字运转的整条业务链，都需要被验证。