# `Sp_Cashier_GetProductPrice` (procedure)


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sProductGuid` | `varchar(100)` |
| 2 | IN | `sCustomerId` | `varchar(100)` |
| 3 | IN | `sBrId` | `varchar(100)` |
| 4 | IN | `sSuId` | `varchar(100)` |
| 5 | OUT | `dPrice` | `varchar(100)` |

## Body

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

## Narrative

**Business context:** 销售 / 报价 — product offer-price resolver (sales side). Was intended to return a per-unit selling price for a given product and customer by walking `eleproductcustomer` for the customer-specific quotation/list price, then falling back through `Viw_SalSalesChecking` / `Viw_SalDeliverGoods` / `Viw_SalSalesOrder` historical prices.

**What it does:** Currently a stub — the entire resolution body is commented out. It sets `dPrice='0'` and immediately returns 0. The dead code (preserved as a comment block) was the planned customer→quotation→list-price→sales-history cascade described above.

**Invocation:** Status: appears orphaned. No form-master, gdsmodule hook, other-routine caller, or xly-src caller — only the install script `script/标版/30100101/Sp_Cashier_GetProductPrice.sql`. The active product-price path is the `Fun_Sis_*` / `Fun_Order_*` family invoked from quotation/sales-order calculators. Candidate for maintainer audit — either reinstate the body or drop the proc.
