个方面带你了解财税管理模块如何设计

　　很多产品汪肯定经历过财务板块的设计，常见的财务板块应该有哪些功能，内容，并让公司财神爷对连连称赞？本期LOG将从基本概念，业务逻辑与关系两方面带你掌握财务板块的业务内容与产品设计。
　　基本概念
　　财务管理板块的存在是让整条业务线的资产投入与产出更明确，让CFO一线掌握某业务线的运转情况以做未来的业务线财务规划；
　　几乎市面所有产品都会存在资金流一说，除非这款产品是纯工具且不具有资金流板块，功能或线下实现资金流的；
　　出色的财务管理功能应具备源头可查，去向可查，税务可查，业务可查；
　　如产品或归属公司不具备金融资质或相关拍照的，原则上同一用户账号（体系）不能进行即充值又提现业务；
　　产品如涉及与用户签订相关协议（比如，劳务，共享，偶然），则用户在进行相关提现操作时应遵循相关法律法规，并进行税务代扣代缴；
　　基于第5条，如公司财务对这块明确了不用代扣代缴的，请务必问清楚原因，否则将会把公司往违法的路子带，且产品设计者本身也难脱干系。
　　业务逻辑与关系
　　按目前我们常见的产品种类来划分，并对这些种类中涉及与财务板块相关的内容做下解析。
　　1。直营电商类
　　这里就不拿B2B2C的电商业务来讲了，我用图来表述直营的商品，订单及资金关系。这里拿相对通用的来讲，涉及到运营板块（比如：优惠券抵扣逻辑，虚拟活动比抵扣获利，团购逻辑，拼单逻辑等及注册的功能就先不讲了。
　　用户创建订单并未支付时，这类订单可单独划入一张数据表中存储与其他订单状态的数据表分开，这么做可以避免恶意下单导致的数据库崩溃。用户完成支付后，行程订单流与资金流，这里的资金严格意义上其实还不归平台所有（跟财务确认下），属于待入账的资金流，在财务管理系统中需要做下区分。
　　平台发货后对应的资金流毅然是未入账，当且仅当用户确认收货后的n天后，资金归平台所有（已入账）。
　　那，这里的规则是基于电商规则来的，在发货途中用户有可能发起退款，所以这里的资金不建议做成已入账。
　　像这类直营电商类的产品，相对在资金流及财务板块的延展性是比较简单的，只涉及到了交易流，并未涉及到用户的提现流（充值流是会存在的，用户支付订单可以看做是一种充值流）
　　在订单信息中，明确用户信息（id，手机号等），支付信息（接第三方的拿第三方返回的订单信息就好），商品信息及物流信息，如有活动的单独归类并与支付信息关联。
　　如平台做推荐功能的，可基于用户所有订单的关键字，结合平台营销策略去做商品推荐，以促成更多的订单转化。
　　2。社交类（含提现，税费）
　　社交类产品多含虚拟货币，用户购买货币并用于平台用户之间的相互流转（注意，购买虚拟货币在ios上与安卓是有明显区分的，且虚拟货币在提现时不得1：1提，做产品设计时建议咨询公司法务），涉及到了冲转提三个流：
　　用户充值：视为用户购买平台的商品，原则上平台需向用户开具对应金额的发票；
　　用户流转：即将已购买的商品赠送给别的用户（比如主播），一般这种赠送类的业务模型，属于偶然所得，被赠送的用户在进行提现时需按提现金额的20缴纳税费或平台代扣代缴；
　　用户提现：从合规的角度来讲，用户在提现时需与平台签订相关协议，协议类型的不同，用户提现时所需扣除的费用也不同。
　　上述3点都是站在合规的角度来分享的，如业务涉及到相对敏感的内容，务必与业务部门做好沟通，并在设计时去规避这些问题。
　　在财务管理用户提现板块，常见的信息需包含，用户的认证信息，银行卡支付宝信息，相关时间信息。注意，按一般公司的财务要求，用户提现的账号需与用户信息一致，如允许用户提现到不同账号的，注意规避相关资金安全风险并明确告知用户。
　　额外BiBi
　　财税模块比较敏感，线上环境的使用权限尽量仅向财税部门开放，如涉及用户咨询的，不想打扰到财务的，可通过用户管理与财税管理数据对接的方式来实现查询，比如用户信息用可将用户钱包的详细变更数据加入，在订单管理中将资金信息加入等等方法。
　　公司财务相对薄弱的（一般不太可能），或对互联网接受程度很低的，以磨合为先，切记不要强压财务去符合你的要求。
　　最后一句财税是一家公司的命脉，及其敏感，并且与多个业务流并存，所以只要涉及到资金流相关的业务，在需求收集与分析阶段，务必将财务与需求部门拉到一起。