从0到1构建电子商务平台售后系统:退货和退款

售后服务类型基本上可以分为四种情况:只退(未收到)、退货退款(已收到)、换货、补货本文仅讨论退款的情况。我将从售后申请、退款单的状态和操作、退款的分支流程以及涉及的其他环节四个维度进行解释。

申请

首先，申请售后服务时，需要选择申请原因，填写问题描述，上传凭证图片等三项操作。提交后，将生成售后服务记录单，然后进入后台供员工操作。

，其中最重要的是申请理由因为《电商法》规定“买方应在收到货物之日起七天内提出售后退货申请(根据从收到物流后第二天零点开始计算的时间，完整的168小时应为七天)。当用户选择申请理由为“没有理由在七天内退货”时，用户的主动性会更大。只要不是用户自己的问题，商家必须同意货物的损坏是否影响二次销售。但是，是否支持七天无任何理由的退货是跟随商品，有些商品支持有些不支持，所以在添加商品时需要选择。

因为我们公司不能像淘宝那样做自己的物流系统来及时捕捉登录信息的反馈，所以给用户10天(估计3天的物流配送+7天的无理由退货)，10天发货后用户就不能选择申请理由。

退货退款单状态对应操作1。用户状态对应操作

正在审查(修改申请、取消申请)、等待买方交付货物(填写物流单据号、取消申请)、等待商家接收货物(无)、完成(无)、被拒绝(修改申请、取消申请)、关闭(无)

2年。背景状态对应操作

待定审查(通过、拒绝)、待定买方装运(无)、待定商户收据(确认收据、查看物流)、待定商户退款(确认退款、查看物流)、已完成(查看物流)、已拒绝(无)、已关闭(无)

如上图所示，除了“退款给商家”(不像订单那么复杂，因为一个售后订单只对应一种商品)之外，用户端退货订单的状态和后台可以配对，而用户端省略“退款给商家”的目的主要是从用户的角度考虑，一是降低用户的认知成本，二是缓解用户的焦虑。

和背景为什么这种状态是因为对于企业来说，收货是由商品部门完成的，退库是由财务部门完成的，而不同部门的权限是不同的。当然，如果你想更详细，你甚至可以有一套财务审批流程(审批、支付等操作都是由财务和出纳等角色来操作。)，这在这里没有完成。

需要解释当商家点击通过时，确认地址弹出窗口应该出现，这是商家添加的返回地址该弹出窗口的目的是选择要发送给用户的返回地址，同时提醒商家返回地址是否已经改变。

回流支管流量

实际上，退货的前向流程非常简单，就像上图一样，不同的操作会改变不同的状态，而复杂的流程是多种分支流程，这就要求系统对它们进行限制。

首先需要明确的是，当用户申请订单中某商品的售后服务时，系统将冻结整个订单的金额，在售后服务订单完成之前(处于完成或关闭状态)，商户将不能申请订单金额的结算。例如，如果用户在一个订单中购买了2个商品A和2个商品B，并且只申请了一个商品A，那么此时整个订单金额将被冻结(为什么要冻结整个订单而不仅仅是商品将在财务章节中解释)

冻结订单金额和各种限制都是为了保护用户和商家的利益。

1年。

客户限额

(1)申请

售后时限

首先，回执确认分为用户主动回执和系统自动回执。一般来说，自动确认收货的时间规则如下:从商家交货之日起10天。例如，淘宝自动确认从收货日期算起7天。但是，淘宝有自己的物流系统，我们不能这样做，所以我们增加了3天的物流时间(当然，不同的时间可以根据不同的商品属性设置)

在确认收到货物后，将计算申请售后服务的时间。一般来说，是15天。15天后，用户将无法申请

(2)超时未处理限制

整个退货流程需要用户完成两个步骤:

商户通过售后申请后，要求用户退回商品并填写物流单号； 当商家拒绝时，用户需要修改应用程序并提交或取消应用程序。

如果用户不操作，通常会有7*24小时。截止日期后，售后订单将自动关闭，用户只能重新申请。

(3)修改应用程序的数量限制

用户可以修改申请并以“审查中”和“拒绝中”两种方式提交申请，但此处提到的限制处于“拒绝中”状态。例如，在用户被拒绝之后，他反复修改应用程序并在7天结束之前提交它，并且商家也一直拒绝它，这可能导致订单的金额被冻结并且商家不能结算账户。

(4)售后应用的

限制

接着说，如果用户取消退货单并在被拒绝后重新申请，它也可能进入周期，因此售后申请的次数也有限制。

的限制肯定在申请售后服务时间的主要前提内，但这样做的目的是防止用户恶意提交和对商家造成骚扰。当然，这个限制可以增加也可以不增加。

2年。商户方面的限制涉及其他

条款

其他涉及商品返还和交换的部门包括商人、商品、金融、营销等。这些部分之间可能有一些数据联系，因此需要考虑它们。当然，这些部分主要是背景数据，用户的感知并不大。

1年。商户

通用平台会给每个商户一个分数和一个奖惩系统。

评级的目的可能对用户方影响更大，无论搜索结果排名更高还是您喜欢等待交通入口显示，评级高的商家下的产品更有可能出现在用户面前。但是，退货和换货肯定会影响评分。例如，当用户选择“无理由七天”作为申请的理由时，分数可能不包括在分数中，而是包括质量问题或商家的服务态度，并且不想要它。这肯定会影响商家扣分的权利。

的奖罚制度更多的是联系平台和商家之间的联系，应该根据公司在不同时期的业务需求来制定，比如因质量问题退货的商家占多少，需要罚款多少，或者一些具体的活动不能参加。

2年。

商品

退货涉及到与商品的关联两个维度，即商品的得分和库存

上面说的是商家的分数，但是每个产品肯定会有自己的一套评分规则，这样搜索引擎在将产品从数据库中取出后会有一个连续的显示。退货会影响功率降低。这里的计算规则非常复杂，必须根据公司当前的业务目的来制定。这里不执行。

用户下单付款后将扣除商品库存，成功退货后将恢复库存。当然，这也取决于产品是否已被删除或sku是否已被删除。

3年。财务

顺序中的金额信息与退货相关，包括运费、金币扣除、实际支付金额和结算金额。

(1)运费

首先，必须确定由哪一方承担退货的运费，以及用户支付的运费是否应退还。因此，有必要确定是用户自己的原因还是货物的原因(我们的平台还没有涉及运费保险)

有两个选项:

系统根据应用的原因进行干预和判断。例如，如果七天内没有理由退货，用户将承担责任，卖方将对货物质量承担责任。这时，事情就更复杂了。可能会有这样的情况，即商家在用户申请退货之前提取付款，因此运费将从押金中扣除(详情将在财务章节中解释)。 卖家和用户在底线下自行协商。

人认为，如果系统介入，对商家来说似乎更具强制性，对用户来说更安全，但卖家肯定会利用漏洞，比如，告诉用户不要选择哪个应用程序，这实际上是对用户的一种骚扰，更开放一些，让双方更自由地交流会更好。

则表示退还多少运费由用户支付首先，运费由运费模板计算，分为按重量计算和按件数计算(先不讨论体积，用的太少)

例如，如果按重量计算运费模板，第一个价格为2公斤，第一个价格为10元，第二个价格为1公斤，第三个价格为3元。一个单品的重量是0.7公斤，如果你买1~2件，你需要支付运费10元，3~4件需要支付10+3元，5件需要支付10+3+3元，6件需要支付10+3+3+3元。计算的运费是不规则的。问题出现了。当我买6件时，我得付19元的运费。那么当我申请退1件的时候，我应该退多少运费，3件应该退多少

根据运费模板计算退款明显不合理。有一个基于平均值的计划。例如，退回3件的运费是19/6*3元，或者是固定的退款金额。例如，您只需在支付10元运费后返还5元，在支付20元后返还10元。事实上，这并不合理。也许我暂时还没有想到一个更合理的计划。有计划的领导欢迎在评论区与大家分享！

因此，基于退款金额的问题，我倾向于上一段中的第二种选择，即卖家和用户可以在线协商，退款金额由您决定。

是回程运费的最后一期。如果这真的是一个商品问题，不知道用户为退货支付了多少费用，并且系统唯一可以计算的是根据运输模板，但是肯定有一些不准确的地方，例如在商家与快递公司交谈之后，支付的运费低于用户支付的运费因此，最好的解决方案是在商家和用户之间进行协商。

顺便提一下，如果平台具有全额运费减免的功能，可能存在的风险是，例如，如果用户购买2件邮费，在没有收到货物的情况下申请退款，可能会给商家造成损失。因此，可以在扣除运费后退款。

(2)金币扣除和实际支付金额

用户可以通过我们平台上的一些渠道获得金币。像JD.com一样，JD.com可以作为购买商品的补贴。提交订单时，用户将按照一定的比例将金币分配给每种商品。例如，甲、乙、丙商品的售价分别为20元、30元和50元，他们将分别购买2件。如果你有20元的金币，你可以分别扣除4元、6元和10元。因此，当你申请退货时，你将得到18元和2元现金的金币。

(3)结算金额

是指平台抽取佣金后商户可以结算的金额，例如，商品售价为100元，平台抽取5元佣金，商户可以结算95元在用户成功退款后，结算金额的这一部分将从可设置的金额中扣除。

接着说，为什么售后服务与订单无关？如果你读了我之前写的订单系统，你会知道我之前设计的是售后订单和订单之间的状态是独立和不干涉的。例如，如果一个订单中只有一个项目，并且只有该项目的售后服务被启动，则订单状态将会改变，例如，它被称为“正在退款”。这还是有道理的。然而，当一个订单中有多种商品或多种采购数量时，很难说是否有些商品已经开始售后服务，而有些商品还没有。最简单的解决方案是订单和售后订单相互独立。

因此，订单的后续操作，如确认收货、评估等。，与售后状况无关。自动确认收货时间的倒计时与订单中售后单据的存在也没有相互影响。

由于我们的平台尚未涵盖优惠券、全额折扣(如200减50)等营销功能，本文将不予扩展。主要原因是我还没有完成这些功能。有可能相反的一些细节没有被充分考虑到，从而引起你们所有人的误解。

以上是我对返回系统的解释。如果有任何不合理或实际上有更好的解决方案，欢迎你指出来并提出你的意见！

在

之前，我写了三篇关于订单系统的文章，并收到了一些反馈。一些评论说，如果我写得太详细，我可以简化我的写作。其他人说我应该写得很仔细，这样别人才能理解。我也在思考，如果标题可以仅仅为了阅读量而变得更加虚张声势，那么内容可以因为赞扬量而变得更加简单和流畅。然而，我之前也说过，写这篇文章的目的是，首先，重复一套，其次，与每个人讨论，并发现我写的是不合理的。事实上，我还有一个感觉。当我还是一家电子商务公司时，我非常愚蠢，踩了很多坑。我希望尽可能多的写下这些坑，希望能给大家一些参考。

张地图来自Unsplash，基于CC0协议。