# `Sp_detail_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_detail_purpurchaseordermaster`'`._

## Narrative

**Business context:** 采购管理 → 采购订单 — "采购订单历史记录" lookup. Given a JSON array of work-order materials, returns the materials-balance picture (already purchased vs production-demand qty) so a buyer drilling into a PO line can see the originating work-order materials history.

**What it does:** Parses `sRowData` (`JSON_TABLE` over `$[*]`) into temp `p_sRowDataSearch_tmp` with `sWorkOrderMaterialIds`, `sWorkOrderMaterialId`, `sMaterialsId`, `dAuxiliaryQty`, `sMaterialsStyle`. Joins to `MftWorkOrderMaterials` to derive the distinct `(sWorkOrderId, sWorkOrderSlaveId)` pairs into temp `p_work`. Then runs a final SELECT joining `MftWorkOrderMaterials`/`elematerials`/the materials view, returning per-row: materials id/no/name/style/unit, auxiliary unit, remaining purchase qty (`dMaterialsQty - dPurchaseQty`), production-side demand qty, knife/coefficient/reel flags, `sFormId`, etc. Output is the JSON snippet for the detail popup.

**Invocation:** Status: appears orphaned. No `gdsmodule` hook, no `gdsconfigformmaster` data-source, no other routine references it, no xly-src grep hits at all. Likely consumed by a "查看历史" button on 采购订单 dispatched via a dynamic-call path or removed in a refactor; candidate for maintainer audit.
