Sp_SalesInvoicing_CheckUpdate (procedure)
销售对账&开票单据保存后校验
- Type: PROCEDURE
- Deterministic: NO
- SQL data access: CONTAINS SQL
Parameters
| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | sGuid |
varchar(100) |
| 2 | IN | sFormGuid |
varchar(100) |
| 3 | IN | sLoginId |
varchar(100) |
| 4 | IN | sBrId |
varchar(100) |
| 5 | IN | sSuId |
varchar(100) |
| 6 | OUT | sCode |
int |
| 7 | OUT | sReturn |
varchar(4000) |
Body
Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpSalesInvoicing_CheckUpdate'._
Narrative
Business context: 销售管理 → 销售对账/开票流程 → 销售对账 (salsalescheckingmaster / salsalescheckingslave / salsalescheckingchild); body comment 销售对账&开票单据保存后校验. POST-save validator that enforces the two business rules a 销售对账 must obey before the row can be persisted: every 送货单 (sSrcNo) may appear only once, and all lines must come from one and the same customer. It also redistributes the per-child dProductQty so each child's allocation cannot exceed the remaining dProductQty - dCheckingQty on the source saldelivergoodsslave.
What it does: (1) Aggregates salsalescheckingslave by sSrcNo,sSrcSlaveId for sParentId=sGuid and rejects with localised sDeliveryNoDuplicate (送货单号重复选择,请核实删除) if any combination repeats; (2) joins through saldelivergoodsmaster→elecustomer and rejects with sDeliveryNoNeedSameCustomer if more than one customer is in the basket; (3) for each slave row, opens nested cursors that compute the maximum sellable quantity MIN(SUM(dProductQty)/MAX(dCoefficient)) over salsalescheckingchild + saldelivergoodsslave and rejects with sOrderProductQtyUp if the slave qty exceeds it, otherwise re-allocates dProductQty across child rows in iIncrement order; (4) recomputes dProductForeignPrice on return-style rows (sSrcNo LIKE '%XSTH%'); (5) chains to CALL Sp_Check_sSck for the standard 销售对账 post-save check.
Invocation: Naming pattern + (sGuid,sFormGuid,sLoginId,sBrId,sSuId,OUT sCode,OUT sReturn) signature places this as a gdsmodule.sSaveProName POST-save hook on the 销售对账单据 form (module sId 11811781131121915184849572550) — runs after BusinessBaseServiceImpl.addUpdateDelBusinessData persists the bill. No xly-src caller; not referenced from any other proc. The trailing CALL Sp_Check_sSck ties it to the same bill family.