# `Sp_addSysbrands` (procedure)

> 根据模块sId删除模块（包含子模块）


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sBrandId` | `varchar(255)` |
| 2 | IN | `sBrandName` | `varchar(255)` |
| 3 | IN | `sBrandNo` | `varchar(255)` |
| 4 | IN | `sBrandShortName` | `varchar(255)` |
| 5 | IN | `sBrandParentId` | `varchar(255)` |
| 6 | IN | `sLoginId` | `varchar(255)` |
| 7 | IN | `sftlogininfoId` | `varchar(255)` |
| 8 | IN | `sftlogininfoPwd` | `varchar(255)` |
| 9 | IN | `gdslogininfoId` | `varchar(255)` |
| 10 | IN | `gdslogininfoPwd` | `varchar(255)` |
| 11 | OUT | `sReturn` | `varchar(4000)` |
| 12 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** Tenant/分公司 (subsidiary) provisioning helper. Given the new brand's id / name / short-name / number / parent and an initial admin password, this proc bootstraps a fresh `sysbrands` row plus all the metadata a usable tenant needs: cloned `gdsmodule` / `gdsjurisdiction` / `gdsconfigformmaster` / `gdsconfigformslave` / `gdsparameter` / `syssystemsettings` / `sysbillnosettings` / `syssearch` (common only) / `sysreport` rows from the canonical tenant `'1111111111'` (xly's seed tenant), plus a `<brandNo>_admin` login row in both `sftlogininfo` and `gdslogininfo`. The catalog header `根据模块sId删除模块（包含子模块）` is mis-copied from another routine — it does not match the body.

**What it does:** Validates `sBrandNo` is unique via `COUNT(*) FROM sysbrands WHERE sNo = sBrandNo` (returns `SP_Sis_GetConst('sBrandNoUnique', …)` and `sCode=-1` on conflict). Then runs 10 `INSERT … SELECT FROM … WHERE sBrandsId='1111111111' AND sSubsidiaryId='1111111111'` blocks to copy seed-tenant metadata into the new brand's namespace (the seed-tenant's `sId`s are reused, the brand/subsidiary keys are remapped to `sBrandParentId`/`sBrandId`). Final two `INSERT`s seed the admin login rows and the `sysbrands` row itself.

**Invocation:** Status: appears orphaned. No caller found in any channel (form-master, gdsmodule hooks, other routines, xly-src grep). The lone xly-src hit `script/标版/30100101/Sp_addSysbrands.sql` is the install-bundle `CREATE PROCEDURE` source, not a call site — candidate for maintainer audit. Likely meant as a one-shot ops script driven manually when onboarding a new tenant, not via the BACK UI.

Caveats: relies on the `'1111111111'` seed-tenant rows being intact; if seed-tenant data is mutated the clone is corrupted; the `gdsconfigformslave` clone reuses the seed `sId` values rather than generating new ones — risks collisions with the seed tenant's own rows; subsidiary-vs-brand id semantics are swapped relative to the rest of the schema (`sBrandsId = sBrandParentId`, `sSubsidiaryId = sBrandId`).
