自动锁库解锁服务简介原创
金蝶云社区-angen
angen
46人赞赏了该文章 9,385次浏览 未经作者许可,禁止转载编辑于2023年03月07日 13:41:19
summary-icon摘要由AI智能服务提供

金蝶云星空PT-146906 8.0.0.202203版本添加了自动锁库解锁服务,支持发货通知单、直接调拨单、销售出库单等单据的锁库与解锁功能,需客户按需启用。服务通过锁库/解锁类型下拉框控制,配置包括库存匹配维度、是否允许部分锁库等。日志记录服务操作详情,但存在与预留等服务的冲突、特定操作不支持锁库等问题,需客户注意。后续版本将修复BUG,增强功能,如支持按辅单位锁库、插件干预锁库逻辑等。

    在金蝶云星空版本 PT-146906 [8.0.0.202203](构建号:8.0.186.8,发布时间2022.3.31) 中,应相关客户提单需求,添加了自动锁库解锁服务,本服务通版默认在发货通知单中的审核(审核时锁库自身单据),反审核,作废(反审核时或作废时解锁自身单据),直接调拨单中的审核(审核时先解锁上游发货通知单锁库信息再锁库自身单据),反审核,作废(反审核时或作废时解锁自身单据),销售出库单的审核(审核时解锁上游发货通知单和直接调拨单锁库信息)操作上已经配置好了,但默认都没有启用,客户可根据需要成对启用(这里建议客户要成对启用,比如发货通知单审核操作上启用了锁库,那么反审核,作废操作上就要启用解锁),也可以参照类似的配置应用到其它二开单据上。本服务将锁库和解锁功能集成在一起,通过'锁库/解锁类型'下拉框 动态地启用或禁用相关控件,锁库的服务配置如下图1-1所示:

image.png

图1-1


    在上图中,1,左侧为库存匹配维度字段设定,必选字段在锁库时必须配置,如果维度配置了,且对应单据在相关维度上有值,则为精确匹配。举个例子,假设发货通知单审核操作挂了自动锁库服务,其配置界面把仓库维度设定为发货通知单的出货仓库,那么如果发货通知单的出货仓库为仓库甲,且即时库存有仓库甲的数据,则锁库能够锁成功(其它维度也要对应),如果即时库存没有仓库甲的数据(但有其它仓库的数据),则锁库不成功;2,右上角的配置在锁库时仅显示和启用复先框'允许部分锁库',其它三个配置'解锁上游单据','上游单据体标识','下游单据体标识'不可用(后面会解析其作用),勾选'允许部分锁库',则在库存量不足时可部分锁库,不勾选时则锁库不成功;3,右下角的配置用于设置锁库标识和数量相关字段(这些字段可以不用填写),即锁库成功后,对应的锁库标识,锁库数量,待锁库数量 字段会更新。

解锁的服务配置如下图1-2所示:

image.png

图1-2


    上图中配置的解锁服务中,1,左侧的'库存匹配维度字段设定'会多显示一列'解锁严格匹配'配置,此列用于在下游单据操作上配置解锁上游单据的锁库信息时是否严格匹配相关维度,如果是解锁自身单据,则解锁严格匹配字段配置就没有作用。举个例子,假设发货通知单上锁了甲仓,发货通知单下推销售出库单时如果将销售出库单上的仓库修改为乙仓,那么在销售出库单审核操作上挂的解锁发货通知单上的锁库信息时,如果解锁严格匹配仓库字段,那么就解锁不了,因为仓库不一样,建议根据需要解锁时按仓库和数量严格匹配,默认通版是按下游的真实数量解锁上游,因此基本单位数量是解锁严格匹配的,举个例子,发货通知单锁库了10个,但是出库时只出了3个数量,那么销售出库单审核时只会解锁发货通知单上的3个数量的锁库信息;2,右上角的配置在解锁时三个字段可以配置,'解锁上游单据'可以配置下游单据上的某个操作解锁上游锁库信息(目前仅支持解锁上游单据为供应链和制造领域的单据),当然这里也可以配置成解锁自身单据的锁库信息(可以为空不填,为空时就代表解锁自身单据);3,右下角的锁库标识和锁库数量是依据解锁上游单据上的字段而不一定是本单据上的字段。

    发货通知单的审核操作配置的服务如下图2-1所示:

image.png

图2-1


    发货通知单上的反审核及作废操作配置如下图2-2和图2-3所示:

image.png

图2-2


image.png

 图2-3


    直接调拨单上的审核操作配置的服务如下图3-1所示:

image.png

图3-1


    上图3-1中解锁上游发货通知单上的维度大部分取至调出维度,比如调出仓库,调出BOM等,而自身锁库时大部分取至调拨单上的调入维度,直接调拨单上的反审核及作废操作配置如下图3-2和图3-3所示:

image.png

图3-2


image.png

图3-3


    销售出库单上的审核操作配置了两个解锁上游单据服务,分别用于解锁发货通知单和直接调拨单,此服务要放到预留关系释放服务之前如下图4-1所示:

image.png

图4-1


    注1:上面所有单据的服务配置中的,有个上游单据体标识和下游单据体标识,这两个字段仅在下游解锁上游且满足特定的条件才需要配置,通版默认都没有配置值,这是可行的,提供此参数主要是为了兼容二开单据或通版多个下游单据的上游单据。举个例子,销售订单作为上游单据时,可能存在使用销售订单上的明细信息下推发货通知单,也可能存在使用销售订单上的收款计划下推收款单,这时 T_BF_TABLEDEFINE 对于FFORMID为 SAL_SaleOrder 时就有多个记录,FTABLENUMBER 分别为 T_SAL_ORDERENTRY 和 T_SAL_ORDERPLAN,如果要在下游解锁上游销售订单上的锁库信息时,就需要提供表T_BF_TABLEDEFINE  中 FENTITYKEY 列对应的值,比如收款单审核时解锁上游销售订单上的锁库信息时需要提供上游单据体标识值:FSaleOrderPlan,如果是发货通知单审核时要解锁上游销售订单上的锁库信息时需要提供上游单据体标识值:FSaleOrderEntry,当然由于通版在销售订单上已经存在了自动锁库功能,且在销售出库单审核时会自动释放销售订单上锁库信息,因此没有必须去销售订单上配置此服务或下游配置解锁销售订单上的服务,这里只是举个例子,如果客户二开的单据或扩展通版单据遇到 T_BF_TABLEDEFINE 表有多个记录时则需要在解锁上游单据时对应地配置好这两个字段,如果上下游单据在表 T_BF_TABLEDEFINE  只有一个记录,则可以不用配置这两个字段,表中的数据试例如下4-2所示:

image.png

图4-2


    锁库日志记录了此服务对应的一些详细信息,通过需求备注和解锁备注字段可以大致看出一些操作细节,如下图4-3所示:

image.png

图4-3


存在的问题:

    1,由于服务内部执行顺序的特殊性,在操作中配置的服务顺序不完全等于其真实执行顺序, 因此本服务可能存在与其它服务(比如库存更新搜集服务, 负库存检查服务,预留关系转换服务,预留关系释放服务)有冲突的情况。举个例子,由于锁库和预留共用同一套表结构,锁库时可能存在与预留有冲突。目前通版销售订单可能存在MRP运算产生预留或锁库信息,因此通版在发货通知单审核时,如果在发货通知单上启用了自动锁库服务,且发货通知单上的上游销售订单如果已经存在预留或锁库信息,则发货通知单上也不会锁库。如果销售订单没有MRP运算产生的预留或锁库信息,则发货通知单就会锁库成功,但如果发货通知单上锁库成功后在销售订单上又再做MRP运算导致订单上有预留则会存在多锁库的情况,客户应当留意并避免或者手工去库存锁库列表中解锁。另外本服务解锁时可能存在与预留关系释放服务有冲突的问题,二开配置时需要客户自行决定启用哪个服务。以销售订单->发货通知单->销售出库单为例(订单不锁库,发货通知锁库,出库单解锁库存且释放预留),预留是认为MRP需求单据才存在预留的,在发货通知单锁库后,预留释放服务无法感知(如果发货通知单是销售订单下推的,通知单下推销售出库,预留服务是以销售订单出库的,会释放销售订单预留,但是无法释放通知单的;如果手工新增的发货通知单为源头单据,预留找不到源单就直接以通知单出库了,这时会释放通知单的预留,所以要是在销售出库单审核操作启用了解锁上游发货通知单的服务,则应停用预留关系释放服务)。

    2,发货通知单列表中的'变更数量'操作由于其特殊性(它是一个空操作,在插件中使用了模拟View更新数量),且其中的变更数量校验逻辑是写在列表插件中的AfterDoOperation方法中,此操作目前不建议在上面配置解锁或锁库服务(如果强制配置解锁或锁库操作,可能导致变更数量校验失败,但是却解锁了),建议通过在单据菜单或列表上重新挂一个空操作菜单并在空操作的服务端服务上配置自动锁库解锁服务(后续通版有计划兼容变更数量逻辑)。

    3,下游操作解锁上游锁库信息时,目前配置界面上的解锁上游单据字段默认只能是供应链和制造领域的单据,如果是其它领域的单据,则需要手工输入单据的formId值(BOSIDE 中单据的唯一标识,注意不能是单据的名称)。另外如果是上游合并下推到下游单据,则下游单据解锁上游锁库信息时可能会多解锁。

    4,锁库或解锁时物料,数量,单位等是必录字段且必须在分录(即单据体上的字段,如果是子单据体上的字段,可能会导致下游解锁上游不成功)上。锁库操作会排除已经锁库的数量,比如在发货通知单保存操作上配置了锁库,则首次保存一次操作,会锁库一次,后续再点保存,会排除此发货通知单已经锁库的记录,因此如果数量不变后再次保存时不会再锁库。当两个保存操作数量有差异时,只有数量变大后的保存会再次锁库增量,数量变小后不会改变上次锁库数量。

    5,本服务目前版本不会对操作结果进行干预,也不会对锁库结果进行提示,比如某个单据审核操作上挂了锁库服务,但是可以能因为库存可用量不足导致锁库失败,那么即使锁库失败了也不会影响审核操作,也不会提示锁库失败了,如果要查看锁库失败原因,则需要启用下文中的日志文件功能。


日志文件启用功能简介:

    如果发现锁库服务没有按预想的执行,可以向对应账套数据库中添加相应脚本清除以BAS_SYSTEMPROFILE_CONFIG_开头的缓存(此脚本建议仅用于分析,如果分析没有问题后建议删除此脚本对应的记录以精减日志文件大小)

INSERT INTO T_BAS_SYSTEMPROFILE(FCATEGORY,FORGID,FACCOUNTBOOKID,FKEY,FVALUE,FACCTPOLICYID,FACCTSYSTEMID) VALUES('SAL',0,0,'AutoLockStkLog','TRUE',0,0);

    通版在有上面的脚本时会在日志文件中记录详细信息, 可以在日志文件(日志文件通常在金蝶云星空安装目录:X:\Program Files (x86)\Kingdee\K3Cloud\WebSite\App_Data\Log )中通过关键字 AutoLockOrUnlockStockService Log Msg 搜索,如下图5-1所示:

image.png

图5-1


提单分析及解决方案:

    1,库存锁库列表不显示某些单据的锁库信息,这个是因为通版添加的自动锁库解锁服务只显示了销售订单,发货通知单,直接调拨单等,此问题可以通过修改 视图 V_PLN_LOCKSTOCK来实现(在视图最后的 OR T1.FDEMANDFORMID IN ('STK_Inventory', 'SAL_SaleOrder') 从句中 添加需要的单据即可),或者升级补丁至2022.08月版本。

    2,有客户提单反馈下游某个操作时解锁上游单据不成功,如果通过上面的日志文件发现记录有类似以下日志:无流程数据,上游表[XXXX], 下游表[YYYY,ZZZZ](其中的XXXX,YYYY,ZZZZ分别代表上游表,下游表,下游单据体标识),则说明二开的流程与通版有冲突,需要在解锁服务配置界面中配置好上下游单据体标识(参看上文中注1的内容)。

    3,如果客户在上游某个单据上按批号锁库,下推到下游时有批号拣货服务且想严格按锁库的批号携带下去,则需要按类似如下的脚本配置(本试例以SQL Server数据库中的发货通知单为例 ,如果是Oracle则需要类似地分别向表T_STK_LOTPICKRESERVESET 和 T_STK_LOTPICKRESERVESETETY 中添加对应的记录):

DECLARE @MAXID INT; 
 SELECT @MAXID = MAX(FID) + 1
FROM T_STK_LOTPICKRESERVESET; 
 IF(@MAXID <= 100000) 
BEGIN 
 SET @MAXID = 100001; 
END 
INSERT INTO T_STK_LOTPICKRESERVESET(FID, FOUTSTOCKFORMID, FSRCFORMID, FRESERVEDEMANDFORMID, FISSYSSET, FISFORCERESERVEPICK)
VALUES(@MAXID, 'SAL_OUTSTOCK', 'SAL_DELIVERYNOTICE', 'SAL_DELIVERYNOTICE', '0', '1'); 

 INSERT INTO T_STK_LOTPICKRESERVESETETY(FENTRYID, FID, FSEQ, FCURRENTFORMID, FENTRYIDFIELDNAME, FLINKTABLENAME, FSOURCEFORMID, FRULEID)
VALUES((SELECT MAX(FENTRYID) + 1 FROM T_STK_LOTPICKRESERVESETETY), @MAXID, 1, 'SAL_OUTSTOCK','FENTRYID','T_SAL_OUTSTOCKENTRY_LK','SAL_DELIVERYNOTICE','DeliveryNotice-OutStock' );

这里要注意下,由于默认情况下T_STK_LOTPICKRESERVESET表中就有销售订单(需求单据)->发货通知单->销售出库单的记录(FID = 1002的记录),因此如果添加了发货通知单做为需求单据,则可能与FID = 1002的记录有冲突,依然会导致批号检货不能优先读取发货通知单上的锁库信息,此时如果仅使用发货通知单锁库,不使用销售订单锁库的话可以删除 FID = 1002的默认记录。详情可参考论坛:https://vip.kingdee.com/article/310734971575254272?productLineId=1 。

    4,有些客户提单反馈明明有即时库存,但就是没有锁库成功,这种有可能是锁库服务中配置的基本单位数量对应的单据字段数量为0。

    5,有些客户提单反馈在菜单'供应链->库存管理->库存锁库->锁库日志'列表中有锁库日志,但没有解锁日志,通过库存锁库列表又发现没有了锁库信息,这种情况可能与预留关系释放服务或预留关系转换服务有冲突(由于一些特殊原因,预留释放不记录日志),建议客户评估后只启用其中的一项即可。

    6,当下游单据上的某个操作要解锁上游单据的锁库信息时如果上游一条分录对应多条下游分录时可能存在少解锁数量的问题(比如发货通知单仅有一条数量为50的分录锁库了,但下推出单时由于批号拣货导致出库单上分录有三条,数量分别为10,15,25),此问题在2022年8月补丁中已修复。

    7,如果客户自行二开单据转换流程且使用了上游子单据体下推下游单据,比如使用组装拆卸单中的子件表(子件表是子单据体)而不是成品表(成品表是单据体)下推其他出库单,那么上游组装拆卸单支持'子件表'的锁库(锁库信息中会保存子单据体的FDETAILID字段信息,但是没有保存单据体的FENTRYID字段信息),但是不支持下游其他出库单解锁上游组装拆卸单,这是因为平台的流程表(T_BF_INSTANCEENTRY)和下游的Link表(比如其他出库单的T_STK_MISDELIVERYENTRY_LK)都是只记录了源表名为上游单据的单据体对应的表,源ID也仅有FENTRYID,没有FDETAILID,不会记录子单据体对应的表,建议不要使用子单据体锁库或解锁。

    8,如果保管者类型为客户或供应商且被分配到其它组织后(假设为组织A),在组织A为主业务组织前提下做的单据,会锁库不成功,此为新发现的问题,目前通版预计将在后一版本(2023年1月)兼容处理,如果客户有二开且服务器环境在本地且等不及通版补丁,可参阅论坛地址:https://vip.kingdee.com/article/168094586567723776?productLineId=1 类似地通过dnSpy反编译并修改应用程序集 Kingdee.K3.SCM.App.Core.dll 中的类 AutoLockOrUnlockStockService(此类的命名空间为Kingdee.K3.SCM.App.Core.AppBusinessService)中的方法 GetValue,如下图6-1所示:

image.png

图6-1


    9,自动锁库解锁服务报 '将截断字符串或二进制数据 语句已终止',其中的Sql语句为:INSERT INTO T_STK_LOCKSTOCKLOG .... (此处省略)。此问题通常是单据标识过长导致的,可升级到2023年1月补丁,或者通过修改表 T_STK_LOCKSTOCKLOG 中的FLOCKTYPE字段长度,语句如下:

--TO SQL SERVER(SQL SERVER脚本): 

    EXEC p_AlterColumn 'T_STK_LOCKSTOCKLOG', 'FLOCKTYPE', 'VARCHAR(36)', 'NOT NULL', '0100', ''' ''' 

--TO ORACLE(Oracle脚本): 

    CALL p_AlterColumn ('T_STK_LOCKSTOCKLOG', 'FLOCKTYPE', 'VARCHAR(36)', 'NOT NULL', '0100', ''' ''')


    10,销售模块下的单据,一但上游有销售订单锁库或预留了即时库库存,则同一流程下的下游是不会锁库的,举个例子,当销售订单锁库后,下推发货通知单,即使发货通知单审核操作上挂了自动锁库服务,发货通知单审核时也不会锁库,同理如果有流程 销售订单->发货通知单->销售出库单,当销售订单锁库后,且在销售出库单上挂了锁库服务,则下游出库单也不会锁。


版本更新记录:

    1,2022年8月版本,修复若干BUG, 支持严格按辅单位锁库,条件控制哪些分录参与锁库,库存锁库列表支持第三方单据显示锁库信息。

    2,预计将在2023年1月支持插件干预锁库逻辑(此功能需要客户有二次开发人员),可参考:https://vip.kingdee.com/article/385083637500554752?productLineId=1  。

    3,预计将在2023年1月重构发货通知单列表上的'变更数量'逻辑以支持变更数量后解锁自身锁库信息,可参考上文中的'存在的问题'中的第2点;修复上文中的'提单问题反馈及解决方案'中的第8点。



图标赞 46
46人点赞
还没有人点赞,快来当第一个点赞的人吧!
图标打赏
0人打赏
还没有人打赏,快来当第一个打赏的人吧!