Sp_BtnUpdate_OnOpsConfirm (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 | sUserId |
varchar(100) |
| 4 | IN | sBrId |
varchar(100) |
| 5 | IN | sSuId |
varchar(100) |
| 6 | OUT | sReturn |
varchar(1000) |
| 7 | OUT | sCode |
int |
Body
Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpBtnUpdate_OnOpsConfirm'._
Narrative
Business context: 外协加工单 / 外协商确认发货 — outsourced-processing supplier portal: lets a subcontractor (外协商) toggle the "shipment confirmed" flag on selected opsoutsideprocessslave lines they have been allocated.
What it does: Parses $.params[*].value[*].sSlaveId from the JSON payload; for each slave line whose current bOutConfirm=0, sets bOutConfirm to its toggle (CASE 1↔0), stamps tOutConfirmDate=NOW() and sOutConfirmPerson=sMakePerson. Reads $.changeValue.textareaValue but the value is never written — appears to be a stub for an unimplemented remark field.
Invocation: Dispatched dynamically by GenericProcedureCallServiceImpl.doGenericProcedureCall() (POST /procedureCall/doGenericProcedureCall) — toolbar button on the 外协加工单 supplier-portal grid registers this procedure name in its button config. No callers in any DB metadata column or xly-src grep for this DB instance.
Flag: the WHERE A.sId=p_sId and bOutConfirm =0 guard means once a row is confirmed, the CASE toggle can never run again — effective behaviour is one-way "confirm", not toggle. Comment says 确认发货 (confirm shipment).