# `Sp_history_purpurchaseordermaster` (procedure)

> 获取采购订单历史记录


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sRowData` | `longtext` |
| 2 | IN | `sBrId` | `varchar(100)` |
| 3 | IN | `sSuId` | `varchar(100)` |
| 4 | OUT | `sCode` | `int` |
| 5 | OUT | `sReturn` | `longtext` |

## Body

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

## Narrative

**Business context:** Older JSON-input sibling of `Sp_history_purpurchaseordermaster_data` — same intent (per-material 采购订单历史记录 lookup) but takes `sRowData` as a JSON array of `[{sWorkOrderMaterialIds, sWorkOrderMaterialId, sMaterialsId, sMaterialsStyle}, ...]` instead of pulling the scope itself from a master id.

**What it does:** `JSON_TABLE` parses `sRowData` into `p_sRowDataSearch_tmp`, then walks it via cursor and accumulates prior `purpurchaseordermaster`/`purpurchaseorderslave` rows for each (sMaterialsId, sMaterialsStyle) pair into `p_history_data`. Cursor declares `Cur_OrderSlave_handle1 = 1` (not 0) so the first row is silently skipped — a known off-by-one bug not present in the `_data` variant.

**Invocation:** Status: appears orphaned. The live 历史采购价格 form `16906148030002174531746365163300` binds to `Sp_history_purpurchaseordermaster_data` (the master-id variant) instead. No other form/proc/Java caller references this JSON-input shape. Superseded; candidate for retirement after a maintainer confirms no integration sends the JSON payload.
