撰稿人：金蝶-牛捷    指导老师：刘航辉、王云

【温馨提示：因企业业务场景存在不同程度的差异，案例仅供参考，请根据现场实际业务情况探讨最优解决方案，并在上线前进行充分验证。】

一、业务背景

1、客户业务现状

A企业为网状管理的工程设计类企业，其下存在10家事业部，各个事业部下有多个子公司，分别负责该企业面向工程不同环节的设计。企业围绕项目开展实际业务活动，从各个事业部分别抽取所需的人力资源及设备资产组建项目组。人员同时受到项目组的管理与法人企业的行政管理，为多个项目服务。

在项目组开展业务时，差旅、费用都需要进行成本计算。在报销的过程当中，针对于同一个差旅、费用可能涉及多个部门，需要根据实际情况将成本分摊至各个部门及项目进行核算。

2、客户诉求

在项目组开展业务时，希望根据不同分子公司的一些核算习惯、要求，对差旅、费用业务实现如下场景的费用分摊：

1）直接生成分摊结果凭证；

2）报销单生成费用归集凭证，分摊单生成费用分摊结转凭证；

3）分摊单直接生成费用分摊凭证且避免报销单重复生成。

二、基本说明

首先需了解，成本分摊要做的事项是将一项或几项成本按照条件分割成更细的成本组成。那么，其最终提供到核算侧的结构性数据分为：

1， 分摊对象（来源单据）：也即分摊主体，分摊结果的数据来源。

2， 分摊规则（分摊依据）：分摊的方式、条件、依据来源和设置方式。

3， 分摊结果（目标单据或单据体）：分摊结果对应的载体，也即更细的成本组成。

图1 费用报销单表内分摊

常见的分摊场景来源单据及其分摊实现逻辑如下表：

再切换回财务视角，财务对于成本分摊的转化其实着眼于维度核算，那么业务数据来源也就约束了可以用来参与分摊的维度类型，也即上述表中的分摊规则。

三、需求场景与实现要点

针对费用分摊处理与分摊凭证实现，常见有三种需求场景，具体如下表：

需求场景一

仅需实现分摊凭证生成——可简化采取表内分摊方式。该情况下可以直接进行表内分摊，在同一张单据上生成分摊到明细的成本分录。

（1）分摊过程

单据内分摊的本质是创建费用明细下的子表体，以场景中的费用报销单为例，也即形成费用明细下的下级明细，对每行费用明细再一次进行拆分。最终形成最明细的成本数据，用以进行财务核算，生成凭证。

图2 分摊过程

（2）配置要点

配置上，以核算所需结果作为起点，针对所需要生成的凭证分录，针对的分别对费用明细行和分摊明细行进行取数。

图3 跨表体取数

注意：注意维度来源及凭证数据源配置容易产生的数据问题。所有数据的来源，以金额为最末级，其他值不允许取下级。也就是说，若金额来源于明细分录行，那么维度、币别等皆不可取分摊数据行，否则会导致生成分摊行数的明细分录金额凭证分录，使得凭证金额翻倍。反之，若金额来源为分摊数据行，则皆可取值。

（3）优缺点

该方案的优势在于：

1、 核算的单据只有一张，减少财务和审核的工作量。

2、 同一张单据，便于直观的检查数据问题，确定是否存在因为财务取数导致的账实不符。

3、 凭证量相对较少，且不会出现期间跨越。

缺点在于：

1、 因为核算单据单一，配置模板时需要考虑不同维度和金额的取值，需要完全能结转分摊，相应配置凭证模板时会更加复杂。

2、 单张单据核算整体分摊成本，会带来更长的审核流程，可能导致涉及分摊的业务在财务数据成本统计时相对滞后。

3、 无法分步体现分摊过程。

需求场景二

分摊结果需单独体现过程，生成归集凭证、分摊结转凭证——采取表外分摊。

（1）分摊过程

该场景下，客户需要费用报销单只体现报销业务，成本分摊则单独由费用报销单下推分摊单，在分摊单进行分摊明细的成本核算，业务产生两张单据，分别生成两张凭证。

这样，在报销凭证时可以先将所有成本归集到某个公共项目，再通过分摊凭证进行结转。

图4 分摊跨期间核算

（2）配置要点

因为什么时候分摊，什么时候分摊结果审核完成是不确定的。那么分摊目标的凭证和分摊结果的凭证，记账期间可能会产生跨越。

故而，要尤其注意其中是否涉及损益类科目，往来类科目：

1、 前者涉及结转损益时，结转的发生，在上期结转完成后，当期会出现合计为零，但同金额的双向/正负数的损益结转，若需避免，则要严格要求分摊需在业务记账同期处理。

2、 后者涉及到期日及账龄计算，其账龄的实际计算会衍生至分摊单据的业务日期/到期日，如果需要严格计算，则避免取系统日期，业务日期及到期日取值皆需取可传递的一致性日期字段。

图5 分摊往来核销

（3）优缺点

该方案的优点在于：

1、 分摊单据独立，可以先将成本整体核算入账，财务数据对于成本的统计不容易滞后。

2、 独立单据承载分摊结果数据，分摊的核算和计算方式更具可操作性。

3、 凭证模板配置都是对于单张单据明细行的取值设置，模板设置较为简单。

4、 分摊单可独立设置业务流程，按条件进行业务判断。

缺点为：

1、 涉及分摊业务时，核算单据和核算凭证都会增加，业务量增大，带来工作量的增加。

2、 分摊的单据需要单独审核，工作流配置工作量会增加。

3、 两张单据两笔凭证可能存在期间跨越，需注意账务核销和勾稽。

4、 数据还原（分摊明细追溯成本来源）涉及跨单据，审计时会更加复杂。

需求场景三

分摊结果需单独体现过程，仅需生成分摊结果凭证——采取表外分摊且控制关联单据不能生成凭证（获取上游单据信息且凭证生成防重）。

（1）分摊过程

在该场景下，就要考虑进行判断，区分业务，在不同的单据生成凭证。分摊时直接计入成本，只生成一张凭证；于此，配置时需考虑配置关联单据，关联单据不制证。

图6 关联单据生成凭证

（2）配置要点

关联单据，其目的是为了实现组合单据生成凭证。

1）关联单据的配置：将需要生成凭证的单据视为主单，另一张则为关联单据。

图7 关联单据配置位置

主单的判断可以将业务线梳理处理，位于业务后端的即是主单。比如分摊的场景下，是先进行费用的报销，然后分摊的，那么费用分摊单即主单，上游的报销单即是关联单据。

2）分录所属的配置：添加关联单据后，可选择凭证分录的分录所属，也即单条分录的数据源。这里使得在该凭证上，可以生成来源为关联单据的分录。

图8 关联单据数据源

注意：

• 关联关系是来源于Botp的上下游关系，分摊的本质是单据的转换；

图9 关联关系来源

• 分录无法跨单据取值，选定来源即界定了数据源。

图10 取值数据源

关联单据即可配置实现，当分摊单存在关联单据费用报销单时，关联费用报销单不生成凭证。当分摊单已经进行了成本费用的归集，上游报销单自然就无需重复制证核算成本了。勾选该项后，则主单生成凭证后，关联单据无需生成凭证。对于不涉及分摊的费用报销业务，则正常通过费用报销单生成凭证即可。

图11 无需生成凭证配置

（3）优缺点

该方案优点在于：

1、 凭证量相较方案二较少，财务核算工作量没有增加。

2、 业务过程相较方案一体现的更加清晰，同时凭证的取值也是来源于独立单据明细数据，不容易产生数值错误。

3、 财务凭证不存在期间跨越，不会产生核销勾稽的问题。

缺点为：

1、 凭证模板配置有条件，模板方案设置前需经过更细致的业务验证，防止疏漏。

2、 做不到每张单据都生成凭证，不再可按照是否生成凭证进行单据的核算统计，期末结账时模块结账的校验也需同步验证。

3、 审批没有减少，工作流设置增加的工作量仍然存在。

四、分摊凭证模板配置

注意：这里不再具体描述凭证模板的基础配置，关于基础配置模板的配置方式，可参考：实践案例 | 凭证模板配置—基本费用核算的凭证模板配置 

对于凭证模板，最终核算分摊的业务场景，依赖于客户实际需求，往往拆分为三种：

1、直接分摊：在计入成本时，直接将分摊结果计入明细科目及核算维度中；

2、 体现步骤的归集后分摊（分摊结转过程需统计发生额）：先将成本统一计入某个科目或某个维度下，最后将分摊结果计入所需科目及明细维度，需完全按照业务体现分摊步骤，统计科目发生；

说明：常见半研半产企业将项目研发成本结转生产/制造/管理费用内的场景。

3、 不计发生的归集后分摊（分摊结转过程不统计发生额）：先将成本统一计入某个科目或某个维度下，最后将分摊结果计入所需科目及明细维度，需体现分摊步骤，但不统计中转科目发生额。

说明：常见生产/金融企业将生产成本/管理费用下某中转科目结转至多个生产成本/管理费用下明细科目内的场景。

与上述需求对应，其结果体现在凭证上，分录各有不同：

说明：

正负数结转和借贷结转的区别：凭证正负数结转是不会统计发生额的，也即该科目和上级科目本期发生不会增加。从结果上，正负数结转在科目余额表上查询不到发生额，借贷结转则会同步增加转入/转出科目的借贷方发生额，科目余额表也会正常查询到发生额的统计值。

图12 账表展示负数抵消结果

五、方案的可推广价值

1、行业普适性

本案例广泛适用于企业的费用、差旅、资产折旧等业务的凭证模板配置及核算。可实现企业不同环节，不同要求，不同场景的成本分摊功能。

2、对客户价值

该案例可实现客户对于成本分摊核算的多样性需求，无论是对过程的展示，统计，独立核算；亦或在控制凭证数量的前提下，业务实现分步式的分摊。多样化的分摊方案结合多种核算方式，综合实现减少财务工作的同时，满足业务端的追溯，查询，审批需求。

附：案例评论有奖活动

我们将每月挑选优质案例评论发放精美奖品，以下形式的评论中奖概率更高哟：

1、分享案例给您带来的启发：这个案例为您当前、进行中或即将开展的项目带来了哪些启发？若您成功将案例中的策略或方法应用到实际项目中，可在评论区分享您的具体应用情况，我们将为您准备额外的奖励。

2、提出案例优化的建议：您认为案例在哪些方面还有改进的空间？您有哪些更好的替代方案或建议？

期待您的案例留言，您的反馈是我们前进的动力~