编辑导语：在B端电商交易中，一些商品的交易涉及到了法律问题，这时便需要在系统中避免交易有法律问题的商品，于是有了商品交易管制系统。那么，b端交易管制系统应该怎么设计呢？一起来看一下吧。
B端电商交易中，很多商品的交易涉及到了法律问题，需要在系统中避免交易有法律问题的商品，于是就有了商品交易管制系统，它是风控体系的基础，也是最严格的风控，涉及到了法律等相关内容。
元器件行业的商品涉及到了许多进出口的管制条例，如美国都对应的商品进出口限制清单，日本、欧盟、中国等国家地区都具有相对应的限制，限制某人/某些企业对于特定的商品进行购买与使用。
避免平台上管制的商品被无法购买管制商品的用户产生交易，产生订单或其他服务，造成法律风险。
1）商品的管制是平台来进行管控的还是商家来进行管控的？
平台需要管控到交易的型号，避免交易出现不能交易的元器件产品，因为在法律中，可能不仅是服务商会涉及到法律问题，平台提供交易场所也可能会存在问题，所以管制商品不仅是服务商自己的行为，也涉及到了平台的管控。
2）如何判断是否进行管制？
下单客户的B端企业信息，下单的商品是否为管制商品，即需要订单的信息与管制清单的信息做比对，确认是否是管制内容。
3）什么时候进行管制？
管制是针对订单产生后进行的，当触发管制后，订单不能被确认，需要被销管部门进行确认后才可进行后续订单流程，此时有几点要点：
4）需求情况是什么？
必要且合理，重要且紧急，排期靠前，能够极大效率提高销售管理员对管制清单的反复比对；防止平台交易产生的法律风险。
5）如何保证扩展性？
首先利用订单的信息字段进行订单管制的匹配，具体的字段包括：谁下的单、买的什么商品、发票抬头来进行匹配。
不需要考虑地址等订单信息，因为这些信息不是相对严格的信息，反而增加了系统的复杂程度。
当订单中的客户信息与商品信息都符合管制信息时，进入管制状态。
其次能够不断更新管制的客户与管制的商品清单。每次平台的客户信息池与管制客户池定时进行一次刷新匹配，再来判断此客户是否是仍属于管制条款中。
最后要能够对管制的数据进行增删改查。增加、删除管制条款中的商品，注意商品是ID化的，管制信息在商品信息中，跟商品上下架状态不相关。
6）应归属在什么系统中？
系统应归属在交易系统中，下订单后先经过交易系统的判断再进入订单处理流程，属于订单系统子模块。
主要分为主要三个子模块：客户管制、商品管制、订单管制，其中客户管制和商品管制主要是针对管制基础数据的增删改查，为管制提供基础的数据信息，而订单管制是来处理管制的应用业务，多种服务订单的管制。
客户管制是针对当前平台上的客户所属的企业信息（B端企业信息）是否是管制企业，定时将当前平台的企业数据库中的客户名称与上传的各国家的管制清单进行匹配，由销管人员将其中的“管制客户”标记出来，并流入管制客户数据池，作为管制客户数据源，当与新的清单不匹配时，会提醒销管人员从管制客户数据源中移出此客户。
商品管制是针对元器件商品型号建立的管制库，根据不同的管制法规，将对应的型号商品添加到对应管制法规下，即形成了平台的管制商品库。
订单在公司平台可能有多种类型，例如样品、定制订单、期货订单等，都需要进行订单信息中的客户名称/发票抬头与商品型号的管制判断，当既是管制客户，又是属于管制型号的订单产生时，会无法进行下一步商家的订单流程，需要联系平台销管部门进行确认以及解除管制。
其实此处有思考是否要做到根据不同的法规（欧盟、美日进出口等），要同时都在上述清单的客户名称与商品型号才进行管制，但考虑到管制订单较为严格（宁可错杀100，不可放过1个），为避免平台风险，最终设计还是只要是管制的型号与管制的客户，都先标记为管制订单，无法进行后续流程，由销管来进行确认。
1）平台后台
2）商家后台（业务中台）
订单管制，具体管制涉及条款呈现。
3）对于客户
这里面引发了思考，希望能够尽可能找出管制的客户并标识出来的，比如华为，东莞华为，成都华为，他们的名称不同，却都是受到美国管制的B端主体，所以此处的客户管理应是关键词判断是否是疑似的管制客户。
4）对于订单
需要精准管控订单是否是无法售出的客户购买的管制型号，故通过精准匹配来判断是否是管制的订单。
以上就是一种B端涉及法律管制的系统的设计思路。
本文由 @浮云志 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。