实践案例 | 零售业利润中心核算体系及账表的搭建方案

栏目：云星瀚知识作者：金蝶来源：金蝶云社区发布：2024-09-22浏览：8

小编推荐

许多大型零售集团由于拥有许多线下门店，若想要精准分析每个门店的经营情况时会面临核算耗时长、数据不精准、计算成本较大等问题，那么如何提升财务核算的质量与速度呢？

别着急，本期文章为大家带来零售业利润中心核算体系及账表的搭建案例，通过实行金蝶云·星瀚的总账与合并报表应用，细化核算颗粒度、精简核算步骤、提升企业管理效率。

撰稿人：金蝶-程娟

一、业务背景

某医药零售集团下属40多家分子公司，拥有9000+家实体零售门店，主要业务包括：医药及器械的零售连锁经营、医药及器械的批发经营、电商平台经营、中药及健康食品生产、医院及大健康相关产业，并配套了大型的物流仓储业务。

零售门店是非法人实体，但是从管理的精细度上，子公司管理层需要根据门店的经营情况进行考核、评优，尤其关注净利润指标。

客户按公司进行法人核算和报表出具，同时需要按照门店这个利润（成本）中心的维度出具内部管理报表。

二、解决方案

考虑到客户的管理报表需求仅是将核算的颗粒度细化到门店层级，如果采用多核算体系启用多账簿会增加核算成本，故我们出具的方案是增加门店这个核算维度。

2.1核算体系设置

1、核算组织按照公司级别进行设置，门店核算采用在会计科目上新增成本中心核算维度实现，不需要门店单独记账。

上传图片

图1 按法人公司搭建的核算主体视图

上传图片

图2 会计科目列表（核算维度包含成本中心）

2、将门店资料维护至成本中心基础资料中，通过成本中心对应核算组织做隔离区分，避免用户在不同组织的手工凭证和机制凭证中选择了非当前核算组织的成本中心，影响核算的准确性。

手工凭证在核算维度值范围中进行设置：

上传图片

图3核算维度值范围设置

机制凭证在提交按钮的操作插件上进行二次开发增加校验：

上传图片

图4 机制凭证的核算维度提交校验

上传图片

图5 机制凭证提交按钮的插件编辑

2.2账表出具方案

客户目前购买并使用的业务系统有星瀚的采购、销售、库存系统和第三方的HR、OA系统等，财务系统包括星瀚的费用、应收、应付、存货、固定资产、出纳、总账、报表等。如下图所示：

上传图片

图6 客户信息系统应用情况

经过初步评估，有两个方案可以满足客户同时出具法人报表和管理报表的诉求。方案一是将总账的凭证数据和账表数据集成到第三方模型数据库中，从数据库出具门店报表；方案二是在合并报表模块出具门店报表。两个方案的详情比较如下：

方案一：凭证与账表数据集成到第三方模型数据库

通过集成平台接口将凭证和余额表的数据下发到第三方模型数据库中，基于该数据库出具门店资产负债表和损益表。财务在结账期间需要查看各类报表、核对数据，故该时间段查看各类报表频率较高，我们根据客户需求制定了下发策略，并支持根据实际情况手动增加下发频次。具体实现步骤如下：

1、会计科目在集团范围内做了级次的梳理和核算维度的新增，总账和第三方模型数据库同步维护新旧科目对照；

2、凭证接口中配置集成的单据以及涉及的字段；

上传图片

图7 凭证集成配置

3、制定凭证数据下发策略：按照【过账日期】字段每天增量下发；

编码	标题	数据类型	数据模型	主键
id	分录id	long		true
seq	分录行号	integer		false
debitori	原币借方	decimal		false
localrate	汇率	decimal		false
debitlocal	借方	decimal		false
creditlocal	贷方	decimal		false
price	单价	decimal		false
creditori	原币贷方	decimal		false
edescription	摘要	string		false
entrydc	分录方向	ENUM	63842F0F	false
currency	币别	REF	bd_currency	false
measureunit	计量单位	REF	bd_measureunits	false
quantity	数量	decimal		false
assgrp	核算维度	REF?(002)		false
maincfitem	主表项目	REF	gl_cashflowitem	false
suppcfitem	补充资料	REF	gl_cashflowitem	false
maincfamount	主表项目金额	decimal		false
suppcfamount	补充资料金额	decimal		false
maincfassgrp	主表核算维度	REF?(002)		false
account	科目	REF	bd_accountview	false
expiredate	到期日	datetime		false
businessnum	业务编号	string		false
isdap	是否dap生成	boolean		false
biznumrecord	业务编号核销记录	long		false
eorg	eorg	long		false
eperiod	eperiod	long		false

表1 凭证下发第三方模型数据库的字段列表

4、余额表接口中配置集成的单据以及涉及的字段；

上传图片

图8 余额表集成配置

5、制定余额表数据下发策略：每天全量下发当前期间数据；

编码	标题	数据类型	数据模型	主键
id	ID	long		true
org	核算组织	REF	bos_org	false
booktype	账簿类型	REF	bd_accountbookstype	false
period	期间	REF	bd_period	false
endperiod	结束期间	REF	bd_period	false
accounttable	科目表	REF	bd_accounttable	false
account	科目	REF	bd_accountview	false
assgrp	核算项目	REF?(002)		false
currency	币别	REF	bd_currency	false
measureunit	计量单位	REF	bd_measureunits	false
beginfor	原币期初余额	decimal		false
debitfor	原币借方	decimal		false
creditfor	原币贷方	decimal		false
endfor	原币期末余额	decimal		false
beginlocal	本位币期初余额	decimal		false
debitlocal	本位币借方	decimal		false
creditlocal	本位币贷方	decimal		false
endlocal	本位币期末余额	decimal		false
yeardebitfor	本年累计借方原币	decimal		false
yeardebitlocal	本年累计借方本位币	decimal		false
yearcreditfor	本年累计贷方原币	decimal		false
yearcreditlocal	本年累计贷方本位币	decimal		false
beginqty	期初数量	decimal		false
debitqty	借方数量	decimal		false
creditqty	贷方数量	decimal		false
endqty	期末数量	decimal		false
yeardebitqty	本年累计借方数量	decimal		false
yearcreditqty	本年累计贷方数量	decimal		false
count	凭证分录数	integer		false

表2 余额表下发第三方模型数据库的字段列表

方案二：在合并报表模块出具门店三大报表

1、在维度中新增成本中心并按照所属组织设置层级关系；

上传图片

图9 合并报表成本中心维度设置

上传图片

图10 合并报表成本中心所属组织层级设置

2、在报表模板中进行行列维设置；

上传图片

图11 合并报表报表模板行列维设置

3、配置门店报表模板时将成本中心增加至页面维中，实现切换页面维度来查找各个门店的资产负债表和损益表；

上传图片

图12 成本中心（门店）增加至页面维

上传图片

图13 门店管理报表样表

因门店报表批量取数，数据量过大（凭证数据条数在千万以上/每月），耗时较长，经过综合权衡比较，最终客户选择在星瀚•合并报表出具法定报表和部分管理报表（涉及主表8个，明细表11个），部分管理报表通过接口的方式在第三方模型数据库中出具。

三、方案的可推广价值

该方案适用于所有零售行业，在此方案下，客户实现了：

提升企业管理效率：通过按公司设置核算组织、门店作为核算维度，对有精细化核算需求的零售型企业，提升了财务核算数据质量。
精简门店人员操作：在该核算模式下，统一由各公司财务人员处理凭证，简化了门店业务人员的核算，提升了财务核算工作效率。
门店账表查询灵活：门店不作为单个核算组织情况下，也能达到单独核算的要求。由于在每个会计科目配置了核算维度，不仅在总账账表分析中可以查询门店各项损益数据，也可以在合并报表模块按照门店搭建个性化报表进行管理分析。

附：案例评论有奖活动

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

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

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

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