首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

从SAP最佳业务实践看企业管理(195)-盘点后的盈亏处理

财产清查的方法有实地盘点法、抽样盘点法、估算法、测量计算法、对账单法、查询法。 对清查结果先放入"待处理财产损溢"查明原因后再转出 (一)存货清查结果的账务处理 造成存货账实不符的原因是多种多样的,应根据不同的情况作不同的处理。通常情况下,定额内的盘亏,应增加费用;责任事故造成的损失,应由过失人进行赔偿;非常事故,如自然灾害,在扣除保险公司理赔及残料价值后,经批准应列作营业外支出等。反之,发生盘盈一般则冲减费用。现举例如下: 例1:根据“实存账存对比表”所列盘亏库存商品40000元,编制记账凭证,调整

08
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    从SAP最佳业务实践看企业管理(44)-SD-销售退货账务处理

    退货与销售折让是企业经常性的经营行为,若不正确处理这些业务,将会在会计核算上带来很多不便。 下面谈谈常用的账务处理方法。 1、购买方未付货款并且未作账务处理的 购买方须将原增值税专用发票第二联(发票联)和第三联(税款抵扣联)及产品(商品)销货单主动退还给我方,我方则应视不同情况作下述处理: (1)我方在会计上未入账时,应将所有专用发票联次注明作废,并将发票联和抵扣联粘贴于存根联后面(在ERP系统中一般不会存在这种情况,开票后肯定会入账)。 (2)我方已入账时,开具一张相同金额的红字(负数)发票,将记账联撕下

    04

    从SAP最佳业务实践看企业管理(174)-CO-采购成本核算及差异分析

    存货作为企业的一种资产,在企业资产中占有相当比重,合理选择存货的计价方法对企业的财务状况、经营成果和现金流量会产生不同的影响。这里介绍SAP系统中最典型的两种计价方法:标准成本和移动平均价,来了解其在采购过程中的成本核算及其差异处理。 1、标准成本法 在ERP环境下,对于存货的采购通常包含两个步骤:采购收货和发票校验。当采购收货和发票校验完成后都会在系统中自动生成相应的会计凭证。但自动记帐的科目和金额由于存货计价方法不同和收货与收发票的顺序不同而不同。 在标准成本法下,采购价与计划/标准价之间的价

    08

    从SAP最佳业务实践看企业管理(175)-CO-期末结算

    成本月结大概过程: 回顾一下产品成本组成: 直接材料,指直接用于产品生产的原材料,燃料和动力, 直接人工,指直接参加产品生产的工人工资和福利费; 制造费用(又称间接费用),指间接用于产品生产的各项费用。 日常的处理过程中都按标准成本进行记账,月末实际的成本出来后,那实际和计划一定有差异,成本月结实际就是处理差异的过程。 直接人工和制造费用是通过作业价格*作业数量进行记账,作业价格计划和实际一定会有差异,根据实际的消耗和实际的作业数量,系统可以计算出实际的作业价格,然后根据实际的作业价格对生产订单成本进行重算

    08

    SAP系统销售流程成本和收入的确认

    ERP标准设置是在开票时确认销售收入,而在交货时结转销售成本。系统本身是不保证收入和成本配比的,这主要是因为两者各有支持的原始凭证(发票和出库单)。对于这个问题我们认为:除非是行业特殊性造成的原因,收入和成本的配比,主要应当从流程的角度通过控制开票和交货的时机来解决,比较理想的状态是开票直接指向交货,交货后即时开票或者定期(每天或至少月底)开票。我国的增值税法也要求企业在销售交货之后应当及时开具增值税专用发票。但是,在有些情况下企业由于种种原因无法实现这种流程上的匹配,就需要一些别的功能和手段来实现这种匹配。

    02

    从SAP最佳业务实践看企业管理(177)-CO-物料分类账

    1、为什么使用物料分类帐? 中国会计准则规定:对存货的核算必须采用历史成本法(即实际成本法),如果企业采用计划成本法或者定额成本法进行日常核算的,应当按期结转其成本差异,将计划成本或者定额成本调整为实际成本。而SAP中则可以使用物料分类帐来解决这个问题。 将原材料购置、生产制造加工过程中,产生的各项差异,通过层层上卷并合理分摊,最终核算出产成品的实际成本(即当期的加权平均价),并按实际成本结算至当期销售成本与存货值。 在SAP系统中,我们可以使用标准成本法和移动平均价来核算原材料的成本。如果我们以标准成本

    05

    老焦专栏 | 为什么需要用业务补偿服务和TCC 型服务实现数据一致性

    分布式事务解决的问题很明确,就是在服务分布在不同进程、数据分布在不同数据库时,如何解决数据一致性问题。对于这个问题,业界的共识是不要启用数据库 XA 模式,因为分布式情况下,如果启用了 XA 事务,必然会有数据库锁存在,实际上造成了两个服务之间的耦合,与分布式服务的初衷背离,还不如部署在一起。在不使用 XA 的情况下,经常使用业务补偿和TCC(Try/Confirm/Cancel)模式的服务来解决:为什么有这样两种模式呢,他们有什么区别,各自适合什么样的场景,这两种模式是否带来了代码开发的复杂度?经常有人问我这样的问题,这里简单说明一下:

    03
    领券