【WEBAPI】保存接口，实现采购订单-采购入库单关联的一些核心字段讲解（附测试JSON）

背景：

1. 下推接口：只能整单数量下推，无法灵活控制做到分批数量入库
   

2. 保存接口：与相应的上游单据关联，可以实现分批入库

3. 官方API交流QQ群：857982100
   

简单的JSON示例：

    以下是总结的采购入库单上比较核心的一些字段

    有时候用采购入库单保存接口来关联对应上游的采购订单【报错】或【没关联成功】或【没反写成功】

    就是字段错误赋值或格式不对或不满足业务

{
  "Model": {
    "FID": 0,
    "FBillNo": "",
    "FBillTypeID": {
      "FNUMBER": "RKD01_SYS"
    },
    "FBUSINESSTYPE": "CG",
    "FStockOrgId": {
      "FNumber": "100"
    },
    "FPurchaseOrgId": {
      "FNumber": "100"
    },
    "FSupplierId": {
      "FNumber": "051101"
    },
    "FDATE": "2022-05-26",
    "FInStockEntry": [
      {
        "FMaterialID": {
          "FNumber": 0.001
        },
        "FStockId": {
          "FNumber": "0.001"
        },
        "FRealQty": 1,
        "FTAXPRICE": "¥3.330000",
        "FPOOrderNo": "CGDD002542",
        "FPOORDERENTRYID": "296025",
        "FSRCBILLTYPEID": "PUR_PurchaseOrder",
        "FSrcBillNo": "CGDD002542",
        "FInStockEntry_Link": [
          {
            "FInStockEntry_Link_FRuleId": "PUR_PurchaseOrder-STK_InStock",
            "FInStockEntry_Link_FSTableName": "t_PUR_POOrderEntry",
            "FInStockEntry_Link_FSBillId": "295517",
            "FInStockEntry_Link_FSId": "296025",
             --"FInStockEntry_Link_FRemainInStockBaseQtyOld":1,
	         --"FInStockEntry_Link_FRemainInStockBaseQty":1, 
	        --"FInStockEntry_Link_FBaseUnitQtyOld":1, 
	        --"FInStockEntry_Link_FBaseUnitQty"：1
          }
        ]
      }
    ]
  }
}

下面一个个来解释：

【FID】：单据的唯一ID

            存数据库一般不显露出来，点击保存时自动生成，可以不给值

【FBILLNO】：单据编码

            可以自己手工赋值，也可以保存的时候让它自动生成

【FBILLTYPEID】:单据类型的编码

            不要直接填中文，一般是固定值，可以在系统的单据类型列表里找到对应的值，如：JSON中的RKD01_SYS，就是标准入库单的意思                

【FBUSINESSTYPE】：业务类型

            很多人忘填，一般不填系统就默认是标准采购

            但是呢，我们有时候是要切换为委外采购入库单，这时候如果你任由系统默认赋值标准采购，那就会报错的，一般是要和单据类型一对应起来的。

        其对应的值，可以在BOSIDE的采购入库单中找到，如：上面JSON中的"CG",代表标准采购的意思。委外入库单的话就要改成"WW"了，需要注意的是字母要全大写

【FStockOrgId】：收料组织的编码

【FPurchaseOrgId】：采购组织的编码

【FSupplierId】：供应商的编码

【FDATAE】:日期字段

 以上字段，单据上做个单子点开来就看得到了，看着业务来填就好

这里延申出两个问题：

1）顺序先后问题，【收料组织】字段的赋值要先于【供应商】字段

        假如你先给供应商赋值，再来给收料组织赋值，供应商也会被刷新清空。

组织>供应商

        系统的设定是你切换了组织，整个单据界面都要刷新清空一遍，这个在单据做单的时候，前端效果很容易的体现出来，但是用JSON接口做单赋值时，就很容易看不出来了。这里也是要注意的。

2）顺序没问题，填充了为啥还时提示我供应商必填？

        这时要考虑JSON赋值的供应商编码在当前收料组织里选的到么？

        本身选不到的话还强行赋值，就会被清空。JSON保存的时候就会提示：供应商必填！其实就是没注意到这个细节！

        供应商里面有一列【使用组织】，这里的供应商是被收料组织过滤，不在这个组织下的供应商，赋值是不会成功的

明细体（FInStockEntry）字段：

【FMaterialID】：物料的编码    

            但是和供应商的道理一样，不要把组织的赋值放到物料之后，也不要赋值这个组织下选不到的物料，不然JSON里统统会报错：物料必填！

【FStockId】：仓库的编码

            这里呢也是要注意的是，不要把仓库字段的赋值排到物料之前，各位可以去单据里录数据试试

            先录物料再录仓库是正常的，而你先录仓库再录物料，会发现仓库被清空了，JOSN这里的赋值是一个道理

【FRealQty】：实收数量

【FTAXPRICE】：含税单价

【FPOOrderNo】：订单编号

        这个值填充的是上游的采购订单单据编号，对后续的业务有用

        【采购订单-采购入库单】下推做单过程中，系统单据转换会自动赋值携带到采购入库单上，不用手工赋值。

         但现在因为是用保存接口，用JSON赋值的方式来构建采购入库单并且关联上游采购订单，这里就需要我们自己填充了，系统也没办法自动赋值。

        举个例子：如果是委外采购入库单，采购入库单的保存校验就要校验这个字段，没填充的话，就会报错：委外业务类型的入库单必须有来源委外订单！

【FPOORDERENTRYID】：采购订单明细行的分录ID

【FSRCBILLTYPEID】：源单类型

            用于指明上游是啥单据。这里是采购订单，所以赋值：PUR_PurchaseOrder（采购订单的唯一标识）

【FSrcBillNo】：源单编号

            用于指明上游的单据编号，这里时填充采购订单的单据编号

1）这里源单编号和订单编号有啥区别？

            如果是从采购订单直接推下来的采购入库单，确实没啥区别，赋值是一样的

            但是，采购入库单可能是【采购订单->收料通知单->采购入库单】这个流程

            这个时候FSrcBillNo就要填充的是收料通知单的编号了

2）源单类型和源单编号这两字段很重要

            如：【采购订单-采购入库单】的反写规则要触发，是靠【源单类型】这个字段来判断的，否则会影响后续的订单上累计入库数量等数据的刷新

明细关联体（FInStockEntry_LINK）里的字段：

【FInStockEntry_Link_FRuleId: PUR_PurchaseOrder-STK_InStock】：

指明是从哪张单据到哪张单据的意思，是固定值。PUR_PurchaseOrder：采购订单。STK_InStock：采购入库单。

【FInStockEntry_Link_FSTableName: t_PUR_POOrderEntry】：

指明上游单据明细体的数据库表名，t_PUR_POOrderEntry，就是采购订单的明细体的那张表，固定值不需要额外查询。

【FInStockEntry_Link_FSBillId】：这个值填充的是上游单据的FID值

【FInStockEntry_Link_FSId】:  这个值填充的是上游单据明细体的分录ID，说白了就是t_PUR_POOrderEntry这张分录表里面，字段名为[FENTRYID]的值

以下这几个值对应的控制来源：

FInStockEntry_Link_FRemainInStockBaseQtyOld（库存基本数量OLD）

FInStockEntry_Link_FRemainInStockBaseQty（库存基本数量）

FInStockEntry_Link_FBaseUnitQtyOld（采购基本数量OLD）

FInStockEntry_Link_FBaseUnitQty（采购基本数量）

对于这几个字段的理解可以参考帖子：请教一个字段的含义 (kingdee.com)

关于 FxxxEntity_Link_FBaseQtyOld、FxxxEntity_Link_FBaseQty 的填写说明： 

反写，是以反写公式中的字段为准的（通常是单据体上的基本单位数量） 

如果没有合并下推，那么Link表中，这两个字段不重要，填写与否，并不影响什么 

如果是合并下推，则需要把单据体行中的反写字段值，进行分配

按照其原始携带的值，反写到多个源单上去 这两个字段，就是在合并下推时，作为反写分配依据

大概原理： 

假设，a1(100个) + a2(200个) + a3(300个)，合并下推b1，自动携带600个

用户手工修改为700个（原始携带与实际反写量，不一致了） 

保存时，单据体基本单位数量为700， Link子表，有三行记录：

 1. sid = a1, baseQtyOld = 100, baseQty = 100; 

2. sid = a2, baseQtyOld = 200, baseQty = 200; 

3. sid = a3, baseQtyOld = 300, baseQty = 300; 

反写引擎，会发现单据体基本单位数量与原始携带量不一致，反写的时候，需要重新分配（自上而下） 

此时，分配的依据，就是link_baseQtyOld的值，重新分配后

 Link子表中的内容：

 1. sid = a1, baseQtyOld = 100, baseQty = 100;

 2. sid = a2, baseQtyOld = 200, baseQty = 200; 

3. sid = a3, baseQtyOld = 300, baseQty = 400; 

如上，反写分配的过程，会更新Link_BaseQty字段值因此，Web API参数中，这个字段，可以不填

而Link_FBaseQtyOld字段，则是重新分配的依据，如果是合并下推，这个字段必填

怎么利用查询接口查出相关上游单据的字段信息：

查询JSON：

{
  "FormId": "PUR_PurchaseOrder",
  "FieldKeys": "FBILLNO,FID,FPOOrderEntry_FEntryid",
  "FilterString": "FBILLNO='CGDD002542'",
  "OrderString": "",
  "TopRowCount": 0,
  "StartRow": 0,
  "Limit": 0,
  "SubSystemId": ""
}

我这里查的是JSON例子中的CGDD002542这种采购订单的相关值，查询结果截图：

        FBILLNO：CGDD002542，这个值就填充到了FPOOrderNo和FSrcBillNo

        FID：295517，这个值就填充到了FInStockEntry_Link_FSBillId

        FPOOrderEntry_FEntryid：296025，这个值就填充到了FPOORDERENTRYID和FInStockEntry_Link_FSId

后续有问题，欢迎留言，会持续的补充！

相关知识：

API文档-API中心 (kingdee.com)

WebAPI如何查询单据体分录内码 (kingdee.com)

WebApi查询接口 (kingdee.com)

金蝶云星空 WebAPI接口说明书_V5.0 (kingdee.com)

webapi保存接口带关联数据包 (kingdee.com)

WebApi 对接的疑难杂症 (kingdee.com)