本来这篇文章的知识点是给我下一次出去蜕变准备的，学历干不过人家，只能在一个领域深入打磨扎根，除了技术，业务也要懂点，成为这个领域带砖头的砖家，下次流浪到社会才能唬住面试官，有份暂时安稳的工作。世事无常，昨天听闻部门解散了，因为绩效OK，我被调到别的部门做事了。唉，可能这辈子都不会再搞供应链相关的东西了，曾经在兔狗刚进去不久因为他们业务不行被无情地伤害过，所以听闻一些事情的时候我会深深地红了眼。“干一行爱一行”，那么，我愿意燃烧我自己微薄的知识点，照亮曾经一起做过事的人，赶紧收藏，面试的时候背一下吧！
。。。。。。题记
一、供应链金融中的保理业务是怎么来的？
在供应链金融中有两大业务，堪称是“卧龙凤雏”。一块是信票业务，也就是通俗意义上的白条；另一块就是我们今天文中讲的保理业务。那么，什么是供应链呢？通俗一点讲，我认为是构成一笔买卖或者交易，有相应的供应商（服务方），有相应的核心企业（消费方），那么就构成这样一条链子，做得大就长一点，做的小就短一点。
俗话说的好，“做事情不要掉链子”，可想而知这个链啊，很重要。所以啦，我们前面说的那个供应链啊，它不能断掉，我们要想尽一切办法，让这个链啊，连起来，转起来。为什么呢？这关乎到一大片人的就业啊，一大片人的饭碗啊，例如你供应商发出去货拿不到钱，一个月开销就奔几万或者几十万几百万去了吧，可能一两个月还能撑下去，让你撑六个月，在不考虑金融危机，环境等变化的影响下，是不是很容易就垮掉了，一大波人又输出到社会再就业；再例如你核心企业，拿到货加工后又买不掉，那就再招点人嘛，人多好办事，先画个大饼，我们是一家很牛逼很牛逼的面膜公司，我们拥有一流的供货商，我们的产品干翻市面上其他的产品，你们进来就网上各大直播平台卖吧。结果话说的太满，业绩亏成屎了呢，那怎么办呢，裁员嘛，又输出一大波人才再就业。
保理是西方那边传过来的，“factoring”译为保理。它的存在就是让整条链子上的交易能够圆满地进行下去，供应商和核心企业都能够活下去，实现共同富裕。那这个保理公司啊，也很好理解，就是提供应收账款账户管理、应收账款融资
、应收账款催收和承担应收账款坏账风险的这么一个东西。对，就是一个发钱收钱的这么个玩意，一般来讲，例如说银行啊、跟银行有密切关系的公司啊、大集团（例如某建集团有一局、二局、、、、、、八局，它就可能成立一个某建保理公司，去给下面的某局做融资，保证下面子公司能够活下来，交易也顺利进行）都可以做这件事。
保理的业务啊，也拆分出很多种模式，例如正向保理（最常见的保理）、反向保理（跟风险较小信用较好的一方做保理）、到货保理（按到货的时间点做保理）、再保理（觉得之前还算OK，再重复一次上次的保理）、双保理（一般是做国际进出口业务，公司资质不够，没过多了解，放弃讲了）、明保理（应收账款通知核心企业）、暗保理（应收账款不通知核心企业）、有追索权保理（收不回账账款还你，把钱还回去）、无追索权保理（收不回账自认倒霉）这么一大坨，我这边按常规的介绍几种常见的吧。
二、正向保理业务
对于正向保理这块，我主要是组合了明保理和暗保理来讲的，他们的区分点就在于是否将应收账款转让通知给核心企业，若通知给核心企业，那么走的是明保理，反之就是暗保理。在天朝，大部分是明保理，因为《合同法》中规定很明确，供应商在对自有应收账款转让时，必须在购销合同中约定，且必须通知买方，所以说啊，你不通知还有点风险的。
2.1、明保理
如下图所示，明保理它的一个大致的流程就是，供应商赊销（货物或者服务）给核心企业，针对于供应商在一定账期内形成的应收账款由核心企业给出（这里为了不混淆账款这个概念，有助于读者理解，统一用了应收账款来做关系处理，但是你要清楚的是，针对于供应商是应收账款，针对于核心企业那就是应付账款，后面不再赘述）。供应商拿着账款去找保理商做应收账款转让，在这里其实图中还可以画一条虚线由供应商箭头指向核心企业，表示通知核心企业应收账款的转让，因为正常按照《合同法》有些嘛，我这边就不高兴画，然后保理商跟核心企业进行应收账款确认以后呢，他就给供应商提供资金融资，等到账期到了的时候呢，核心企业就不用管供应商了，将钱打到保理商指定的相关账户上进行回款就好了。
看似就6条线很简单，实际上它是一个很复杂的过程，因为我们在东西嘛，肯定是把复杂的东西简单化，而不是越搞越复杂，人的脑容量都是有限的，怎么简单怎么来嘛。
今天，我有一个危险的想法
我以前觉得买房没有那么难，只要我嘴皮子够快，就能买得起房，心中有大海，到哪里都是马尔代夫。我先去A银行拿着我的一些社会资质去贷款50W，然后我再自己凑一点去付个首付，再然后我把我的资产（刚买的房子）给B银行看，再贷出50W，循环这个步骤，我一共干翻了6个银行，理想状态下我有300W的资产加一套房，我再这笔钱去类似于余额宝这种只赚不赔的货币基金去投资，就是不断地干翻银行不断地还钱，反正欠多了就不是我的烦恼哈哈，只要状态是流动的，就感觉日子过得还是很滋润的。
在没有接受供应链金融保理相关知识熏陶的情况下，基于楼上的理想状态下的想法，我又萌发了去干翻保理公司的想法，我注册3个公司分别是a、b、c。然后a 100%控股b和c，我拿着b和c做一些猥琐的事情，给b定义一个供应商的角色，比如说面膜的原材料，各种芦荟啊、树叶精华啊，然后c是核心企业，负责研发面膜，然后再搞个直播带货卖出去。然后找个有钱的冤大头，让它进行保理业务的融资，循环往复，实际上呢，b和c都是没有真实的业务的，就是虚晃一枪，拿来套钱干翻保理公司的。
大家觉得想法还是很美好的，但是现实是很残酷的，这种做法是玩不转的。为什么呢？央行有一个叫中登网的平台https://www.zhongdengwang.org.cn/， 所有的所有的动产融资交易在这上面都会有记录，也就是说，你去A银行贷款50W没问题，但是当你去B银行贷款的时候，它就会去这个平台去看下你有没有相关的贷款记录，有的话，它就不贷给你了，规避风险嘛，想法是挺好的，但确实是玩不转的。
实际上呢，在保理公司做相关保理的时候呢，供应商和核心企业都会出具相关的证明的，这还只是前期，然后进行项目立项，项目审批（比如 市场部 (经办、经理)-> 法务风控部（经办、经理）-> 总经理 -> 财务（经办、经理）-> 出纳这样一套流程，我这边随便写的，这个就叫审批流，有通过不通过，反正就是来回打），应收账款转让，应收账款确认，提供相关的融资，这里的话，其实如果是银行，它会让你去它指定的银行开个账号，然后去监控那个账号的资金流动或者暂时冻结你的资金，知道某一个环节OK，里面的钱才能够转。
总结一下，明保理它利于核心企业接受，但是对供货商就会有些风险，因为双方需要摊牌，展示自己真实的市场背景，例如供应商资金或者市场状态不佳，对贸易合作会有伤害。
2.2、暗保理
暗保理的话，例如供应商自己存在资金和市场状况不佳的问题，而核心企业又比较大，跟它做生意的供应商有很多个，这个时候核心企业就横着走了，你们反正要跟我做生意，你们就必须给我赊销账款6个月，不然我就换一家做。没办法，供应商只能吃点亏，拿着这个账款去找保理公司进行融资，维持企业的发展，心想啊，这也忒坏了，我要是告诉它，下次它不就知道我的老底了嘛，所以就走暗保理，不通知核心企业了，假装我资金很雄厚，过了6个月自己去收账，然后把收到的还给保理商，保理商呢中间赚差价。当然，也有收不回账的情况，例如核心企业造的孽太重，佛祖不让留在人间，就走了呗。那这收不回来的钱，是供应商背，还是保理公司背呢？我们接着往下看
三、反向保理业务
这里再讲一下反向保理，针对于楼上抛出的问题。保理商他也不是傻子，既然你供应商的资金不太行，也不清楚你到底有没有能够保证的生产环境和生产力，信用也一般，是有一定的交易风险的。而核心企业是在这个行业扎根20年还依旧辉煌的大公司，它的各项流程啊，报表啊是很规范的，规章制度啊是很规范的，风险小、信用好。那就以佛祖的名义，跟核心企业签呗，不管是账面上，风险上都是利大于弊。对外弘扬业务的时候还可以说，我和某某某500强公司有过过命资金业务往来，这不香嘛。
反向保理这边的流程就是，不做应收账款转让了，我直接跟核心企业先签订相关协议，然后核心企业这边提交应收账款，保理公司通知供应商是否有需要保理的意向，有的话你就提交保理申请，然后保理公司进行相关审查后，打钱，最后账期到了，由核心企业把钱打给保理公司。
五、有追索权保理和无追索权保理
所有的账目，都有一定的坏账的风险，针对于这个账款能不能收得回来，又可以拆分出有追索权的保理和无追索权的保理，其实也很好理解，就是出现坏账的时候，有追索权的就可以要求供应商还钱，然后把账款还给你。
六、保理池
关于保理池我这边就一笔带过了，例如某建集团旗下的保理公司，给一局的授信额度是100W，一局第一次用掉了50W，剩余50W的额度，而它第二次要贷出70W，那么它要把之前的50W还回去，或者问问看还个20W先行不行，保理池凑够70W，然后再一把掏空保理池，今年的额度也就用完了再不回款的情况下已经用完了。
七、前端在保理业务中的应用
我们公司是一个重后端轻前端的这么个公司，一方面是积累了20多年的传统文化根深蒂固，认为前端还是处于远古时代html刀耕火种。另一方面也是业务上前端难以支撑起整个架构，说的不好听一点，就是可有可无，大街上随便找就行了。那作为一个已经工作了两年半的前端，我这边还是想反击下，你去相亲、你去应聘、你的衣着不重要吗？这是门面啊，哪怕你真的很有内涵，如果你一开始看上去很邋遢，她为什么要看上你呢？昂！
这一年，江涛在供应链金融做相关业务，主要在以下几个方面有感悟
- 针对于各项数据的报表（柱形图、扇形图、折线图这三个可以说很常见了）
- 简单列表和复杂列表的设计和实现（例如根据不同状态展示不同行列的表格，以及跟着脑阔疼的操作）
- 针对金额的操作和显示（都知道js是不适合做运算密集型的语言，适合做io密集型的语言，然后就是进度问题，比如0.1 0.2与0.3的关系，以及超大整数运算，千分位展示等等）
- 文件的上传下载预览（没什么好说的，各大媒体文件）
- 针对审批流的相关业务展示
业务上大概就这些是万变不离其宗的，架构上比如说，从最基础的工具包的集成（时间、金额、数字、上传、下载、正则。。。。。。）、公共布局组件（框定整个页面各个应用场景的布局）、业务组件（文件上传下载、文件预览、通用表格。。。。。。）
八、最后
以上就是我的一些浅薄的见解，如有不对，供批评指正。
