Rss & SiteMap

昂捷论坛 http://www.enjoyit.com.cn

中国零售业界精英论坛!
共2 条记录, 每页显示 15 条, 页签: [1]
[浏览完整版]

标题:问:生鲜加工部门的损耗率是怎样计算的?

1楼
飞絮 发表于:2007/1/21 4:19:56

答:商品的损耗率也被称为报损率、损溢率、灭失率等,在介绍生鲜加工部门的损耗率计算方法之前,我们要统一一下损耗的定义。

虽然“损耗”一词在超市和生鲜经营业内被频繁使用,但却理解各异:超市经营者把损耗理解为失窃损失、商品破损等;在生鲜经营中则将损耗界定为生鲜产品的丢弃物或废品。对于损耗的不同理解及描述或偏或全,由此也引出了各种不同的管理措施和控制方法,而损耗管理和控制的效果也会迥然不同。

美国食品营销协会《超市防盗手册》对超市的损耗有如下定义:损耗是收货时的商品零售值与售出后获取的零售值之间的差额。这样看来,损耗应该是由于盗窃、损坏及其它因素共同引起的。这个定义比较着重于损耗在价值上的综合体现。

按照这个定义,业界比较统一的损耗率计算方法是:

损耗率=本期损耗售价金额 / 本期销售售价金额

=(期初售价金额+本期所有形式进货售价金额-本期销售售价金额-期末实际盘点售价金额)/ 本期销售售价金额

当然,许多用户也会不含税售价、含税进价、不含税进价等金额来计算损耗率,只要分子分母使用同一口径,都可以认为是可以接受的。但因为用进价金额受进价频繁变化的影响比较大,因此得出来的损耗率可能和售价相差较大。

而对于生鲜加工部门,因为生鲜加工过程本身就是一个商品零售价值增长的过程,因此仍然采用这种算法是不适合的。举一个简单的例子:一个部门期初为0,在本期只是将零售价值为7元的原材料进货后加工为零售价值为10元的成品并卖出,按以上算法损耗率为-30%,显然是不合理的,因为实际上以上过程是没有任何损耗的。

可见对于生鲜加工部门,以上公式应修正为:

损耗率=本期损耗售价金额 / 本期销售售价金额=

(期初售价金额+本期所有形式进货售价金额+加工过程售价增值金额-本期销售售价金额-期末实际盘点售价金额)/ 本期销售售价金额

而加工过程售价增值金额只有在采用精细的加工管理时才能够得到(关于生鲜加工部门的管理方法,请见http://www.enjoyit.com.cn/bbs/dispbbs.asp?boardid=29&ID=2587&replyID=12192),遗憾的是,现在大部分超市采用的是粗放的以盘点倒计成本的方式。

在粗放管理的情况下,损耗和加工过程的增值是混在一起的,因此不可能准确求取损耗率。

也许您说可以考虑采用进价的方式来求取损耗率,是否就不受加工过程售价增值金额的影响的,即:

损耗率=本期损耗含税进价 / 本期销售含税进价

=(期初含税进价+本期所有形式进货含税进价-本期销售含税进价-期末实际盘点含税进价)/ 本期销售含税进价

但应该明确如果采用的是粗放的管理方法,此处成品的本期销售含税进价是预设的计划成本价格,是人工设定的,设高或者设低对损耗率有着直接的影响(但并不影响最终核算的综合成本,请见http://www.enjoyit.com.cn/bbs/dispbbs.asp?boardid=29&id=2589),即这样计算出来的损耗不仅仅包含真正的损耗,还包含预设计划成本相对于真实成本的差额(注意另外还包含从其他部门领用而预先转出的领用成本,预先转出的领用成本实际相当于先期做的报损,即调入进到本加工部门,则立即报损掉,而不必等到月末盘点,因此若不考虑预设计划成本相对于真实成本的差额,本月的报损金额应该等于系统中体现得报损金额+本月的领用金额)。

再举个上面那个简单的例子:该部门的原材料进价为5元,若预设其成品成本价格为4元,则得到的损耗率为25%,若设置成品成本价格为6元,则得到的损耗率为-16.7%,但实际上这两个数值都是不对的,以上过程是没有任何损耗的,反映出来的仅仅是成品的预设计划成本相对于真实成本5元的偏差而已。

如何在采用粗放的管理方法下计算相对准确的生鲜加工部门损耗率是当前仍然值得探讨的一个问题,各个商业企业的做法也不尽相同,我认为其中一种简单算法倒是值得推荐,即

损耗率=部门标准毛利率 - 本期综合毛利率

因为虽然是粗放式的管理,但每期盘点后倒计的方法可以获得准确的部门综合毛利,与部门的标准毛利比较即可以估计本期的大概损失率,而困难之处在于如何确定各个部门的标准毛利率。

[此贴子已经被作者于2007-1-21 13:13:40编辑过]
共2 条记录, 每页显示 15 条, 页签: [1]

Copyright © 2006-2010 EnjoyIT.com.cn
网友言论或观点与昂捷公司无关!涉及版权/著作权问题请与发帖者直接联系
Powered By Dvbbs Version 8.2.0
Processed in 0.16406 s, 2 queries.