Shopify履约请求已接受，为什么还要分别读请求状态与筛选类别？

Shopify开发文档把FulfillmentOrder定义为订单中预期由同一地点履约的一项或一组商品所对应的工作。[1] 同一订单在同一地点可以有多份这样的工作记录；订单路由后，系统自动生成并分配它们。本文关注的是这些工作与履约服务之间的请求状态，而不是把每份记录直接当成一个已经送达的包裹。

所读对象页的元数据版本是2026-10。其中，requestStatus字段写的是履约单的请求状态，另一个status字段写的是履约单状态。两项分别命名，意味着描述请求如何得到响应时，应保留requestStatus的对象。该页也将Fulfillment解释为进行中或已经完成的履约工作，与FulfillmentOrder所表达的预期工作相区分。

请求枚举来自明确标示2026-01的另一页。[2] UNSUBMITTED是新履约单的初始请求状态；未分配给履约服务的履约单，只有这一种有效请求状态。SUBMITTED表示商家已经提出履约请求。ACCEPTED与REJECTED分别表示履约服务接受、拒绝这一请求。由未提交到提交再到服务响应，文字记录的是双方围绕工作的交流，而非承运商运输轨迹。

取消请求另有三项名称。CANCELLATION_REQUESTED表示商家请求取消这份履约请求，CANCELLATION_ACCEPTED与CANCELLATION_REJECTED则分别表示服务接受或拒绝取消请求。这里的ACCEPTED附着在不同对象上：接受履约请求，与接受取消请求，不能只截取相同词尾便读成同一种进展。枚举还包含CLOSED，其定义是服务未完成工作就关闭履约单，因而关闭也不自动表示工作完成。

AssignmentStatus来自元数据为2026-10的筛选枚举页。[3] 它按四类描述可筛选的履约单：尚未请求、已请求、请求已接受，以及对先前已接受请求提出取消。官方在FULFILLMENT_ACCEPTED项特别说明，可以创建任意多个fulfillments来完成所请求的商品。因此，“请求被接受”与后续工作记录的数量不是一对一关系；这个名称首先限定筛选集合，不能据此把一份请求固定解释成一票货件。

对象页的几个时间字段又提供不同线索。createdAt是履约单创建的时间，fulfillAt是它将可履约的时间，fulfillBy则是其中全部商品需要完成履约的最晚时间。[1] 三项分别表达记录建立、可以履约和要求完成的时点。对资料整理而言，将它们都缩写成“日期”，会同时丢失时间所属的对象和先后条件；这些字段也没有在定义中给出顾客签收的证明。

订单身份仍需留在自己的范围内。orderName例如“#1001”，在单店订单页面承担标识作用，但文档明确说它跨多个商店并不唯一。orderProcessedAt记录订单处理时间，也可能不同于订单创建时间。于是，一份跨店履约资料除了请求原名，还需要保留相应商店背景与时间字段名称，才不会把相同显示号或相近时刻当成同一工作记录。本文采用上述两个版本的公开定义，网页首发日期均未另确认。