新建【用户管理】，维护用户的基本信息，本身需有添加功能，登录功能的用户数据就来源于此。 登录功能这边需要有用户名、密码和验证码，登录后数据与【用户管理】校验，成功即可进入系统。 有多个系统使用一个登录功能，进入后到系统导航，点击每个子系统又可以进入，登录可保持24h有效，子系统4h有效。 注册功能填写的数据，需要同步到【用户管理】，包括重置密码这些也需要更改【用户管理】的信息。

1. 授权开发者账号 首先要在Amazon的卖家中心将需要拉取库存数据的账号授权绑定开发者账号，也就是店铺授权。 这里有两种方法： 可以直接登录卖家中心，一步步去操作，Setting -> User Permissions，点击“Authorize New developer”按，填写授权内容即可 自己系统做功能，也就是在自己的系统已经做好了一个授权菜单，里面的操作也已处理好，在里面添加Amazon的账号信息，登录即可 两者都可以，我们后面开个详细的文章说下，要注意防关联！！！ 2. 确定SP-API接口 FBA Manage Inventory，找到对应的SP-API的接口，可以参考开发者文档。 https://developer-docs.amazon.com/ 在里面搜索FBA Manage Inventory就可以找到。 reportType value：GET_FBA_MYI_UNSUPPRESSED_INVENTORY_DATA 同时也可以看下后台路径，方便拉取数据后去后台下载报表核对：报告>配送>库存>管理亚马逊库存。 3. 设置定时任务 因为是即时库存，理论上讲这个定时任务频次越高、间隔时间越短说明数据越准确。但是你要考虑到账号数量和库存数据量，服务器的性能等。 我们假设按每一小时获取一次，定时任务该这样写：新建定时任务，每天通过接口获取，从0点开始，每一小时执行一次，获取数据后按日期覆盖。 因为一天会获取24次，可以每天只保留一份最新的库存，如果要求高，要查看小时库存变化，也可以把时间精确到小时，全部保留即可，一般建议每天留一份最新的就好。 4. 获取字段 sku fnsku asin product-name condition your-price mfn-listing-exists mfn-fulfillable-quantity afn-listing-exists afn-warehouse-quantity afn-fulfillable-quantity afn-fulfillable-quantity-local afn-fulfillable-quantity-remote afn-unsellable-quantity afn-reserved-quantity afn-total-quantity per-unit-volume afn-inbound-working-quantity afn-inbound-shipped-quantity afn-inbound-receiving-quantity 加粗的这几个字段用的比较多，fnsku是FBA的产品编码唯一标识，其他几个都是库存字段，可用库存、预留库存、在途库存、接收中库存，一般我们自己计算FBA的总库存，习惯于用这六个合计。 afn-fulfillable-quantity-local和afn-fulfillable-quantity-remote的合计是afn-fulfillable-quantity，而且只有欧洲才有这俩字段，有段时间afn-fulfillable-quantity没值了，现在又有了，说明强如Amazon的产品功能设计有些时候也是乱的。 5. 关联字段 关联字段就是根据拉到的字段关联出另外一些我们需要的字段。 公司产品信息：根据fnsku或者sku关联我们自己的系统维护的数据 站点：根据fnsku关联 总库存：自己定义的几个字段合计 账号所属公司：可以根据账号关联出所属公司，定义库存所属 单价/金额：可以根据公司产品编码关联财务成本单价，计算库存金额 上架日期：可以按某一些库存从0变为1的那一刻定为上架日期 …… 6. 建立菜单 拉取数据后需要在界面展示，菜单简单一些就好，正常的web端表单菜单，有一些查询、重置、导出按钮，有一些查询条件就够了。 这里可以有两个菜单，一个是即时库存，只保留最新数据；另一个是历史库存，就是多了时间维度，因为有历史库存，我们可以分析库存变化，做可视化数据展示。 7. 其他注意事项 区域是共享库存的，要注意不要拉重了，比如欧洲、北美，这些站点比较多的。 墨西哥的库存因为时间的原因，我们最新只能获取两天前的，也就是我们的时间是当天，实际上墨西哥的库存是前天的，就跟因为时差原因，欧洲和美国是昨天的一样。 服务器方面，因为拉取国外的数据，购买个海外服务器要快很多，比如美西服务器，通过这个服务器拉取数据，脚本任务都在这上面，数据清洗后同步到国内服务器做功能界面展示。 综合带宽成本和效率，内部系统服务器的带宽不建议用固定带宽，用流量包就好，会很快，相对量成本低很多，不过你要是数据量超级多，比如SaaS软件的，可以考虑固定带宽。

01 设计原则 付款报销的设计需要考虑的点蛮多的，需要有以下几个原则： 通用：这个是给全公司用的，通用性需要强，适配所有部门、类型和各类场景 简单：交互、操作都需要简单，付款报销功能，几乎所有人都会用，你如果设计的很复杂，用户体验就很低了 审核：这套流程是需要审核的，不管是自己部门领导还是财务那边，都要规划好，多少人审，根据什么原则审 提醒：对于这个单子到了哪一阶段了，需要及时提醒给相关人员，是否需要关联短信、钉钉还是邮件等 移动：可以快速审核的，需要搭建移动端，类似于第3点，最好是有 账务：里面的数据需要适应财务的账务处理 02 整体方案 新建菜单，通用的添加、编辑、删除和审核这些，添加数据后需要更新审核状态，并根据规则提醒对应审核人，审核人操作后状态更新，最后到付款完结。 部门信息需要关联【员工信息管理】和【部门管理】，提醒功能需要关联钉钉、*或者邮件等，移动端审核也需要注意。 菜单需要支持打印功能，数据导出需要合乎财务账目。 需要有附件上传功能，针对附件需要下载和预览。 审核流需要显示出来，让大家清晰知道自己的单据该找谁审核。