数据格式组装不对,你先用patchlisting试一下,先把组装数据调成功了,在使用feed批量上传
数据格式组装不对,你先用patchlisting试一下,先把组装数据调成功了,在使用feed批量上传
你用getListing拉取一下看看是不是5天。lead_time_to_ship_max_days或者有的订单是产生在设置之前。
确认设置没有问题了,观察新产生的订单是否正常。
我们之前和销售确认过,设置之后确实有用的
upc和item_type_keyword没有关系。和recommended_browse_nodes算是有点关系
UPC豁免是按照分类,或者分类类型来的。
8560,大概率是你upc豁免没有成功,或者豁免的分类和刊登的不是同一个分类。你检查一下
最好的办法,你叫销售,在店铺后台刊登看看是否可以成功。排除豁免问题
然后你用代码刊登,和他测试可以成功的用同一个分类,这样子可以减少很多干扰
先确认 AmazonOrderId 正确无误
用同一个 AmazonOrderId 同时调用 getOrderItems 和 getOrderItemsBuyerInfo,对比结果。
看下返回内容格式
是整个 OrderItems 为空,还是每个 OrderItem 里 OrderItemId 为 null?
可以发下你的返回示例,我帮你分析。 或者微信私聊我,发access_token,我帮你看看
商品处理时间?指的是等待发货的天数吗? 你试试这个字段 lead_time_to_ship_max_days
可以给一些具体的例子,请求示例和请求结果,方便看问题
你用getInboundOperationStatus 这个接口试一下
https://api.sp-api.net/zh/api-308930009
作用:用于查询某个异步操作的处理状态,例如货件的处理进度。
支持状态:返回的状态包括 IN_PROGRESS(处理中)、SUCCESS(成功)、FAILED(失败)。
适用场景:在发起创建、确认等异步操作后,调用此API可以获取操作的最新状态。
item_type_keyword 是用来唯一标识您的产品类型的属性,通常用于描述产品的类别或特定类型。它是一个字符串类型的参数,帮助系统理解您的商品属于哪个具体类别。
传参时,您需要提供符合该产品类别的关键词。例如,如果您的产品是电子产品中的手机,item_type_keyword 可能是 "smartphone";如果是服装,可能是 "t-shirt"。
比如:
'item_type_keyword' =>
array (
0 =>
array (
'value' => 'smartphone',
'marketplace_id' => 'ATVPDKIKX0DER',
)
),
GET_MERCHANT_LISTINGS_ALL_DATA
是CSV格式的。
确实有的报告是xml的,甚至是压缩包的
你需要根据,document reponse header部分解析这些,然后进一步处理
价格部分,你有传price吗,offer部分? 你发的json太长了,我没看到。
一般报价确实有两个情况:
你搜一下你传json的price
部分看看或者offer
估计是sellerId没有传,或者没传对。你检查试试
订单上传物流和修改物流的操作主要涉及到订单状态更新和运输信息的提交。
confirmShipment
接口,参数包括订单ID和物流信息(如物流公司、追踪号码等)。updateShipmentTrackingDetails
接口,参数包括运输计划ID、运输ID和新的追踪信息。具体参数信息如下:
confirmShipment
(订单确认发货)参数示例:
orderId
:订单IDshipmentDetails
:物流公司、追踪号码、发货时间等updateShipmentTrackingDetails
(更新运输追踪信息)接口路径:
/inbound/fba/2024-03-20/inboundPlans/{inboundPlanId}/shipments/{shipmentId}/trackingDetails
请求参数:
inboundPlanId
:入库计划IDshipmentId
:运输ID请求体(UpdateShipmentTrackingDetailsRequest
):
{
"trackingDetails": {
"spdTrackingDetail": {
"spdTrackingItems": [
{
"boxId": "FBAxxxxxxxxxxxxxxx",
"trackingId": "TRACKINGNUMBER"
}
]
}
}
}
参数说明:
boxId
:箱子ID(如果是小包)trackingId
:新的追踪号码总结:
confirmShipment
接口(订单API)updateShipmentTrackingDetails
接口(Inbound Shipment API)大概率原因是:sku一样,或者标题一样,或者upc一样(如果没有做UPC豁免)
建议:
**1. 避免重复提交相同商品信息:如果是在测试的时候,标题信息要做差异化。另外 sku也换成新的,避免原来有错误的干扰
feed的document大部分都是xml 或者json,不像报告。
你这是哪个feed的
应该是list_price相关的,你看看schema 里,有个字段,传个0好像就是没有。
这个就是那个schema里,实验一下可以在这里反馈一下,我给你进一步回复
问 使用 JSON_LISTINGS_FEED 修改sku价格解析文件结果报错