Sp_SalesOrder_BtnOrderCompleteApply (procedure)
- Type: PROCEDURE
- Deterministic: NO
- SQL data access: CONTAINS SQL
Parameters
| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | sProInParam |
varchar(10000) |
| 2 | IN | sMakePerson |
varchar(100) |
| 3 | IN | sBrId |
varchar(100) |
| 4 | IN | sSuId |
varchar(100) |
| 5 | OUT | sReturn |
varchar(1000) |
| 6 | OUT | sCode |
int |
Body
Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpSalesOrder_BtnOrderCompleteApply'._
Narrative
Business context: 销售管理 → 销售订单管理 → 销售订单 (salsalesorderslave) — "申请完结" (apply-to-complete) toolbar that flips the order-line's bDeliverComplete=1, stamps tDeliverCompleteDate=SYSDATE(), and stores the operator's textarea message into sDeliverCompleteMemo. Also runs the standard generic-grid valueKey/changeValue SQL-merge pattern, so any extra columns named in valueKey are merged into the same UPDATE. Distinct from Sp_SalesOrder_BtnOrderComplete, which is the simple toggle with no memo.
What it does: Validates sProInParam, splits $.changeValue.valueKey on commas and builds p_setSql as col1=val1, col2=val2, … from $.changeValue[0].colN. Appends bDeliverComplete = 1, tDeliverCompleteDate=SYSDATE(), sDeliverCompleteMemo=<textareaValue> to the SET-clause. For each sSlaveId in $.params[*].value[*] it CONCATs the prepared statement UPDATE salsalesorderslave SET <setSql> WHERE sId=p_sTmpId AND sBrandsId=sBrId AND sSubsidiaryId=sSuId and executes it via PREPARE/EXECUTE.
Invocation: Generic-dispatch button signature (sProInParam, sMakePerson, sBrId, sSuId, OUT sReturn, OUT sCode) — dispatched by GenericProcedureCallServiceImpl.doGenericProcedureCall() from the 销售订单 grid's 申请完结 line-toolbar button. Install script: script/标版/30100101/Sp_SalesOrder_BtnOrderCompleteApply.sql (also bundled in Sp_SalesOrder_BtnOrderComplete.sql). No xly-src Java caller, no gdsmodule row — binding lives in the front-end grid-button metadata.