easySales 中的订单履约如何运作：将拣货、打包和发货外包给 3PL
把你的订单交给第三方物流伙伴，由他们替你拣货、打包和发货。连接一个履约服务，然后手动、批量或通过履约规则自动发送订单——并让受支持的服务商把仓库状态同步回 easySales。
随着你的成长，自己打包每一个订单将无法继续扩展。easySales 中的订单履约把这项工作交给第三方物流（3PL）伙伴：easySales 把订单发送给伙伴，伙伴则从自己的仓库拣货、打包并发货。你在 easySales 中保留对订单的掌控，而由别人处理实际的发货工作。
本指南解释这里的履约意味着什么、支持哪些服务商、如何连接一个、发送订单的三种方式、订单离开后会发生什么，以及如何追踪它。读完之后，你将知道每个服务商各做什么、每项设置在哪里，以及——最重要的是——为什么有两个服务商的行为与其他服务商不同。
easySales 中的订单履约意味着什么
订单履约是指把订单的实物处理外包给一个外部物流伙伴。你不再从自己的货架上拣选商品并亲自打包包裹，而是连接一个履约服务，把订单交给它，由伙伴的仓库把货物发给你的客户。
这不同于你自己来做——内部拣货和打包，由你自己的团队准备包裹——也不同于 marketplace 的履约计划，例如 eMAG FBE 或 Amazon FBA，那是由 marketplace 存储并发送你的库存。那些是本功能不涉及的独立概念。在这里，你选择一个物流伙伴，连接你在它那里的账户，然后从 easySales 内部把订单路由给它。
结果是清晰的分工：easySales 仍然是订单的归属地——客户、商品、状态——而伙伴负责仓库工作：定位商品、打包并发出包裹。你决定哪些订单送往伙伴以及何时送出，逐单或自动，订单全程保持可见。
受支持的履约服务商
easySales 连接到一系列履约伙伴——例如 Huboxx、KLG、Linker、Fulfillment by FHB Group、Fulfill.ro、HelpShip、Metrica.bg、EuShipments 和 FanCourier 这样的服务商。每个都是你拥有账户的物流公司；你在 easySales 中连接该账户，然后向它发送订单。对你可用的确切列表会显示在履约服务标签页上。
EuShipments
更深度的整合（多账户）——连接多个账户，通过提交流程运行，回传状态，并把订单发票上传到仓库。
FanCourier
更深度的整合（多账户）——连接多个账户，通过提交流程运行，并回传状态。
单账户服务商
Huboxx、KLG、Linker、Fulfillment by FHB Group、Fulfill.ro、HelpShip 和 Metrica.bg——每个连接一个账户，手动、批量或通过履约规则发送订单。
最重要的不是服务商的数量，而是一个行为上的区分——这是你在设置任何东西之前需要掌握的最重要的一点。其中两个——EuShipments 和 FanCourier——拥有更深度的整合：它们是多账户的，通过一个单独的订单提交流程运行，并把仓库状态同步回 easySales。其他每一个可连接的服务商都使用最初的单账户流程。接下来的章节会介绍如何连接每种类型，但从一开始就记住这个区分：它决定了一个服务商在 easySales 中出现在哪里，以及订单到达它之后它会做什么。
连接一个履约服务
履约在一个专门的设置区域中配置，从侧边栏的整合方式 → 订单完成情况下打开，有两个标签页。履约服务标签页用于连接和配置你的服务商账户。履约规则标签页用于设置自动路由——把所选销售渠道的订单发送到某个服务，无需手动处理。先从履约服务开始。
凭据与连接测试
要连接一个服务商，请输入它提供给你的凭据——标识你账户的详细信息。easySales 在保存前会实时向服务商测试这些凭据，因此如果有什么不对（密钥错误、登录过期），你会立即知道，而不是等到订单发不出去时才发现。只有在服务商接受后，连接才会保存。
依靠这项实时检查：一个已保存的履约服务在你保存的那一刻就是可用的。如果凭据稍后在服务商一侧发生变化——账户被轮换或过期——重新连接会让它们经过同样的测试，因此在你通过它路由订单之前，你总能知道连接是良好的。
单账户与多账户服务商
这里两组就有了区别。单账户服务商——除 EuShipments 和 FanCourier 之外每一个可连接的伙伴（Huboxx、KLG、Linker、Fulfillment by FHB Group、Fulfill.ro、HelpShip 和 Metrica.bg）——遵循最初的履约流程：你连接一个账户，然后手动、批量或通过履约规则自动向它发送订单。
多账户服务商——EuShipments 和 FanCourier——拥有更深度的整合。你可以为每个服务商连接多个账户，订单通过一个单独的提交流程运行，二者都会把履约状态同步回 easySales（EuShipments 还会把订单的发票上传到伙伴的仓库）。因为它们通过那个流程运作，而非最初的流程，所以它们被有意地不提供在订单下拉菜单、履约规则或批量操作中。这是最常见的困惑来源：如果你连接了 EuShipments 或 FanCourier 却在发送到履约的下拉菜单中找不到它，这是正常的——这些服务商是通过提交流程驱动的，而不是通过订单选择器。
| 单账户（其他所有服务商） | 更深度整合 / 多账户（EuShipments / FanCourier） | |
|---|---|---|
| 每个服务商多个账户 | 否——一个账户 | 是——多个账户 |
| 状态同步回 easySales | 否 | 是 |
| 发票上传到仓库 | 否 | 仅 EuShipments，当订单有发票时 |
| 可在订单下拉菜单、批量和履约规则中使用 | 是 | 否——通过提交流程驱动 |
把订单发送到履约
一旦服务连接好，有三种方式把订单送到它那里。
从订单手动发送
打开单个订单，从那里把它发送到已连接的履约服务。这是最简单的路径——当只有部分订单送往伙伴，或当你想逐单决定时很有用。单账户服务商会出现在订单上的服务选择器中。
批量
一次选择多个订单，用批量履约一个操作把它们发送到某个履约服务，而无需逐个打开订单。这是清理一批全部送往同一个单账户服务的订单的最快方式。
通过履约规则自动发送
履约规则完全省去了手动步骤。在履约规则标签页上，你把一个销售渠道映射到一个履约服务——例如，「来自这个渠道的每个订单都送往这个服务」。从那以后，符合条件的订单会在进来时自动路由，无需你操作。规则适用于单账户服务商；多账户服务商则通过提交流程处理。
当一个履约安排已经稳定时就用它：如果某个销售渠道总是通过同一个伙伴发货，一条规则就意味着你再也不用操心那些订单。对于不符合固定模式的订单，继续在规则之外使用手动和批量选项——自动路由与手动发送可以并存。
订单发送后会发生什么
把订单发送到履约会改变 easySales 追踪它的方式。
状态变更。 当订单被发送到履约服务时，它的状态会变为处理中，并为其分配履约服务，这样你就能看出哪些订单现在在伙伴那里。已经终结的订单（已取消、已完成或退货）会保留其状态而不被覆盖，这样你不会丢失它们在你自己流程中的位置。
发票上传。 对于 EuShipments，如果订单已有发票，easySales 会把它连同订单一起上传到伙伴的仓库系统，让伙伴带着正确的单据发货。其他服务商不会以这种方式收到上传的发票。
状态同步回传。 EuShipments 和 FanCourier 是把履约状态同步回 easySales 的通用型 3PL 服务商，因此订单在它们仓库中的进度会自动出现在你这一侧。单账户服务商——Huboxx、KLG 和 Linker——不回传状态；对于它们，easySales 会记录订单已发送，但不会收到持续的仓库更新。
取消。 在 easySales 中取消订单是否也会告诉伙伴的仓库停止，取决于具体服务商。有些服务商会收到取消；有些不会，因此你取消的订单如果已经在伙伴的流程中，仍可能被发出。如果某个被取消的订单很重要，请直接向服务商确认它已被停止。
这些行为合在一起，解释了为什么服务商的选择超出了谁发包裹这件事。多账户服务商提供更丰富的双向画面——仓库状态会回流（且使用 EuShipments 时发票随订单一起传送）——而单账户的交接是单向的：easySales 告诉伙伴去发货，之后你就依赖伙伴自己的系统。两者都没有错；它们适合不同的配置，知道你用的是哪一种，能让你免于期待那些永远不会到来的更新。
追踪已履约的订单
已发送的订单不会获得自己专属的状态，所以你不是按状态、而是按履约服务来追踪已履约的订单。在订单列表中，按履约服务字段筛选，即可查看当前路由到伙伴的每一个订单（并可缩小到某个特定服务商）。对于 EuShipments 和 FanCourier，回传同步的状态会随着仓库处理每个订单而保持其进度最新。对于单账户服务商，该筛选告诉你订单已交接；请直接向服务商确认进度，因为它们不会回报到 easySales。
在日常使用中，履约服务筛选把你的订单列表变成履约看板：它把仍在你手中的订单与已在伙伴那里的订单区分开来，而对于 EuShipments 和 FanCourier，订单状态会随着仓库的操作持续变动。如果你需要确认某个单账户服务商的单个订单——比如有客户在追问一次配送——订单可以确认它已被发送，而服务商自己的追踪则补足其余信息。