Sp_OEE_PlanByProcess (procedure)

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

Parameters

#	Mode	Name	Type
1	IN	iState	int
2	IN	sLoginId	varchar(100)
3	IN	sMachineId_s	varchar(100)
4	IN	sProceeAllMachine	varchar(10)
5	IN	sSuId	varchar(100)
6	IN	sBrId	varchar(100)
7	IN	bFilter	varchar(5000)
8	IN	sUnTaskFormId	varchar(100)
9	IN	pageNum	int
10	IN	pageSize	int
11	OUT	totalCount	int
12	IN	countCloumn	varchar(5000)
13	OUT	countMapJson	longtext
14	IN	sFilterOrderBy	varchar(5000)
15	IN	sGroupby_select_sql	varchar(5000)
16	IN	sGroupby_group_sql	varchar(5000)

Body

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

Narrative

Business context: OEE管理 — paged plan-by-process feed: given a machine (or "all-machine" override) and a force-finish flag, returns the production tasks queued for that machine as one row per 工序 (process step), including parts/colour/plate counts, materials, reserves, customer, team, and the up-/down-stream work-order linkage.

What it does: Builds the large p_Tmp_ProductionReport temp table (~80 columns of plan/process/material/colour data), branches on iState (0 normal, 1 force-finish) and sProceeAllMachine (process-level vs. machine-level filter). Populates the temp from mftproductionplanslave joined to work-order / process / material / customer / look-customer scopes, then runs a paging-shaped final SELECT through the pageNum/pageSize/totalCount/countCloumn/sFilterOrderBy/sGroupby_* parameters typical of the form-master report contract — same signature as the sibling Sp_OEE_ProductionReport, so a paging wrapper is expected.

Invocation: Status: appears orphaned. No gdsconfigformmaster binding, no gdsmodule hook, no other proc/function call, and no xly-src caller (Java, MyBatis, install script) reference this name. Looks like a sibling/precursor of Sp_OEE_ProductionReport that was never wired to a form. Candidate for maintainer audit.