本帖最后由 CHINACYN 于 2016-1-24 21:00 编辑 收款及核销业务的开发模式介绍(1) 近日,有几位粉丝在群里交流了有关收款业务的处理模式,这里对此进行一个收集与整理,系统性地把款与核销做一归纳。 收款业务,一般发生在货物销售之后,根据发货金额进行收款,这是比较普遍的。而有的企业则是按开出去的发票进行收款,这二者间的差别在于收款的依据不同。如下图说明: 针对以上业务关系,在软件设计上应该如何进行呢? 1、若按销售发货进行收款,则收款就与销售发货单进行关联,一旦发货单确认(可用状态字段进行标志),则通过业务公式增加客户档案中的发货金额和发货未收金额。这样就是以随时知道每个客户发货未收回的款,只需直接从客户档案中取发货未收的当前金额即可。 在确定了收款按发货业务来执行后,还有一个收款与发货本身的关联关系处理问题。有二种方式,一种是事中处理,另一种是事后处理。 事中处理,即是在收款时关联发货单,只要是没有收款完成的单据全部取过来,然后,在收款时逐一进行匹配,可以通过自动的方式将收到的款项自动分配到不同的单据上。这种方式好处是可以按先后顺序进行未收款监管,特别是进行账期分析与管理比较方便,难点在于预收款的处理。 以上收款是根据企业实际开发的,对于任何一个企业都可以做到简洁、有效。顺便比较下一个软件的收款单,若是你,能忍受吗? 信用控制,可以通过客户档案中的发货未收来进行实时的控制,这与过程中的核销关系不大。 若业务量特别大,那就可以采购事后处理的模式进行,先只管收钱,反正把钱收进行登记好就行,至于这些收款与哪些发货单有关,则可以事后通过软件进行自动化的匹配处理,这样不但效率高,还保证了业务单据与财务收款单间的关联,也能掌握明细,还能便于对账。 事后处理,云表群中唐山佳源冯总他们的做法就很好,如下图: 2、若是用发票来收款,则发货与发票之间要建立一个关联,发货未开票部分作为在途商品记账,而企业对这部分金额与开票金额同样关注,在客户档案上增加有关发票的二个数据项,开票金额和开票未收。 无论是哪种方式,在云表平台上的设计套路都是相似的,上拉与下推这样的业务关联。 有关设计,请关注后续介绍。 欢迎转载,转载请保留原文出处:《收款及核销业务的开发模式介绍》,云表开发者社区 QQ图片20160123223243.png ( 19 KB ) QQ图片20160123221544.png ( 16 KB ) |
+10
3 条回帖
本帖最后由 CHINACYN 于 2016-1-24 21:00 编辑 收款及核销业务的开发模式介绍(2) 上篇介绍了付款的来源可以因企业管理的不同而不同,在这种情况下就需要有不同的设计,为有效地解决平台设计上的灵活性和规范化,一般在业务单据与付款间增加一个档案性的单据,也即应付款单,这也是典型的三表设计法。 请看下图: 增加应收单后,在设计上增加了最左侧的业务单据与应收单间的关联关系,但这样在处理收款单与业务间的关联设计会变得非常稳定,只需要建立与应收单间的关联。同时,又增加了系统响应和满足客户需求上的灵活性,可以做各种不同的业务单据,如发货单就可以按需要设计成多种格式,而不会对后续业务产生影响。这对于持续不断变化和升级的系统设计是至关重要的。 增加应收单据,还有一个益处在于保持数据在多用户并发操作时的准确性。因为应收单据是一个非人为输入的单据,因此,不会有人为的修改,这样就可以准确地接受各种业务公式的更新或删除。 业务源头单据与应收单间就是一种下推业务,在云表平台就是通过业务公式来实现的。这里就是当发货单保存或审核后,由系统自动生成对应的应收单,这就是下推业务。这种应用也是实现软件智能化一种重要的实现手段,如财务业务一体化时就利用业务类型下推直接生成凭证。 那如何在云表平台实现,请关注后续介绍。 |
+10