未映射的方式永远不会计入收入
支付方式功能用于将您商店自有的支付方式名称按类型分类——银行转账、货到付款、在线卡支付。与订单状态配对后，该类型决定订单是否产生收入。
支付方式分类与状态共同决定 两者缺一不可
订单状态功能设定每个状态的含义；支付方式功能处理支付方式分类——每种支付方式属于什么类型。两者单独都不能决定收入——只有两者配对后满足条件，订单才计入收入。未映射的方式永远不计入，原因与未映射的状态相同：将尚未到账的款项算作收入，是唯一值得大声宣告失败的错误。
- ✓收入与订单数量，并列展示——两者往往不一致，而它们之间的差距通常就是值得关注的原因。
- ✓类型，而非原始标签——银行转账、货到付款、在线卡支付等，从您商店自有的支付方式名称映射而来。
- ✓标注来源——例如 bizniweb——适用于从多个平台拉取支付数据的商店。
- ✓未映射即为零，与订单状态同理——未分类的支付方式有意不计入收入。
- ✓与订单状态协同工作，而非替代——此处设置的类型与订单状态中设置的含义共同决定任何给定订单是否产生收入。
收入与订单数量，以及两者之间的差距
收入与订单各自以独立的份额条列表呈现，按数值从高到低排序——收入以净收入的强调色显示，订单以绿色显示纯计数值。每一行显示原始方式名称、其绝对值及其在列表中的百分比，条的长度与该百分比匹配；任何正数值片段至少获得 1% 的宽度以保持可见。没有坐标轴、基线或零线——宽度纯粹是列表总额的份额，如果总额不为正数，则整个分割图隐藏。某方式承担的收入份额大于订单份额时，表示其运行的订单价值高于商店平均值；反之则表示价值较低——这一差距，而非任何一个单独的数字，通常就是打开该方式并检查其类型的原因。
- ✓收入——通过此方式支付的订单所归属的净收入，以报告货币显示。
- ✓订单数量——使用该方式的订单数量，与收入无关。
- ✓两者之间的差距——收入份额大于订单份额，表明该方式价值较高，其受理成本值得关注；这是一个调查信号，而非自动的好或坏评分。
- ✓与映射表分离——该混合图按原始支付名称对去重后的导入订单进行分组；不按您下方分配的 Kind（类型）进行筛选或重新分组。
将 bizniweb 支付字符串映射为报告可理解的类型
每一行都是您商店平台命名的支付方式，标注了来源，按平台及原始名称排序。有一个提示框显示还有多少行处于「未映射」草稿状态。选择其类型——货到付款、银行转账、在线卡支付、钱包或其他——即可立即保存，无需点击保存按钮：下拉菜单自动保存，请求运行时本地草稿保持可见，并显示「保存中……」或返回的错误。在后续的矩阵中，货到付款、银行转账、在线卡支付和钱包在已付款、已履行或已完成状态下计入；其他类型仅在已付款或已完成状态下计入；待处理及任何未映射状态永不计数。取消订单始终优先排除订单，订单状态上的按状态覆盖规则可在其后生效。因此，将方式保留为未映射是一种审慎且保守的默认设置——在分类完成之前，这些订单不产生已实现的收入。此表格即是将支付方式映射到收入类型的方式（取消订单的情况除外）。
- ✓您商店中的方式——您的平台发送的精确支付方式字符串，例如来自 bizniweb。
- ✓类型——货到付款、银行转账、在线卡支付、钱包或其他，从变更时自动保存的下拉菜单中选择。
- ✓未映射，收入为零——与订单状态相同的故障保护机制，应用于配对的另一半。
- ✓谁可以编辑——所有者、管理员和编辑者可更改映射；成员和维护者可读；访客无访问权限。
- ✓完成闭环——状态加上支付方式类型最终决定订单是否计入收入（取消订单的情况除外）。
准备好查看实际计入收入的金额了吗？
Free check · 7-day trial · no credit card