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