SP_DeliverGoods_Warning (procedure)

• Type: PROCEDURE
• Deterministic: NO
• SQL data access: CONTAINS SQL

Parameters

#	Mode	Name	Type
1	IN	tStartDate	datetime
2	IN	tEndDate	datetime
3	IN	sBrId	varchar(100)
4	IN	sSuId	varchar(100)
5	IN	bFilter	varchar(5000)
6	IN	pageNum	int
7	IN	pageSize	int
8	OUT	totalCount	int
9	IN	countCloumn	varchar(5000)
10	OUT	countMapJson	longtext
11	IN	sFilterOrderBy	varchar(5000)
12	IN	sGroupby_select_sql	varchar(5000)
13	IN	sGroupby_group_sql	varchar(5000)

Body

Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESPDeliverGoods_Warning'._

Narrative

Business context: 销售管理 → 发货计划管理 → 超期未送货预警表 — paged "delivery-warning" report. For each sales-order slave row it computes a yujing flag (already complete vs days-until-promised-delivery) and exposes the row with product, customer, tax info so dispatchers can chase late deliveries.

What it does: Defaults tEndDate to "now + 1 day" if null and tStartDate to 2000-01-01 if null. Builds a temporary copy of Viw_MftWorkOrder filtered to the period, joins customer/product/tax info, then routes a dynamic SELECT (with sFilterOrderBy, sGroupby_*_sql, page/size) through the standard pagination dispatchers (Sp_Outstanding_Query / Sp_Do_UpdateByPageSizeBefore) to produce totalCount and countMapJson for column-totals.

Invocation: Status: the live gdsconfigformmaster row for 超期未送货预警表 (101251240115015879470853200) is bound to the view Viw_SalSalesOrder rather than this proc — the form was migrated. The proc is still wired through Fun_getInitColumnByProName (the helper that returns the column manifest when sProductName='SP_DeliverGoods_Warning'), so it remains the canonical column source. Likely retained as the historical/alternate report body; verify whether any tenant override still calls it. Install body: script/标版/30100101/SP_DeliverGoods_Warning.sql.