静待水到渠成

网贷记账应用“库牛”设计全过程之三——对象分析

网贷记账所涉及的四大对象

网贷投资记账过程中,共有四种对象,从小到大分别为交易、项目、平台、总账户。

交易,有交易日期,交易类型,交易金额,交易平台,备注等基础特性。
其中,交易类型根据资金流可以得出,详细地列举的话,有以下16种:充值,提现,投标,回款,逾期,坏账,转让债权,购买债权,站岗资金坏账,平台奖励,提现手续费,充值手续费,利息管理费,转让折让金,转让服务费,VIP费用等等。
但这16种交易类型并非彼此独立,有些甚至是并生并存的,比如充值与充值手续费,提现与提现手续费等等。
另外,不同的交易类型,还会在交易的基础属性下有其他的属性。(想到了父类和子类的关系了╮(╯▽╰)╭)

项目,有项目名称,平台名称,项目利率,项目期限,还款方式,投标时间,项目状态,初始债权,已转出债权,已回款本息,待回款本息,当前持有债权,项目下交易明细等特性。
其中,项目状态根据资金流可以得出,有在投,逾期,坏账,结束四种。

平台,有平台名称,综合年化收益,投资占比,在投本金,待收利息,已获收益,逾期金额,坏账金额,平台下项目明细,平台下交易明细等特性。
其中,平台投资占比=平台在投本金÷该用户在网贷的总在投本金。
平台综合年化收益=收益÷∑(本金X投资天数)X365X100%。
已获收益=结束项目利息总和-各种手续费。

总账户,有总在投本金,总待收利息,累计盈利,平台明细,项目明细,交易明细等特性。
总账户,其实相当于一个平台的平台,比平台属性增加一个平台明细的特性。

很显然,项目是由交易生成的,如果知道了项目相关的投资、回款等交易信息,自然就能得出对应的项目信息。平台和总账户信息也可以由交易信息得出,所以交易是整个应用中最核心的对象。

交易的详细对象分析

接下来,我们详细对交易进行分析,关键是对交易类型这个属性进行分析优化。

首先,我们可以很容易地通过给充值手续费收费标准(元每笔或充值本金百分比的值)而把充值手续费和充值两种交易类型对应起来,从其中任意一个推出另一个,即这两个其实只要保留其中之一即可。同理,提现手续费和提现也是只需保留一个。
另外,利息管理费是与每一笔利息回款绑在一起的,可以在投资或购买债权时添加利息管理费的属性来推出利息管理费。同理,可以在转让债权中添加转让折让金和转让服务费的属性,在购买债券中添加转让折让金的属性。从而我们可以删去利息管理费、转让折让金、转让服务费三个交易类型。
现在还剩下充值/充值手续费,提现/提现手续费,投标,回款,逾期,坏账,转让债权,购买债权,站岗资金坏账,平台奖励,VIP费用共11种交易类型。

再次审视这11种交易类型,继续简化。
投标这个类型是最重要的最必不可少的,购买债券是一种特殊的投标,它与投标可能有部分属性不同,可以考虑把二者合并,将项目和债券作为投标的两种子类型。
充值手续费,提现手续费,VIP 费用可以合并为收费一个交易类型,下设充值费、提现费、VIP费用、其他四个子类型。充值和提现的本金是多少其实只有在站岗资金坏账时才会影响资金流,故而完全可以用充值手续费、提现手续费、站岗资金坏账来代替充值和提现的类型。
平台奖励类似于收费,可以命名为奖励这个交易类型,下设注册红包、邀请好友、分享活动、其他四个子类型。
回款、逾期、坏账和转让债权都是基于某一个投标衍生出来的后续交易。应用可以自动根据一个投标生成相应的回款,让用户处理标识为回款、逾期、坏账。即用户只需要选择一笔回款进行操作即可,这样可以减少用户的操作。同理,用户记录转让债权时也可以先选择一笔投标进行操作。鉴于坏账和站岗资金坏账的区别在于站岗资金坏账可以不用关联回款,故而其实可以把二者合并为坏账,但是允许坏账不关联回款。如此,回款、逾期、坏账、转让债权这四个交易类型,由于可以合并部分流程。

最终,交易类型归并如下:

  1. 投资:分项目和债权共两个子类型。
  2. 收费:分充值费、提现费、VIP会员费、其他共四个子类型。
  3. 奖励:分注册红包、邀请好友、分享活动、其他共四个子类型。(PS:后来发现其实比较常见的还有充值奖励,不过这个好改哈~)
  4. 其他:分回款、逾期、坏账和转让债权共四个子类型。选择具体子类型后需要选择关联的回款或投资,坏账可以不关联直接跳过选择。

继而,根据确定的交易类型,需要分析每个类型下所特有的特性,如下图所示。
其中,对转让债权的类型进行下说明。根据:折让金=折让比例X债券原值,公允价格=折让金+投资金额,应收利息=公允价格-债券原值,上一次付息日=起息日-(应收利息÷日化利率),转让债权并不需要知道折让金、公允价格、原债权期限等数据,因此我们可以减少用户所需要输入的数据。
另外,投资时的续投奖励、投标奖励都是在投资金额上的奖励比例,所以统一为奖励利率一个特性。

图片

注意,上图的特性只是需要用户提供或者允许用户修改的属性。
交易有部分特性和项目、平台、总账户的特性是可以根据这些数据推导出来的,不需要用户提供,并没有列举在图中。

后记

在整个设计过程中,我给各个对象所设计的特性,经历了一个从多到少的过程。
刚开始的时候,需要枚举各个对象的所有可能的特性,以免有所遗漏;然后,需要对每个特性进行分析,哪些特性是用户需要给我们提供的(下面简称为元数据),哪些特性是从元数据可以推导出来的但是可能有变化因此需要允许用户修改的,哪些特性是从元数据推导出来后用户不会修改但需要偶尔查看的,哪些特性是用户不关心的可以删去的……这样把特性进行一定的删减和分类。
这样,就可以让用户只需要输入最少的数据,却能得到他们所需要的所有的数据。

Comments