前言:
现时姐妹们对“php开源c2c”可能比较关心,兄弟们都需要剖析一些“php开源c2c”的相关知识。那么小编同时在网络上汇集了一些有关“php开源c2c””的相关内容,希望看官们能喜欢,咱们快快来了解一下吧!笔者负责的电商平台在具备一定的规模后,开始出现财务手工做账工作负荷太大等问题,因此决定升级成全系统处理,实现全线上的结算流程。本文将与大家分析相关的产品需求、研究过程、最终实现的方案。
01 商城分账与结算
我们是一家社区电商,商品由农场提供,放在平台上销售,主要依托社区团长进行推广销售,模式可以定义为B2C2C:供应商->分销者->终端用户。
当用户在平台上购买了某个农场的蔬菜后,订单将计算物流成本。去掉物流成本后,用户确认收货后,剩余资金将在供应商、分销者、平台三者之间按比例分成,这就是分账的过程。
我们还会按照供应商每月的销量,动态的调整平台手续费的比例,分销者销量越高也能获得更高比例的佣金奖励。
用户支付的费用,我们在渠道上设置为T+1天自动提现到我们公司的对公账户中。系统根据订单计算好分账方的收入后,我们的运营将会审核,然后总经理签字确认后,财务将会按每周两次的频率将各方的收入,以银行转账的形式,将资金从公司对公户转账到对方的银行账户中。完成转账后将在系统中推送一条消息给各方,提示他们到账了。我们将货款支付给供应商,佣金支付给分销者的过程,就叫做结算。
结算:指把某一时期内的所有收支情况进行总结、核算。可以是货款的结算、佣金的结算,可以是平台给商家钱,也可以是商家给平台钱(如返佣)。
02 实现方案
由于我们的结算过程人工干预程度大,人力成本高、速度慢,供应商经常来投诉我们结算不及时,甚至有出错款的情况。所以我们决定采用全线上的结算流程。
to C的电商平台如果需要实现给供应商结算,底层的方案一般有五种:
1. 银行分账
与银行合作,开一个监管户,然后通过银行分账的接口实现分账,比较出名的解决方案有平安银行的见证宝、中信银行的电商管家。
由于支付系统的开发、与银行系统对接比较耗时耗力,所以又有一些公司如Ping++、维金,先对接好了银行、支付宝、微信等,实现了一套支付分账平台,然后专门卖系统,这样让电商平台实现分账又能少了一些琐屑事。
大部分银行其实并不提供非同一主体的公司间分账业务,剩下支持的银行一般要求公司有ICP/EDI证其中一个,对于大陆的电商公司而言,ICP证还是比较容易拿的。
ICP证:Internet Content Provider,即向广大用户综合提供互联网信息业务和增值业务的电信运营商。其必须具备的证书即为ICP证。ICP证是指各地通信管理部门核发的《中华人民共和国电信与信息服务业务经营许可证》,注意ICP证和大家看到网站底下的ICP备案不是同一个东西。
EDI证:Electronic Data Interchange,全称叫增值电信业务经营许可证-在线数据处理与交易处理业务,属于第B21类增值电信业务的范畴,具体是指利用各种与通信网络相连的数据与交易、事务处理应用平台,通过通信网络为用户提供在线数据处理和交易、事务处理的业务。
2. 第三方支付公司分账
与第三方支付公司合作,这类公司持有互联网支付牌照,并且已经有银行监管户了,可以直接接入他们现成的支付分账系统。
通过第三方支付公司分账,一般会受到支付渠道的“间连”政策影响,如2019年的微信支付断间联事件,同时支付宝也没有向第三方支付公司提供APP支付的接口。
这就意味着,使用此方案后,你的平台可能无法支持APP唤起支付宝、微信支付,虽然有一些技术方案可以解决,但是用户体验还是很差的。
3. 微信/支付宝官网分账
如果自家平台只需要支持微信H5、微信小程序,没有APP,不需要考虑支付宝支付,也可以使用微信的分账方案。支付宝应该也有类似的方案,但是我想应该极少公司会只考虑支付宝的场景吧。
配图:支付宝分账介绍
无论支付宝还是微信分账,都要求参与分账方需要有对应的支付宝、微信支付账号,如果合作对象是一些传统的供应侧的公司,可能对方还得先去注册一个。
另外要使用支付宝或微信分账功能,还需自家公司有一定的资质,例如我才了解到微信分账的时候,那时候只对微信服务商提供内测,那时候我们还不是服务商,更别提有内测资格了。
微信服务商分账:;index=4
支付宝商家分账:
4. 银企直联
与银行合作,开通银企直联系统,将支付宝、微信的收入提现到公司对公账户中,然后系统再向银行请求将资金转账给不同的供应商。
招商银行银企直联系统:
银企直联需要与企业对公账户相配合操作,假如最终选定了某银行的银企直联方案,则公司需要具有/开通在该银行的对公户,为了方便系统打通,建议将该对公户绑定到公司对外业务的支付宝/微信账户上。
各大银行的银企直联系统接口一般都比较保[古]守[董],对接起来要比那些互联网化的方案难度大一丢丢,而且银行对于收款银行卡的要求可能会影响用户绑卡的体验。
5. 人工模式
财务按照ERP的订单记录和支付渠道实收做账、定期人工将资金转账给供应商。此举毫无疑问浪费人力物力,且耗时长,对供应商来说自然很不友好。但是大部分公司不成规模时,或者大公司的小规模业务、传统非互联网业务,依然大量使用该模式。我们并不讨论该模式的好坏、未来趋势,对很多公司而言这个模式存在既有其合理的理由。对于我们而言,则是有机会将人工转换成系统操作。
03 我们的选择
我们在与多家银行、第三方支付机构沟通后,综合考虑很多后,最终采用了银企直联的模式。银企直联模式一般又有两种,前置机(又称代理服务器)模式、嵌入式模式。
采用哪种模式对接银企直联,我认为不是一个简单的技术问题,我觉得其实也与产品形态有很大的关系,另外有些银行可能只持续或主力维护其中某种方案,这也会变成选择的先决条件。
银企直联拓展阅读:
如果你的ERP系统是部署在云端,通过浏览器访问,建议就选前置机模式。
银企直联还有公网、专线模式,这个就看公司财力选择了。
最终方案:
04 流程介绍1. 用户支付
我们接了支付宝、微信、银联支付,实现了APP、H5、微信公众号、微信小程序、支付宝生活号的全场景支付。
2. 渠道资金提现
这是实现后续银企直联分账的前提,先要设置把钱从公司的支付宝、微信、银联账户中T+1自动结算到公司的同一个对公账户中。
3. 对账、分账
其实在用户下单的时候我们就知道了供应商、平台、物流、分销商的分成比例,此步骤有两个目的:
对账:确保系统计算的收入跟渠道、对公账户实收一致。支付宝、微信、银联等渠道都有T+1对账的接口,而银企直联系统则有查账的接口,通过本地业务订单、支付渠道账单、银行收支记录,确保三者一致。阶梯分账:我们跟一些供应商签订了按销量阶梯提成的方案,在此步骤对分账比例进行更新。
4. 业务系统向OA申请结算
此步骤并没有让业务系统直接与银企直联系统对接,而是把银企直联系统放在了公司内部OA后面,这样保障了资金系统的安全,且可以利用OA实现公司所有业务的业务财务一体化(简称“业财一体”)。另外OA系统中还是有领导的审批流,这个审批流我们尽可能的设计成了最精简的模式,因为有系统的自动对账、分账,所以原来线下出款很多审批节点都被代替了。
5. 银行前置机
此步骤主要是用于实现与银行系统通讯的加密、安全认证,属于系统自动化流程。
6. 财务在网银中确认出款
财务在银行的网银系统中看到,有OA推送过来的订单,插入U盾、输入密码后,完成出款。
有些大企业在系统稳定后,此步骤都可省略,在有一套成熟可靠的系统,加上一定的预警机制后,这一步其实会逐步淘汰。据我了解,很多银行确实也将这个步骤去掉了,出款变成了接收客户系统的指令,不再保留财务人工出款卡最后一步的流程。
7. 供应商、分销商、物流公司收到货款
这是此流程最后的一步,银行将资金支付给对应的收款方。收款方要是没开通手机通知之类的可能不会及时知道收到钱了,所以我们的业务系统在接收到结算流程结束后,还会再次通知绑定的联系人,资金已经到账。
05 总结
通过银企直联进行商家结算,可以有效地简约平台的人力物力,通过系统流程保障资金计算准确性、减少不必要的人员介入缩短结算周期,未来甚至实现全自动化出款。
对于一些小的供应商而言,资金流转快,太长的账期将很不利与他们的生存,对平台而言,加快结算可以有效提高供应商们的出货、售后积极性。
本文由 @iCheer 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
标签: #php开源c2c