金蝶云信用占用的更新计算是考虑销售业务流程的上下游关系，单据下推到下游单据时，通过下游单据占用信用，释放上游信用占用的方式进行更新。
单据上更新信用的过程：
一、 在保存或提交时调用【保存或删除时更新信用关联表信息】服务，更新信用关联关系。
因为信用的更新不是简单的把单据上的金额更新到信用余额，至于具体要更新多少金额就必须要知道这张单据对应的上游信用单据的金额是多少，首先要释放上游的金额再占用本单的金额。 信用的关联跟普通的单据上下游关联又有所不同，单据直接上游未必是信用单据，而做信用更新的上游必须要是信用单据。 所以信用单独做了一个信用的关联关系表来存储信用的关联关系。
信用关联表表名： T_CRE_TRACK
名称 | 代码 | 数据类型 | 长度 | 注释 |
主键guid | FID | varchar(36) | 36 | |
基本单位数量 | FBASEUNITQTY | decimal(23,10) | 23 | |
销售订单分录id | FSOENTRYID | bigint | ||
销售订单是否下推 | FSOISPUSH | varchar(255) | 255 | |
销售订单信用单价 | FSOPRICE | decimal(23,10) | 23 | |
销售订单源单类型 | FSOSRCFORMID | varchar(255) | 255 | |
销售订单源单类型(最后) | FSOSRCFORMIDLAST | varchar(36) | 36 | |
发货通知单分录id | FDELIVERYENTRYID | bigint | ||
发货通知单是否下推 | FDELIVERYISPUSH | varchar(255) | 255 | |
发货通知单信用单价 | FDELIVERYPRICE | decimal(23,10) | 23 | |
发货通知单源单类型 | FDELIVERYSRCFORMID | varchar(255) | 255 | |
发货通知单源单类型(最后) | FDELIVERYSRCFORMIDLAST | varchar(36) | 36 | |
销售出库单分录ID | FOUTENTRYID | bigint | ||
销售出库单是否下推 | FOUTISPUSH | varchar(255) | 255 | |
销售出库单信用单价 | FOUTPRICE | decimal(23,10) | 23 | |
销售出库单源单类型 | FOUTSRCFORMID | varchar(255) | 255 | 如果有多级源单,出库单是由销售订单下推发货通知单再下推而成的，该字段值为： SAL_SaleOrder|SAL_DELIVERYNOTICE| |
销售出库单源单类型(最后) | FOUTSRCFORMIDLAST | varchar(36) | 36 | 记录最后一级的源单： SAL_DELIVERYNOTICE |
退货通知单分录ID | FRETNOTICEENTRYID | bigint | ||
退货通知单是否下推 | FRETNOTICEISPUSH | varchar(255) | 255 | |
退货通知单信用单价 | FRETNOTICEPRICE | decimal(23,10) | 23 | |
退货通知单源单类型 | FRETNOTICESRCFORMID | varchar(255) | 255 | |
退货通知单源单类型(最后) | FRETNOTICESRCFORMIDLAST | varchar(36) | 36 | |
退库单分录ID | FRETSTOCKENTRYID | bigint | ||
退库单是否下推 | FRETSTOCKISPUSH | varchar(255) | 255 | |
退库单信用单价 | FRETSTOCKPRICE | decimal(23,10) | 23 | |
退库单源单类型 | FRETSTOCKSRCFORMID | varchar(255) | 255 | |
退库单源单类型(最后) | FRETSTOCKSRCFORMIDLAST | varchar(36) | 36 | |
应收单分录ID | FARENTRYID | bigint | ||
应收单是否下推 | FARISPUSH | varchar(255) | 255 | |
应收单信用单价 | FARPRICE | decimal(23,10) | 23 | |
应收单源单类型 | FARSRCFORMID | varchar(255) | 255 | |
应收单源单类型(最后) | FARSRCFORMIDLAST | varchar(36) | 36 |
二、在提交或审核时调用【更新信用额度】服务，更新单据的信用明细表和信用余额。
更新信用额度这个服务包括两个部分，一个是检查信用是否超标，一个就是更新信用余额，判断信用超标简单的来说是根据当前单据对应的信用档案已占用的信用额加上当前单据应该更新的信用金额之和与信用档案的信用额度进行对比，如果超出就会提示，更新信用余额主要是更新单据的信用明细表和信用占用表这两张表的数据。
每张信用单据都有一张信用明细表，表结构是一样的，以销售订单的信用明细表说明
销售订单的信用明细表表名： T_SAL_ORDERENTRY_CRE
名称 | 代码 | 数据类型 | 长度 | 注释 |
单据明细分录id | FENTRYID | int | ||
分录档案明细id | FARCHIVEENTRYID | int | ||
本单额度 | FBILLCREDITAMOUNT | decimal(23,10) | 23 | |
执行额度 | FEXECCREDITAMOUNT | decimal(23,10) | 23 | |
源单额度 | FSRCCREDITAMOUNT | decimal(23,10) | 23 | |
关闭额度 | FCLOSECREDITAMOUNT | decimal(23,10) | 23 | |
更新方向 | FORIENT | char(1) | 1 | +' 正向 ‘-’ 反向 |
币别 | FCURRENCYID | int | ||
本单基本单位数量 | FBASEUNITQTY | decimal(23,10) | 23 | |
信用的上游单据类型 | FCREDITSRCFORMID | varchar(36) | 36 | |
信用的下游单据类型 | FCREDITTARGETFORMID | varchar(36) | 36 |
记录源单额度的目的，是反向操作时，能够知道上游信用单据增加多少信用占用。 记录执行额度的目的是和本单金额对比才知道当前单据占用多少额度，关闭额度是在单据关闭时记录的，反关闭时要增加相应的信用占用。
另外，还有一个信用占用明细表，记录每个信用档案的信用占用情况，表名： T_CRE_CREDITUSEDETAIL
名称 | 代码 | 数据类型 | 长度 | 注释 |
组织 | FORGID | int | ||
对象类型 | FOBJECTTYPE | varchar(20) | 20 | 枚举 |
BD_Customer：客户 | ||||
ORG_Organizations：组织 | ||||
BD_Department：部门 | ||||
BD_Saler：销售员 | ||||
BD_SaleGroup：销售组 | ||||
对象 | FOBJECTID | int | ||
币别 | FCURRENCYID | int | ||
占用额度 | FCREDITAMOUNT | decimal(23,10) | 23 | |
信用控制范围 | FCTRLSCOPE | varchar(20) | 20 | 枚举 |
1：集团 | ||||
2：法人 | ||||
3：组织 | ||||
信用档案ID | FARCHIVEENTRYID | int | ||
授信部门 | FDEPTID | int | ||
ROWID(GUID) | FROWID | varchar(36) | 36 | 主键 |
占用类型 | FTYPE | varchar(20) | 20 | |
单据类型 | FFORMID | varchar(36) | 36 | |
单据ID | FBILLID | int | ||
处理时间 | FDATETIME | datetime | ||
销售组ID | FSALEGROUPID | int | ||
销售员ID | FSALERID | int | ||
客户ID | FCUSTOMERID | int |
三、在反审核时调用【更新信用额度】服务，清除单据的信用明细表和更新信用余额。
有些特殊的应用场景目前信用是无法支持的，比如：
1、下推到同一单据的场景，比如销售订单下推到销售订单的场景，如果这两张销售订单都控制信用的话，信用扣减逻辑会出现混乱，只能其中一张单据可以控制信用，可以加个标识区分。
2、多分支流程的场景，信用也不支持，比如销售订单下推了发货通知，同时销售订单又下推了应收单，这时候，发货通知和应收单都想控制信用是做不到的，只能选择其中一条线来控制信用。
3、业务流程跨级超过三级也无法支持，比如销售订单—>发货通知—>直接调拨—>结算单—>销售出库—>应收单。 只想销售订单和销售出库控制信用也是做不到的，因为中间跨级太多，销售出库无法正确的找到对应销售订单的关联信用情况。只有中间的发货通知单也控制信用就可以支持。
4、订单下推了发货通知单（未审核），然后关闭订单，这时候系统是无法判断这张发货通知单是要执行还是不要执行的，关闭订单时也就不知道要释放多少信用
推荐阅读