Microsoft Dynamics 365 Finance Functional Consultant (MB-310)

**Posting Profile 把子账和总账分开看** — Posting Profile 是 MB-310 最核心也最容易丢分的概念。每个子模块（AP / AR / Fixed Assets / Inventory / Bank）都有自己独立的 Posting Profile，定义了子账事件（Vendor Invoice 过账、Customer Payment 收款、Asset Depreciation 折旧）应该借贷哪个总账科目。**陷阱**：Posting Profile 支持按 Table / Group / All 三个级别配置（Table = 特定 Vendor/Customer/Asset，Group = Vendor Group / Customer Group / Asset Group，All = 默认），系统按 Table → Group → All 顺序查找。考试场景："为 VIP 客户 C001 单独配置了一个 AR Posting Profile，但过账时仍然用了 Customer Group 的配置，为什么" — 答案是 Table 级别的 Posting Profile 必须在 Customer 主数据上显式指定，系统不会自动按 Customer ID 匹配 Table 级别配置。**另一个陷阱**：Posting Profile 和 Main Account 的关系是"每个事件类型对应一个科目"，不是一个 Posting Profile 对应一个科目——一个 AP Posting Profile 里同时定义了 Summary Account（应付总账）、Arrival（在途应付）、Offset（清账对方）、Settlement Discount 等多个事件的科目映射。

**子账到总账的集成机制（Subledger Journal）** — D365 Finance 的子账过账经过 Subledger Journal 这个中间层：子账事件先生成 Subledger Journal（可以预览），再根据设置转成 General Ledger Journal（实际过账到总账）。**两种过账模式**：(1) **Synchronous**（默认）— 子账事件立即同步过账到总账，速度慢但实时；(2) **Asynchronous (Transfer to General Ledger)** — 子账先批量累积，定时任务批量转入总账，性能好但有延迟。**考试场景**："客户抱怨 AP Invoice 过账非常慢影响工作，怎么优化" — 答案是把 Accounts Payable parameters 里的 Transfer to General Ledger 改为 Asynchronous + Batch。不要混淆成"关闭过账验证"或"减少 Financial Dimension"。

**Fixed Assets 折旧方法选错场景** — Fixed Assets 有多种 Depreciation Method：Straight line service life、Straight line life remaining、Reducing balance、Manual、Factor、Consumption。**最容易出错的是 "Straight line service life" vs "Straight line life remaining"** — 前者按资产的总 Service Life 匀速折旧（即使中途提高资产价值或改变剩余寿命，每期折旧额不变直到最后追溯调整），后者每次重新按 **剩余** 价值和 **剩余** 寿命重新计算每期折旧额（资产重估或寿命变更后立即反映在下一期折旧里）。考试场景："客户要求当资产做 Write-up 调整后，新的折旧额从下个月就生效" — 答案是 Straight line life remaining，不是 Straight line service life。另一个陷阱：**Low Value Pool**（小额资产池）只对应特定国家税务规则（澳洲、新西兰），默认不启用，有专门的 Asset Group 配置。

**Tax Code vs Tax Group vs Item Sales Tax Group 的组合机制** — D365 的税务配置是三层嵌套：**Sales Tax Code** 定义税率和计算方式（如 GST 10%、VAT 20%），**Sales Tax Group** 是 Tax Code 的集合绑在 Customer / Vendor 上（代表"这个客户可能涉及的所有税种"），**Item Sales Tax Group** 是 Tax Code 的集合绑在 Product 上（代表"这个商品可能涉及的所有税种"）。**系统实际用哪个 Tax Code = Sales Tax Group 和 Item Sales Tax Group 的交集**。考试场景："客户 Sales Tax Group 里有 [GST, PST, Exempt]，商品 Item Sales Tax Group 里有 [GST, Exempt]，过账时会用哪个 Tax Code" — 答案是 GST 和 Exempt（两个交集），不是客户 Tax Group 里的所有税种。很多人漏掉交集这一步直接选 Sales Tax Group 的内容而丢分。

**Budget Control vs Budget Planning 完全是两个东西** — 这是 MB-310 最常见的概念混淆。**Budget Control** 是 **实时预算约束** — 配置 Budget Control Rules 后，当用户过账 Purchase Order / Purchase Requisition / General Journal / Expense Report 时，系统实时检查"本次过账会不会超过该维度组合的预算余额"，超支时根据配置显示 Warning 或 Hard Stop。**Budget Planning** 是 **预算编制工作流** — 完全独立的模块，提供预算创建的多阶段流程（Budget Plan Template + Stages + Workflow + Worksheet），供财务团队协作编制下一年度预算，编制完成后可以 Generate Budget Register Entries。考试场景："客户希望预算编制过程有多轮审批" → Budget Planning；"客户希望采购单超预算时禁止过账" → Budget Control。两者可以一起用但不是一个东西。

**Consolidation 的三种方式和适用场景** — D365 Finance 有三种财务合并方式且每一代技术都不同：(1) **Consolidate Online**（传统方式）— 把多个 Legal Entity 的过账数据复制到一个专门的 Consolidation Legal Entity，支持 Elimination Rules，但只是快照式，维护起来比较重。(2) **Financial Reports (Management Reporter) 合并**— 通过 Reporting Tree 定义集团层级，不复制数据到新 Legal Entity，直接在报表层做合并，适合只需要合并报表不需要合并账本的场景。(3) **Consolidation via Electronic Reporting / Global Consolidation（新）**— 2021+ 新功能，支持更复杂的多 Ledger 合并。考试场景："客户只需要每月看到集团合并的损益表和资产负债表，不需要在合并后的数据里做二次调整" → Financial Reports (Management Reporter) 方案，不需要 Consolidate Online。

**Accounts Payable Invoice Matching 的 Two-way / Three-way / Charges Matching 差异** — AP Invoice Matching Policy 有三种级别：**Two-way matching** 对比 Vendor Invoice 的单价和数量与 Purchase Order，差异超过容差则阻止过账；**Three-way matching** 额外对比 Product Receipt（收货单）的数量与 Invoice，确保没收到货不能付款；**Charges matching** 对比 Invoice 上的杂费（运费、关税）与 PO 上预期的杂费。**考试陷阱**：Matching Policy 可以在三个级别设置——Company-level default、Vendor-level、Item-level，系统按 Item → Vendor → Company 优先级查找，Item 最优先。场景题："客户对所有 Vendor 默认 Two-way matching，但对 Vendor V001 要求 Three-way，该怎么配置" — 答案是在 Vendor V001 主数据上单独设 Three-way，而不是改 Company-level 默认值。