# `Sp_ScanPicking` (procedure)

> 扫码入库


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sId` | `varchar(100)` |
| 2 | IN | `sUserId` | `varchar(100)` |
| 3 | IN | `sBrandsId` | `varchar(100)` |
| 4 | IN | `sSubsidiaryId` | `varchar(100)` |
| 5 | OUT | `sCode` | `int` |
| 6 | OUT | `sReturn` | `varchar(5000)` |

## Body

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

## Narrative

**Business context:** 移动端管理 → 扫码业务 (likely 扫码送货 / 扫码入库, paired with modules `101251240115015959228704430` 扫码送货 and `101251240115015959853077870` 扫码送货(单据)). When a worker scans a product-barcode label on a mobile device the proc validates the label and returns its full attributes for the next step (`COMMENT '扫码入库'`).

**What it does:** Looks up `pitproductbarcode` by the scanned `sId`. Returns `sCode=-1` with a localised message if the label doesn't exist (`该标签不存在`) or has been used (`bUsed=1` → `该标签已使用，不能重复扫码`). Otherwise selects the full barcode row plus a derived `sSqlConditionId = CONCAT(sMaterialsId, sDefineNo, sDefineNo2, sWarehouseId, sLocationId, sWarehouseLocationId, sMaterialsStyle)` so the caller can match the label against in-store / picking conditions.

**Invocation:** No DB caller and no Java/XML reference in xly-src — only the install script `script/标版/30100101/Sp_ScanPicking.sql` ships the proc. The expected reach is a mobile/scan-handler that invokes it dynamically by name (similar pattern to other scan routines), but no concrete call site is discoverable in this tree. Status: appears orphaned — candidate for maintainer audit to confirm which mobile endpoint dispatches it.