# `sp_get_sOppositeColor` (procedure)


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sWorkOrderControlId` | `varchar(100)` |
| 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_get_sOppositeColor`'`._

## Narrative

**Business context:** Printing-industry production setup. "Opposite
color" (`sOppositeColor` on `mftworkordercontrol`) is a per-work-order
print-color configuration — typically the alternate face's color list
for a double-sided print job, or a substitute-color mapping when the
target ink isn't available. This proc reads that configuration off a
specific work-order control row and forwards it for processing.

**Status: appears orphaned.** No caller found in any channel — no
Java/MyBatis code, no SQL templates, no other procs, no metadata-side
form-master row, no module hook. Either: (a) called only from
customer-override SQL not in this snapshot, (b) called via dynamic
dispatch by a name passed in at runtime, or (c) dead code. Worth a
maintainer audit before relying on it.

**What it does:** two steps. Reads `mftworkordercontrol.sOppositeColor`
for the input `sWorkOrderControlId`, tenant-scoped by
`sBrId`/`sSuId`. Then forwards that value (plus tenant ids and the
two OUT params) to
[`sp_get_sOppositeColor_data`](sp_get_sOppositeColor_data.md), which
does the actual color resolution. The split lets the same `*_data`
proc be called with an already-known `sOppositeColor` value — a
common xly pattern where `<proc>` / `<proc>_data` form an
"I have the id" / "I have the value" pair.

**Naming note:** lowercase `sp_` prefix (vs. the majority `Sp_*`) — a
naming-style outlier, same engine type, just inconsistent casing.
