Skip to content
最佳实践

最佳实践

如果您正在设置 BigLedger,或者接手了别人设置好的租户,本页就是一份简短的习惯清单:它区分开一套能平衡的账簿,和一套到月底要花三天才能理清的账簿。一共五条。读完大约十分钟;照着做需要一个下午,省下的时间远不止于此。

这不是一份通用的管理建议清单。这里的每一条都是 BigLedger 特有的行为,每一条我们都亲眼见过出错。

认识 GadgetSphere

GadgetSphere Sdn Bhd 是一家马来西亚消费电子集团:22 家零售分店、一个网上业务和一家分销公司,约 5,200 个在售 SKU 和 28 个现金簿(cashbook)。下面的例子使用它的数字。您的企业可能规模更小,但每一条依然适用。

习惯一:弄清哪张单据才是算数的那一张

这是本页最有价值的一点,几乎每个人都会感到意外。

在销售端,只有两种单据会移动库存并过账到您的账簿:Sales Invoice(销售发票)和 POS Cash Bill(现金单)。 报价单、销售订单、送货单(goods delivery note)和出库送货单(outbound delivery order)都只记录意向。它们值得录入——它们彼此冲销(close off),驱动拣货,给客户提供单据——但在发票或现金单最终确认(finalise)之前,您账上的数字和**库存结余(stock balance)**中的数量都不会变动。

注意结余与可用的区别:未完成的销售订单确实会减少 BigLedger 显示给您的**可用(available)**数量,这样仓库就不会把同一件货承诺两次。它只是不会把货从库存中扣除。

所以,当 GS-KV-01 分店的经理告诉您,今早有 40 部旗舰智能手机凭 40 张销售订单出了店,而库存报表仍显示现存 40 部时,并没有出故障。只是还没有人开发票。

在采购端则正好相反。 标准的 Goods Received Note(收货单,GRN)记录点收数量并冲减采购订单,但不会增加您的库存结余;增加库存的是采购发票。(还有另一对单据——Purchase GRN Stock In / Purchase Invoice No Stock In——在收货时就入库,您的公司可能就是按这一对设置的。无论您用的是哪一对,都只能用其中一对,绝不能两对各取一张。)

该怎么做: 为您的每一条工作流程写下哪张单据是过账单据——并告诉每一个看库存报表的人。然后,永远不要根据订单量来规划库存。

会怎样出错: 有人用销售订单去核对库存,发现各分店合计相差 400 件,然后花一周时间追查盗窃,而实际上只是已送货却未开发票。

→ 标准销售流程 · 收货单处理 · 采购发票处理

习惯二:在任何人录入交易之前设好默认 GL 代码

Chart of Account applet > Company Default GL Codes

BigLedger 根据公司的默认 GL 代码(总账科目代码)来生成一张单据的日记账——销售记借哪个科目、销项税记哪个科目、应收账款科目,等等。它是在最终确认之后运行的过账中查找这些代码的,不是在您创建单据时,也不是 FINAL 本身的一部分。

所以缺少映射永远不会阻止 FINAL。单据会变成 FINAL,背后发生两种情况之一。当应收或应付科目缺失(或者公司根本没有默认 GL 代码)时,过账以 MISSING_DEFAULT_GL_CODE 或 COMPANY_DEFAULT_GL_CODE_NOT_EXIST 失败,并指明它找不到什么;单据停在 FINAL,没有日记账——它的 Posting 选项卡不显示日记账状态,也没有人收到通知。当销售、采购或税务科目缺失时,什么都不会失败:那一行被略过,由客户或供应商那一行吸收,于是账簿悄悄地少了一块。月底最后一天下午 5 点的销售员什么也看不到;您要到月结时才发现。

该怎么做: 在上线之前,为集团内每一家公司完成默认 GL 代码映射。GadgetSphere 有三家——GS、GSO 和 GSD——每一家都需要自己的一套。然后为您实际使用的每一种单据类型各录入一张测试单据并最终确认。

会怎样出错: 只为主营运公司做了映射。分销公司的发票连续三周变成 FINAL,背后却没有日记账,第一个发现问题的信号是应收账款分类账与账龄报表对不上。

→ 会计科目表设置 · Chart of Account applet

习惯三:把信用控制当作定时任务,因为它本来就是

BigLedger 不会在您录入时计算客户的风险敞口。没有一个累计数会在保存时因为将超出额度而拦下一张销售订单。

实际发生的是一个名为 Blacklist Overdue Customer 的后台任务。它运行时会汇总每个客户的未结单据,与其信用额度比较,检查是否有逾期的信用条款,并把不合格的客户标记为黑名单。另外,当有人为一个已经带有该标记的客户保存 Cash Bill、Sales Invoice、Sales Order 或 Outbound Delivery Order 时,BigLedger 会以 “Customer is blacklisted due to credit limit. Transactions are not allowed for this customer.” 拒绝。

由此产生以下几点后果,每一点都很重要:

  • 拦截的时效只取决于该任务最近一次运行。 如果它昨晚运行过,而某客户今早已超出额度,今天的订单照样通过。
  • 这四种单据类型以外的任何单据都完全不受拦截。 为黑名单客户开的报价单、送货单或贷项通知单(credit note)照常保存。
  • 录入订单时没有任何界面显示剩余信用额度,唯一的额度检查是可选的。 在 Sales Order 或 Sales Invoice 的设置中打开信用检查后,一旦客户在该公司的信用额度用完,FINAL 就会被拒绝。关闭时,没有任何东西会因为超出额度而拒绝一张单据。
  • 该任务在重新计算之前会清除所有现有的黑名单标记。 因此,对一个您已决定不再往来的客户手动设置的黑名单,过不了下一次运行。

该怎么做: 为该任务设定排程,清楚它的排程;如果需要永久停止与某客户的交易,不要用黑名单标记——信用额度设为零能在重新计算后保留,手动设置的标记则不能。

会怎样出错: 财务经理在星期五把一个有争议的账户列入黑名单,任务在周末运行,星期一这个账户又能交易了。

习惯四:不要指望第二级审批来拦住任何东西

如果您为采购订单、采购申请单或库存申请单设置了单据审批,在设计规则之前有一个行为必须知道:单据在第一位审批人批准时就被设为 FINAL,而不是最后一位。

审批记录本身的行为是正确的——第 2 级仍会创建,审批人仍会收到电子邮件,在他们处理之前审批不会标记为完成。但采购订单已经变成 FINAL,可以据此执行了。如果您设第二级是为了在董事看过之前拦住一张大额订单,它拦不住。

该怎么做: 用审批级别来记录签核,而不是用来强制搁置。真正需要搁置时,把金额控制在允许录入该单据的门槛以下,或者把录入权限留给应当做决定的人。

会怎样出错: 为 RM 50,000 以上的订单建了两级规则,所有人都以为董事是关卡,结果供应商按一张董事从未见过的 FINAL 订单发了货。

→ 单据审批

习惯五:始终把前一张单据拉进来——绝不重新录入

BigLedger 的每一条工作流程都有办法把前一张单据带入后一张:草稿上的 Search Document、新单据上的 KO For 选项卡,或 Import 选项卡。每次都要用它,即使单据只有两行、手打看起来更快。

它建立的关联正是冲销前一张单据的依据。没有它:

  • 采购订单永远保持未结,您的未完成订单报表成了虚构;
  • 应付账款没有东西可以用来核对供应商的账单,数量争议只能靠纸质单据解决;
  • 数量会出现偏差,因为重新录入的一行是凭记忆打出来的。

该怎么做: 把“搜索,不要手打”作为教给新用户的第一件事,并每月抽查未结采购订单清单,找出几个月前已收货却从未冲销的订单。

成功是什么样子

三十秒,今天就能做:

  1. 把库存报表和销售订单清单并排打开。如果有人能用一句话解释两者的差异——“那些是已下单,未开发票”——习惯一就落实了。
  2. 在 Chart of Account applet 中,为集团内每家公司打开 Company Default GL Codes。您用到的每一行都填有代码,没有空白。
  3. 打开未结采购订单清单,按日期排序。其中没有一张比您最长的正常交货期还要旧。

如果三条都成立,本页所说的问题就不会找上您。

常见错误

发生了什么看起来是什么样解决办法
用销售订单核对库存一个持续存在、无法解释、在各分店之间游移的短缺用销售发票和现金单核对——只有这两种销售单据会移动库存
只为一家公司设置了默认 GL 代码上线几周后,第二家公司的第一张单据出现 MISSING_DEFAULT_GL_CODE按公司分别映射默认代码,然后在每家公司为每种单据类型各最终确认一张测试单据
以为信用额度会在保存时拦截一个远超额度的客户仍在不断下单查看 Blacklist Overdue Customer 任务最近一次是什么时候运行的;拦截读取的标记正是它设置的
把手动黑名单当作永久停止任务下一次运行后,该客户又能交易了直接设置信用额度;任务会重新计算标记,但不会改写额度
把第二级审批当作搁置一张没有高层批准过的 FINAL 采购订单把审批级别当作签核记录;用权限来强制搁置
重新录入单据而不是搜索带入永远不会冲销的采购订单;与收货不符的发票数量每次都用 Search Document / KO For / Import

相关文档

Last updated on