企业官网建设流程全解析

简介：本资源是一份面向企业财务人员与SAP FICO模块实践者的深度技术教程，聚焦成本中心会计中最具实操难度的结算机制，系统解析成本结转的‘推’与‘拉’逻辑、分配与分摊差异、间接作业分配、定期重过账及累计分配等核心场景。内容基于SAP Press权威资料二次提炼，辅以原创截图、真实凭证示例和循环配置路径（如KSV1事务码），覆盖定义循环、段配置、追踪因素选择、迭代与累计逻辑等关键操作细节，助力读者准确实现跨部门成本归集与透明分摊。资源为单文件PDF，大小1.11MB，结构紧凑、图文并茂，适合作为日常运维参考或进阶学习速查手册。目前已有1882人学习下载，特别适合已掌握SAP基础操作、亟需打通成本核算落地瓶颈的财务管理者与ERP实施顾问。

1. SAP FICO成本中心结算不是“转账”，而是成本动因的显性化建模：搞懂“推/拉”逻辑才能避开90%的月末结账翻车

你有没有遇到过这种场景：月底跑完KSV5分配，生产部报表里突然多出一笔“行政管理费”，而HR同事坚称他们没申请过这笔支出；或者在KSU5分摊后，品质检测中心的成本要素贷方余额清零了，但系统里查不到任何凭证号，财务总监盯着屏幕问：“钱到底去哪了？”——这不是配置错了，是根本没理解成本中心结算的本质。它不是简单的会计科目平移，而是把隐性的组织协作关系（比如“人事部为产线提供招聘支持”“设备科为车间提供维保服务”）用可配置、可追溯、可审计的规则翻译成财务语言。本教程拆解的正是这套翻译引擎的核心机制：成本中心结算的四种技术路径——分配（Distribution）、分摊（Assessment）、定期重过账（Periodic Reposting）、间接作业分配（Indirect Activity Allocation）。它们分别对应四类业务真相：“谁该为谁买单”（推式分配）、“成本打包怎么分”（拉式分摊）、“先记总账再拆分”（重过账）、“没干够活但得按比例付钱”（间接作业）。适合已经能独立完成FI过账、创建成本中心主数据、维护作业价格，但一到CO期末结账就卡在“为什么结果和预期不一致”的FICO实操者。本文不讲SAP Press书里的定义复述，只讲我在某制造企业上线时，带着A同学连续三轮月结踩出来的参数边界、凭证痕迹和验证铁律。

2. 分配（Distribution）：初级成本要素的“原样搬运”，关键在追踪因素的数学洁癖与业务合理性对齐

分配是成本中心结算中最直观也最容易误用的机制。它的核心承诺是：发送方的每个初级成本要素（如5101010000工资、5101030000福利费），必须1:1、不加修饰地出现在接收方的同一成本要素下。这意味着你能清晰回答“生产部收到的25,000元工资，是从哪个部门、哪笔原始凭证来的”。但这个“原样搬运”的背后，是一套精密的数学模型，稍有不慎就会产出违背业务常识的结果。

2.1 分配循环的结构设计：抬头决定全局策略，段表头定义每组收发关系

分配循环（Transaction KSV1）不是单个配置项，而是一个三层嵌套结构：抬头（Header）→ 段（Segment）→ 发送方/接收方明细（Sender/Receiver Line）。新手常犯的错误是直接在段里填数字，却忽略抬头参数对整个循环的统治力。

# 在KSV1中配置抬头时，必须确认以下三项： # 1. 迭代（Iteration）：勾选与否决定系统是否循环计算 # - 场景：若A成本中心既是发送方（向B、C分配），又是接收方（从D接收），则必须勾选迭代 # - 风险：不勾选时，A收到D的费用后，不会将这部分新费用再向B、C二次分配，导致成本漏转 # 2. 累计（Cumulative）：控制金额计算的时间粒度 # - 勾选后：系统累计1至当前期间所有发送方金额 + 所有接收方追踪因素，再算当期应分配额 # - 不勾选：仅用当期发送方金额和当期追踪因素计算（易受单期波动影响） # 3. 对象货币（Object Currency） vs 业务货币（Business Currency） # - 对象货币：强制要求发送方与接收方成本中心主数据中"对象货币"字段一致（如都设为CNY） # - 业务货币：允许使用发送方实际过账币种（如USD），但需确保汇率已维护

提示：某次上线前测试发现，某海外子公司成本中心对象货币设为USD，而国内接收方为CNY，KSV5执行时报错“Currency mismatch in distribution”。根源不在段配置，而在抬头的“对象货币”标志被误启——关闭此标志，改用“业务货币”，问题立解。

段表头（Segment Header）才是定义具体收发关系的地方。这里的关键不是“填什么”，而是“为什么这样填”。例如“发送方规则”中的“固定比率”选项，表面看是输入一个百分比，实则绑定着“发送方值”标签页里的单价计算逻辑：

# 伪代码：固定比率模式下的发送金额计算 if 发送方规则 == "固定比率": # 系统先读取"发送方值"标签页中维护的"单价" unit_price = get_unit_price_from_sender_value_tab() # 如：0.5 CNY/人 # 再乘以接收方的追踪因素（如员工数） sender_amount = unit_price * receiver_tracking_factor # 如：0.5 * 200人 = 100 CNY else: # 其他模式（记账金额/固定金额）不依赖此单价 pass

2.2 追踪因素的生死线：6种可变部分类型如何精准映射业务动因

追踪因素（Tracing Factor）是分配的灵魂。它决定了“为什么A收30%、B收20%”。SAP提供了6种基础类型（实际成本、计划成本、实际消耗、计划消耗、实际统计关键指标、计划统计指标），但真正决定成败的是选择条件（Selection Condition）与可变部分类型的严格匹配。常见错误是看到“实际消耗”就直接选，却忽略成本要素主数据中是否勾选了“记录数量”。

-- 验证成本要素是否支持"实际消耗"作为追踪因素 SELECT kstar AS cost_element, menge AS quantity_recorded_flag -- 'X'表示勾选了"记录数量" FROM skat WHERE kstar IN ('5101010000', '5101240000') -- 工资、水电费 AND spras = 'E'; -- 结果：5101010000的menge='X'（可作实际消耗追踪），5101240000的menge=' '（不可！）

注意：某客户曾用“水电费”（5101240000）作为发送方，设置追踪因素为“实际消耗”，执行KSV5后所有接收方分配金额为0。排查发现该成本要素主数据未勾选“记录数量”，系统无法读取消耗量，自动跳过该段。解决方案：要么改用“实际成本”类型（基于金额占比），要么重新激活成本要素的数量记录功能。

2.3 “量度负方向跟踪因素”的6种处理逻辑：当业务数据出现负值时的数学救赎

现实业务中，追踪因素完全可能为负。例如：某成本中心上月员工离职数大于入职数，统计关键指标“净增员工数”为-5；或某车间设备故障导致“有效工时”为负偏差。SAP用6种策略处理负值，但文档极少说明其业务含义。我们用真实案例对比：

• 选“标准刻度(2)”：系统将最大负值（-100）置0，并给所有其他值+100，使全部非负。适用场景：当负值是统计误差（如离职数多计），且需保证所有接收方都有正向权重。
• 选“负到零(4)”：所有负值直接归零，不补偿。适用场景：负值代表无效接收方（如停工车间），不应参与分配。
• 选“最小负到零(5)”：仅将最小负值（-100）置0，其余值按比例增加。适用场景：负值有业务意义（如研发部门本月净减员），但需避免其拖累整体分配。

血泪经验：某项目上线首月，因启用“标准刻度”，导致某停工车间（追踪因素-80）被置0后，其他车间权重暴涨，分摊额超预算300%。紧急切换为“负到零”，问题当日解决。从此我养成了习惯：配置前必查追踪因素历史值分布，预判负值出现概率。

3. 分摊（Assessment）：次级成本要素的“黑匣子打包”，为什么接收方看不到原始成本构成？

如果说分配是“透明快递”，分摊就是“密封包裹”。它把发送方的所有初级成本（工资、折旧、水电）和次级成本（如内部服务费）打包成一个统一的次级成本要素（类型42），过账到接收方。好处是简化核算（接收方只需关注一个成本要素），坏处是丢失明细（你无法知道这10万元“管理费”里工资占多少、折旧占多少）。这恰恰是分摊存在的业务前提：当成本构成对下游决策无意义，或披露成本构成会引发部门间争议时，分摊是更优解。

3.1 分摊循环与分配结构的双轨制：如何让不同成本要素走不同通道？

分摊循环（KSU1）的配置界面与分配循环高度相似，但有一个致命差异：它不直接指定发送哪些初级成本要素，而是通过“分配结构（Assessment Structure）”间接控制。这是SAP设计的精妙之处——将“分摊什么”与“怎么分摊”解耦。

分配结构Z2（事务码KSES维护）： ┌─────────┬──────────────────────────────┬──────────────────────────────┐ │ 序号 │ 源成本要素范围 │ 分摊成本要素（类型42） │ ├─────────┼──────────────────────────────┼──────────────────────────────┤ │ 010 │ 5101010000 ~ 5101120000 │ 9900010003（品质检测-人工成本）│ │ 020 │ 5101130000 ~ 5101480000 │ 9900010004（品质检测-其他成本）│ │ 030 │ 5101420200, 5101240000 │ 9900010005（厂房运营费） │ └─────────┴──────────────────────────────┴──────────────────────────────┘

• 为什么需要分配结构？
  假设发送方是“品质检测中心”，其成本包含：人工（5101010000）、耗材（5101300000）、设备折旧（5101420200）。业务要求：人工成本分摊给各产线，耗材成本分摊给各产品族，折旧成本分摊给各车间。若只用一个分摊循环，无法实现这种差异化路由。分配结构就是路由表。

• 配置陷阱：
  在KSU1中指定分摊循环时，“分摊成本要素”字段必须留空！否则系统会忽略分配结构，强行使用你填的单一成本要素，导致所有源成本都打包装进同一个42类要素，彻底丧失分类意义。

3.2 分摊凭证的不可见性：如何从S_ALR_87013611报表中定位“消失”的凭证？

分摊执行后（KSU5），你在发送方成本中心报表（S_ALR_87013611）中会看到：初级成本要素借方余额不变，但贷方出现了一笔类型42的分摊成本要素（如9900010003）。接收方报表则显示借方新增同笔42类要素。但你永远找不到一张凭证号（Document Number）同时包含发送方贷方和接收方借方——因为分摊凭证是系统后台生成的CO凭证（CO Document），不产生FI凭证（FI Document），故不在FB03中显示。

-- 查询分摊产生的CO凭证（需权限：CO document display） SELECT belnr AS co_document_number, gjahr AS fiscal_year, bukrs AS company_code, kostl AS cost_center, kstar AS cost_element, dmbtr AS amount_in_local_currency, shkzg AS debit_credit_indicator -- 'S'=贷方, 'H'=借方 FROM coep WHERE belnr IN ( SELECT belnr FROM coep WHERE kostl = 'Z800200010' -- 发送方成本中心 AND kstar = '9900010003' -- 分摊成本要素 AND shkzg = 'S' -- 贷方 AND gjahr = '2024' AND perio = '06' ) AND gjahr = '2024' AND perio = '06' ORDER BY belnr, shkzg; -- 结果：同一belnr下，既有kostl='Z800200010'（发送方）的S行，也有kostl='Z800202020'（接收方）的H行

提示：某客户财务坚持认为“分摊没成功，因为FB03查不到凭证”。我带他运行上述SQL，导出CO凭证明细，指着同一凭证号下的发送方贷方和接收方借方行项目说：“这就是分摊的DNA，它活在CO模块，不在FI模块。”从此他养成了查COEP表的习惯。

3.3 分摊与分配的本质差异：一张表看懂何时该用哪种机制

注意：某次优化月结流程，将原用分配的“IT服务费”改为分摊。上线后IT部门抱怨：“以前能看到各业务部门用了多少服务器小时，现在只看到一个总数！”——这暴露了机制选择的根本原则：分配服务于成本溯源，分摊服务于成本管控。切勿为省事而牺牲管理需求。

4. 定期重过账（Periodic Reposting）与间接作业分配（Indirect Activity Allocation）：当“先记总账”和“反向推算”成为唯一解

定期重过账和间接作业分配，是成本中心结算中最具业务智慧的两种机制。它们不解决“成本该不该转”，而是解决“成本怎么转才最高效、最贴近现实”。前者是操作层面的效率妥协（手工记账太慢，先总后分），后者是计量层面的业务妥协（作业量无法直接测量，只能反推）。二者共同点是：结果与手动操作（KB11N/KB21N）完全一致，但过程全自动、可复现。

4.1 定期重过账：为什么发送方报表里“借方余额直接变零”？

定期重过账（KSW1/KSW5）的视觉冲击力极强：执行前，发送方成本中心（如“厂房管理部”）的“水电费”借方余额是100,000元；执行后，该余额变为0，且凭证查询（S_ALR_87013611）中找不到任何贷方行项目。这不是Bug，而是SAP的底层设计哲学——重过账不是“结转”，而是“修正原始过账”。

执行KSW5前的发送方凭证流： FI凭证 10000001：借：水电费 100,000 → 成本中心Z800200010（厂房管理部） 执行KSW5后的状态： - 成本中心Z800200010的水电费借方余额 = 0 - CO凭证 20000001：借：水电费 X → 成本中心Z800202020（砂芯成型） - CO凭证 20000002：借：水电费 Y → 成本中心Z800202030（缸体成型） - ...（无贷方凭证！）

• 技术原理：KSW5并非新增一笔贷方，而是调用系统函数REPOST_COSTS，直接修改COEP表中原始借方行项目的kostl（成本中心）字段，将其从Z800200010更新为各接收方成本中心。因此，原始借方记录被“移动”了，而非被冲销。
• 业务价值：避免了“先记总账、再冲销、再分录”的三步操作，减少凭证数量，提升月结速度。某汽车厂月结时间因此缩短47分钟。

避坑：某次配置KSW1时，在“发送方/接收方”标签页误将“发送者”设为内部订单（IO），而非成本中心。执行KSW5时报错“Invalid sender object”。根源在于：定期重过账的发送方必须是成本中心或内部订单（文档写明），但接收方只能是成本中心。检查路径：KSW1 → 段 → 发送方/接收方标签 → “发送者”字段右侧的“对象类型”下拉框，确认为“KOSTL”（成本中心）。

4.2 间接作业分配：用“接收方的作业量”反推“发送方的作业量”的数学游戏

间接作业分配（KSC1/KSC5）是作业成本法（ABC）落地的关键。它解决了一个经典难题：发送方（如设备维保中心）的作业量（维修工时）无法精确计量，但接收方（各产线）的作业量（设备运行工时）却有完整记录。系统通过建立二者间的数学关系（如“每运行100分钟需维修5分钟”），用接收方的已知量反推发送方的未知量。

# KSC1中“参考加权因素”标签页的核心公式 # 发送作业数量 = Σ(接收方追踪因素 × 权数) / 所有因素 # 其中： # - 接收方追踪因素：如MACH01（设备工时）= 1000分钟 # - 权数：由业务专家设定，如“维修系数”= 10 # - 所有因素：所有接收方权数之和 = 100（示例中三个接收方权数分别为10,20,70） # 计算过程： total_weighted_factor = (1000 * 10) + (800 * 20) + (1200 * 70) = 10,000 + 16,000 + 84,000 = 110,000 all_factors = 100 sender_activity_quantity = total_weighted_factor / all_factors = 110,000 / 100 = 1100 minutes # 各接收方分配量： receiver_A_quantity = 1000 * 10 / 100 = 100 minutes receiver_B_quantity = 800 * 20 / 100 = 160 minutes receiver_C_quantity = 1200 * 70 / 100 = 840 minutes # 总和 = 100 + 160 + 840 = 1100 minutes ✓

• 作业类型分类的硬约束：
  KSC1中“活动类型”字段只能选择分类为“02-间接决定，间接分配”或“03-手工决定，间接分配”的作业类型。若选错（如选了分类01的“直接决定”作业类型），KSC5执行时会静默失败，无报错，但结果为0。验证方法：事务码KA02查看作业类型主数据，“分类”字段必须为02或03。

• 权数的小数位数陷阱：
  “参考加权因素”标签页中的“所有因素”不仅用于计算，还控制结果精度。若设为100，分配量保留两位小数；若设为1000，保留三位。某客户要求分配量精确到秒（1分钟=60秒），将“所有因素”设为6000，权数相应放大，完美解决。

5. 避坑指南：成本中心结算中5个高频翻车现场与血泪修复方案

成本中心结算配置看似简单，但因涉及多模块（FI、CO、PM）、多时点（过账、计划、实际）、多对象（成本中心、作业类型、统计指标），极易陷入“配置没错，结果不对”的玄学困境。以下是我在某跨国制造集团三年内记录的真实踩坑案例，每一条都附带可立即执行的排查命令。

5.1 现象：KSV5执行成功，但接收方报表（S_ALR_87013611）中无任何数据

原因：接收方成本中心主数据中“结算接收方”标志未激活。SAP默认成本中心不可作为接收方，需手动开启。
解决：

1. 事务码KS02进入接收方成本中心主数据
2. 切换到“控制”标签页
3. 勾选“结算接收方”（Settlement Receiver）复选框
4. 保存并激活

提示：此标志在KS01创建成本中心时默认不勾选，但文档极少强调。某次上线，12个接收方中有3个遗漏，导致整批分配失效。

5.2 现象：分摊（KSU5）后，发送方成本中心报表中初级成本要素贷方出现，但金额为0

原因：分配结构（KSES）中定义的“源成本要素范围”与发送方实际过账的成本要素不匹配。例如结构中写5101010000~5101120000，但发送方过账的是5101010001（工资-加班费），超出范围。
解决：

1. 运行事务码KA03，输入发送方成本中心，查询其所有过账的成本要素
2. 将结果导出，与分配结构中的范围比对
3. 在KSES中扩展范围（如改为5101010000~5101129999）或新增一行精确匹配

5.3 现象：间接作业分配（KSC5）执行后，CO凭证中发送方作业数量正确，但接收方成本为0

原因：作业类型价格（KP26）未维护或维护错误。间接作业分配计算金额=发送数量×作业价格，若价格为0或未维护，则金额为0。
解决：

-- 快速验证作业价格 SELECT vornr AS version, plvar AS plan_version, kstar AS cost_element, kbetr AS price_per_unit, peinh AS price_unit FROM tka01 WHERE vornr = '00' AND kstar = 'LABO01' -- 你的作业类型 AND gjaht = '2024'; -- 当前财年 -- 若无结果或kbetr=0，则需在KP26中维护

5.4 现象：定期重过账（KSW5）执行后，发送方余额清零，但接收方无任何数据

原因：KSW1中“发送方/接收方”标签页的“接收者”字段未指定成本中心，而是留空或填了错误对象。
解决：

1. 进入KSW1，找到对应循环段
2. 切换到“发送方/接收方”标签页
3. 在“接收者”字段，点击右侧“...”按钮，从弹出列表中选择正确的成本中心（KOSTL）
4. 关键：确认“对象类型”下拉框中显示“KOSTL”，而非“KOIN”或“PRPS”

5.5 现象：所有结算执行完毕，但总成本不平衡（发送方转出总额 ≠ 接收方转入总额）

原因：追踪因素为0的接收方被系统自动排除，导致分母变小，分配比例失真。例如3个接收方追踪因素为[100, 200, 0]，系统按100:200分配，0的那个不参与，但业务要求它分得固定比例。
解决：

• 方案A（推荐）：在KSV1/KSU1的“段表头”中，“接收方规则”选“固定百分比”，手动输入每个接收方的百分比（如33.3%, 33.3%, 33.4%）
• 方案B：在“接收方追踪因素”标签页，为追踪因素为0的接收方，手动维护一个极小值（如0.001），避免被过滤

6. 验证闭环：用三张报表+一个SQL脚本构建不可绕过的结算审计链

配置完成只是开始，真正的挑战在于证明结算结果既准确又合规。我从不依赖单一报表，而是用一套组合拳：发送方报表（S_ALR_87013611）验证“转出正确”，接收方报表（S_ALR_87013611）验证“转入正确”，CO凭证（COEP）验证“凭证一致”，最后用SQL脚本做全量校验。这套方法在某审计项目中，帮客户提前2周发现分摊循环配置错误，避免了百万级调整。

6.1 报表验证的黄金三角：三步锁定问题模块

第一步：发送方报表（S_ALR_87013611）

• 输入发送方成本中心、期间、版本（0实际）
• 关注“实际”列：初级成本要素借方余额应等于“分配”、“分摊”、“重过账”三列之和
• 若不等，问题在发送方配置（如KSV1中“发送方规则”选错）

第二步：接收方报表（S_ALR_87013611）

• 输入任一接收方成本中心、同期、版本
• 关注“实际”列：所有接收的初级成本要素（分配）或次级成本要素（分摊）借方余额，应与发送方报表中对应行项目一致
• 若不等，问题在接收方主数据或循环段配置

第三步：CO凭证穿透（S_ALR_87013611 → 凭证详情）

• 在接收方报表中，双击任意一笔分配/分摊/重过账行项目
• 点击“凭证”按钮，进入CO凭证明细
• 核对：凭证号（BELNR）、期间（PERIO）、公司代码（BUKRS）、成本中心（KOSTL）、成本要素（KSTAR）、金额（DMBTR）是否与报表一致

提示：某次客户质疑“分摊金额不准”，我当场打开S_ALR_87013611，双击接收方行项目，穿透到CO凭证，再点击凭证号旁的“凭证流”按钮，直接跳转到原始FI凭证（BKPF/BSEG），展示“水电费100,000元”如何从银行账户出发，经成本中心，最终分摊到各车间——证据链瞬间闭合。

6.2 自动化校验SQL脚本：10分钟跑完全量结算一致性检查

手动核对百个成本中心不现实。我编写了一个标准SQL脚本，部署在数据库层，每次月结后自动运行，输出差异报告。核心逻辑是：提取所有结算凭证（KSV5/KSU5/KSW5/KSC5生成的CO凭证），按发送方-接收方-成本要素聚合，与报表数据比对。

-- 脚本名：co_settlement_audit_2024.sql -- 功能：校验指定期间内所有结算的发送方转出总额 = 接收方转入总额 WITH settlement_docs AS ( -- 提取所有结算产生的CO凭证（KSV5/KSU5/KSW5/KSC5） SELECT belnr, gjahr, perio, kostl AS sender_cost_center, kstar AS cost_element, dmbtr AS amount, shkzg AS dc_indicator, CASE WHEN kstar LIKE '9%' THEN 'ASSESSMENT' -- 类型42成本要素 WHEN perio IN (SELECT perio FROM t001b WHERE bstat = 'KSV5') THEN 'DISTRIBUTION' WHEN perio IN (SELECT perio FROM t001b WHERE bstat = 'KSW5') THEN 'REPOSTING' ELSE 'INDIRECT_ACTIVITY' END AS settlement_type FROM coep WHERE gjahr = '2024' AND perio = '06' AND belnr IN ( -- 获取所有结算凭证号（需根据实际日志表或自定义表填充） SELECT belnr FROM z_co_settlement_log WHERE period = '202406' ) ), sender_summary AS ( -- 发送方转出汇总（贷方） SELECT sender_cost_center, settlement_type, SUM(CASE WHEN dc_indicator = 'S' THEN amount ELSE 0 END) AS total_sent FROM settlement_docs GROUP BY sender_cost_center, settlement_type ), receiver_summary AS ( -- 接收方转入汇总（借方） SELECT kostl AS receiver_cost_center, settlement_type, SUM(CASE WHEN dc_indicator = 'H' THEN amount ELSE 0 END) AS total_received FROM coep WHERE belnr IN (SELECT belnr FROM settlement_docs) AND gjahr = '2024' AND perio = '06' GROUP BY kostl, settlement_type ) SELECT s.sender_cost_center, s.settlement_type, s.total_sent, COALESCE(r.total_received, 0) AS total_received, ABS(s.total_sent - COALESCE(r.total_received, 0)) AS difference FROM sender_summary s LEFT JOIN receiver_summary r ON s.sender_cost_center = r.receiver_cost_center AND s.settlement_type = r.settlement_type WHERE ABS(s.total_sent - COALESCE(r.total_received, 0)) > 0.01; -- 容差0.01 -- 输出：所有差异大于0.01的发送方-接收方对，供人工复核

• 部署方式：将脚本存为co_settlement_audit_2024.sql，每月初由DBA定时执行，结果邮件发送至FICO团队
• 效果：某次运行发现“分摊”类型下，发送方Z800200010转出1,200,000元，但接收方汇总仅1,199,999.98元，差0.02元。追查发现是“绝对值（负到正）”处理逻辑导致的舍入误差，属正常现象，无需干预。

从那以后我每次配置完一个新循环，都强制走一遍这三张报表+SQL脚本的验证闭环。不是信不过自己，而是信不过人类在高压下的注意力。希望帮到你。

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