本文讨论了在使用第三方系统通过WebAPI与K3 Cloud系统进行数据交互时,如何处理和更新单据数据。文中指出,第三方在保存数据时应记录K3 Cloud返回的单据主键内码及分录行内码,以便后续更新。同时,还详细说明了如何通过“单据查询接口”查询单据体的分录内码、序号及基础资料属性,并解释了请求参数的构造方式,包括单据业务对象标识、过滤条件、以及特定字段标识的使用,如基础资料字段的引用属性查询方法。
业务场景:
一般第三方可以通过WebAPI保存接口,全新保存一条数据,
当第三方系统单据有变化后,
还需要对K3 Cloud系统里已经保存的单据数据做更新处理,
比较好的做法是在第三方在第一次调用保存接口时,
就把K3 Cloud成功保存的单据主键内码及分录行内码的返回结果都记录到第三方系统中(下次用记录的内码做更新),
但也不保证第三方只记录了单据主键内码(因为单据主键内码是默认返回的),
或者第三方单据主键都没有记录,
此时,第三方在新一次数据更新时,
要先获取到已经保存到K3 Cloud这边的主键及分录内码,
根据拿到的内码在做到K3 Cloud这边的单据及分录行数据更新处理。
查询调用接口 WebAPI“单据查询接口”,
需求:查询单据体分录内码、序号、基础资料属性,
对于单据上直接拖入添加的字段,我们知道“单据查询接口”直接写字段标识就可以查询到,
那么对于不是我们直接拖入的字段,
如单据体的分录内码、序号或者是单据上引用的基础资料的字段的属性该怎么查询到呢?
如想了解,可以往下看,
如图有一张【销售出库单】,编码为“XSCKD000001”
我们直接通过 WebAPI的“在线测试WebAPI”拿到的此张单据的查询结果。
既然结果已经拿到了,那么我们的参数构造的规范是怎么样的呢?
继续往下看,
参数构造解析:
请求参数:
[code]{\"FormId\":\"SAL_OUTSTOCK\",\"FieldKeys\":\"FID,FBILLNO,FEntity_FENTRYID,FEntity_FSeq,FMaterialID,FMaterialName,FMaterialID.FName,FMaterialID.FStockId\",\"FilterString\":\"FBILLNO = 'XSCKD000001'\",\"OrderString\":\"\",\"TopRowCount\":\"0\",\"StartRow\":\"0\",\"Limit\":\"0[/code]
"FormId":"SAL_OUTSTOCK" SAL_OUTSTOCK 为【销售出库单】的业务对象标识。
"FilterString":"FBILLNO = 'XSCKD000001'" FBILLNO = 'XSCKD000001'是按单据编号进行过滤的条件。
重点是这里:
"FieldKeys":"FID,FBILLNO,FEntity_FENTRYID,FEntity_FSeq,FMaterialID,FMaterialName,FMaterialID.FName,FMaterialID.FStockId"
FID:这个我们知道是单据内码主键
FBILLNO:这个我们也知道是“单据编号”字段标识
FEntity_FENTRYID:这个就是单据体分录行内码
FEntity_FSeq:这个是单据体的分录行序号
FMaterialID:单据体的物料字段
FMaterialName:单据体的基础资料属性类型的物料名称字段标识
FMaterialID.FName:物料名称另一种的查询方式 基础资料字段.引用属性字段名(后面会做解释)
FMaterialID.FStockId:查询仓库 基础资料字段.引用属性字段名
这里,小伙伴可能会有疑问 单据体的分录内码查询 为什么会是 FEntity_FENTRYID?
这里是有依据的,如下截图可以看到,
【销售出库单】的单据体标识为 FEntity ,“分录主键标识”为 FENTRYID,取数规范也就是 [单据体标识]_[分录主键标识]。
序号也是类似规范 【销售出库单】的单据体“序号字段标识”为 FSeq[单据体标识]_[序号字段标识]
基础资料属性如果界面上有的直接使用配置的属性即可,
如物料名称,
其实这里也可获取到界面上没有配置的基础资料属性,也就是这一种写法 基础资料字段.属性字段名,
那么这里是不是基础资料的所有字段都可以这样去写呢?
答案是 不是的,是已经加在基础资料字段的“引用属性”中的才可以这样写,
可以看到【销售出库单】,单据体中的物料已经添加的引用属性,
也就是前面我们获取物料的仓库为什么可以这样写 FMaterialID.FStockId,
其实这里的规范是这样的 基础资料字段.引用属性字段名
the end
thank u!
推荐阅读