订单状态同步旨在防止的，正是那种值得大声报错的一个错误
订单状态同步意味着：您的商店使用了某个尚未被映射的状态，该状态在所有报表中都不会产生任何收入，直到它被分类。这不是一个 Bug——这与支付方式功能遵循相同的理念：一个未分类的状态可能意味着从刚下单到已退款等任何情况，因此报表将其视为零，而不是猜测。
- ✓订单所在位置 — 每个状态所持有的收入，无论是否已计入，因此大量收入集中在未映射或已取消状态之下，是需要首先检查的事项。
- ✓五种含义，一个小词汇表 — 未映射、已下单、已付款、已完成、已发货——您商店使用的每个平台特定状态名称都会被分类到其中之一。
- ✓已取消，独立复选框 — 独立于含义之外，因此一个状态可以同时是“已完成”和“已取消”，如果商店工作流需要的话。
- ✓收入覆盖，默认为矩阵规则 — “遵循矩阵”是默认值；仅当某个状态确实需要打破常规的状态加支付方式规则时才进行覆盖。
- ✓未映射即为零，而非未定义 — 未映射的状态在报表中任何地方都不计收入，直到有人将其分类，因此遗漏的映射会显示为缺口，而非无声的过量计数。
在分类之前，先看看收入分布在哪里
在触及映射表之前，两列独立排序、从大到小排列的份额条列表显示了商店每个自有状态名称所持有的收入和订单数量——无论是否已计入。条块从零开始，其宽度为该行在显示总数中的份额；只有当某一行占有100%的份额时它才会占满整行，任何低于1%的正向份额仍会获得1%宽的细条，而其标签保留真实百分比。没有对比序列或零线——总计为零时直接显示零。从持有最大收入份额的状态开始，然后检查其订单份额：如果订单份额小而收入份额大，则值得优先处理，因为该处的映射错误会影响不成比例的价值。大量收入份额集中在“未映射”或“已取消”状态下，是需要检查映射的信号——而不是收入应当计入的证据。
- ✓显示每个状态 — 包括尚未分类的状态，确保在未映射期间没有状态不可见。
- ✓收入与订单，独立排序 — 无论收入如何，资金都与该状态关联，同时显示该状态下有多少订单，因此一个状态可能承载大量订单而收入很少，或者相反。
- ✓带有来源标记 — 例如 bizniweb——适用于从多个平台拉取数据的商店。
- ✓警告横幅统计剩余数量 — “N 个状态尚未分类”保持可见，直到所有状态都被映射。
映射 bizniweb，或您商店实际使用的任何平台字符串
每一行都是您的商店平台发送的精确状态字符串，并带有来源标记。新的连接仅从商店实际报告的状态名称中生成行——已知的平台值会被赋予合理的默认值（WooCommerce 的 'processing' 映射为已付款，'refunded' 映射为已付款加已取消），未知值起始为未映射，重新连接不会覆盖您已做出的决定，但您从未触及的行可能会获得新习得的默认值。从一个刻意简短的小列表中选取其含义，如果需要可独立勾选已取消，并将收入覆盖保留为“遵循矩阵”，除非该特定状态需要打破规则——矩阵将货到付款、银行转账、在线卡支付和钱包支付下的已付款、已发货和已完成计入收入，而“其他”计入已付款和已完成但不计入已发货，即使“始终计入收入”也无法将已勾选的取消项转为收入。该表就是您将订单状态映射到收入的方式；规则的另一半——支付方式的类型——位于下一页。
- ✓您在商店中的状态 — 您的平台使用的精确字符串，例如来自 bizniweb，未经重命名。
- ✓含义 — 未映射、已下单、已付款、已完成或已发货。
- ✓已取消 — 一个单独的复选框，独立于含义；它始终优先，即使覆盖了“始终计入收入”的覆盖设置。
- ✓收入覆盖 — 默认为“遵循矩阵”，因此状态和支付方式共同决定；仅在某个状态确实无法通过共享矩阵表示时，才使用始终/从不计入收入。
- ✓每次编辑自动保存 — 无保存按钮；更改后立即发送，显示“保存中……”或返回的错误，并且仅触及那一行——其他所有内容保持不变。
准备好查看哪些状态实际在计入收入了吗？
Free check · 7-day trial · no credit card