| Contact Us | CHT | Mobile | Wechat | Weibo | Search:
Welcome Visitors | 登录 | 免费注册 | 忘记了密码 | 社交账号注册或登录

Home

温哥华资讯

Realty

Education

Finance

Immigrants

Yellow Page

Travel

报损率超50%,那些没卖完的面包去哪了?(图)

QR Code
请用微信 扫一扫 扫描上面的二维码,然后点击页面右上角的 ... 图标,然后点击 发送给朋友分享到朋友圈,谢谢!
“每天现做、只售当日。”追求极致新鲜,成为越来越多烘焙商家招揽顾客的招牌。


中研网数据显示,2021年中国包装烘焙产品收入规模合计450亿元,其中短保烘焙(保质期较短的烘焙食品)市场规模达到200亿元,占比近50%。现制短保面包成为烘焙行业的宠儿。

保质期缩短,意味着食物添加剂剂量降低,口感更为新鲜,与此同时,更高的食品报损率也随之显现。业内人士指出,“ 现制烘焙产品的保质期一般在1至3天,生命线最短的只有4小时,超过24小时就有过期风险。”近日新华社报道称,已有面包店报损率超50%。每天深夜,没卖完的面包被扔掉的情况,同时发生在便利店、超市以及烘焙店,大量的食物因此浪费。


高报损面包从何而来?

下午6点左右,北京市丰台区一家传统面包店还有现烤新品端出、上架,展柜里满满当当,正是客流高峰期,店员热情地向客人推销着面包。

“我们是做社区生意,很多品类都会打折,就是为了减少积压,但畅销品和现烤品一般不参与活动。” 店主告诉《中国新闻周刊》。即便如此,在临期商品区堆满了特价面包,它们当中最快的将在当天晚上12点之后过保质期,如果最终没被卖出去,就只能被当成垃圾扔掉。

“这些多出的面包不能让员工带回家吃,或者送给周围需要的人吗?”



橱窗里摆满刚出炉的面包。摄影/吴利婷

店主的答案是:现在基本不这样做。按照面包店的规定,不允许面包私下流出。在业内看来,5%至10%之间的报损率被认为是正常的,低于区间则从侧面说明可能生产量不够。


“湿垃圾处理是按重量计费,比起找专业机构量化更合理的库存、进货、销售方案,出于成本考量,打包扔掉反而成了更优选择。”店主告诉《中国新闻周刊》。

一边不停生产,一边不断扔掉,对此,国务院发展研究中心市场经济研究所副研究员刘馨分析称,为提高消费者的购买欲望,一些商家盲目追求货架“满”,选择生产充足甚至过量的面包,在保质期内未完全售出,就造成了较高的报损率。为了弥补高报损率带来的成本增加,面包店会提升单个商品的价格以保证盈利。

“最终羊毛出在了羊身上。”刘馨说,商家选择将余量面包直接丢弃,还可能是避免长期规律性的打折销售导致一些消费者只购买优惠价格面包,影响日常经营,造成亏损。


剩余面包如何处理?

面包店产量与销售量不能完全一致,出现余量食物十分常见。为了解决剩余面包这个由来已久的问题,《中国新闻周刊》采访发现,不同商家的处置方式各不相同。

烘焙网店经营者杨立轩表示,“我们的烘焙品以预订为主,按需定制,几乎不会有多余的产出。”

而在一些规模型的品牌连锁店,没卖完的现烤面包将送回总厂统一回收销毁或再利用。有的会跟养殖场合作制作成饲料、有的用于堆肥;也有不少商家在营销策略上推陈出新,采用年轻人喜欢的“面包盲盒”进行促销。

“充分利用流通中产生的剩余面包,实现食物的梯次利用,可以有效减少食品浪费。”刘馨介绍说,这些都是为了物尽其用。但食物最好的归宿就是完成使命,被人们吃掉。

事实上,国外半个多世纪以前,一种名为“食物银行”的社会企业或慈善组织开始出现,与当地的食品生产商、超市和社区组织合作,收集、储存未售出或临期的食品,然后免费分发给有需要的人。
觉得新闻不错,请点个赞吧     这条新闻还没有人评论喔,等着您的高见呢
Prev Page12Next Page
Note:
  • 新闻来源于其它媒体,内容不代表本站立场!
  • _VIEW_NEWS_FULL
    _RELATED_NEWS:
    _RELATED_NEWS_MORE:
    _POSTMYCOMMENT:
    Comment:
    Security Code:
    Please input the number which is shown on the following picture
    The Captcha image
    Terms & Conditions    Privacy Policy    Political ADs    Activities Agreement    Contact Us    Sitemap    

    加西网为北美中文网传媒集团旗下网站

    Page Generation: 0.0331 Seconds and 4 DB Queries in 0.0047 Seconds