# `spKPImodule` (procedure)


- **Type:** PROCEDURE
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

_No parameters._

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURE `spKPImodule`'`._

## Narrative

**Business context:** 系统 → KPI考核 — bootstrap / sync proc that materialises one `kpimodule` row per business-displayable `gdsmodule` so the KPI configuration UI has a complete list of modules to attach 工作果实 / 限制时间 / 奖励 / 处罚 defaults to. Also nukes the login-info jurisdiction rows on the way out.

**What it does:** Three statements. (1) `INSERT INTO kpimodule(sId,…)` from `gdsmodule M WHERE bUnTask=1 AND sDisplayType='Business' AND sName<>''` for any module not yet in `kpimodule` (left-anti-join via `NOT IN`) — defaults `dLimitation=8h`, `sLimitTime='16:00:00'`, `sWorkDate='08:00:00'`, `dreward=0`, `dpunishment=0`, copies `sChineseUnMemo`/`sChineseWorkFruit` into `sUnMemo`/`sWorkFruit`. (2) `UPDATE kpimodule SET bVisible=1` for rows whose `sModelId` is no longer in the live module set (orphan kpi rows). (3) `DELETE FROM sysjurisdiction WHERE sJurisdictionClassifyId IN (SELECT sId FROM sisjurisdictionclassify WHERE bLogininfoShow=1)` — clears all login-info jurisdiction grants.

**Invocation:** Status: appears orphaned. No `gdsmodule`/`gdsconfigformmaster` binding, no other DB routine, no Quartz task row, no Java caller — only the install script `script/标版/30100101/spKPImodule.sql` references this name. Lowercase `sp` prefix, no IN/OUT params → likely an admin one-shot run manually by maintainers (`CALL spKPImodule();`) to reconcile KPI module rows after a deployment. The third `DELETE` is destructive — flag before re-running.