> ## Documentation Index
> Fetch the complete documentation index at: https://docs.domsoftware.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Depósitos (QA)

> Testes de Depósitos

# OmniDom Depósitos — QA Test Documentation

### 📌 Suíte de Testes

* **Nome da funcionalidade testada:** Gestão, Cadastro e Configuração de Depósitos
* **Módulo/sistema identificado:** Módulo de Logística / OmniDom
* **Pré-condições gerais:** Usuário autenticado, empresa habilitada e permissão total na tela de Depósitos.

***

### 🧪 Casos de Teste

**CT1: Fluxo Positivo do Cadastro de Novo Depósito e Automação de CEP**

* **Tipo:** Positivo
* **Pré-condição:** Estar na página logada de "Depósitos".
* **Dados de Entrada:** Empresa vinculada: "Empresa X", Nome: "Depósito Teste", Código Interno: "TST-01", Estrutura: "Loja", CEP: "09540-000".
* **Passos:**
  1. Clicar no botão "+ Novo Depósito".
  2. Preencher "Empresa", "Nome", "Código Interno" e tipo de "Estrutura".
  3. Descer para os dados viários e preencher o "CEP". Acionar busca.
  4. Confirmar o preenchimento automático geográfico.
  5. Validar a submissão geral e salvar.
* **Resultado Esperado:** O modal desaparece sem travamentos visuais e o alerta do sistema ("Depósito criado com sucesso!") pipoca no ambiente.
* **Critério de Aprovação:** Confirmação dos dados persistida na tabela/grid central e validação do fluxo do CEP respondendo corretamente ao gatilho.
* **Origem:** Observado nas telas.

**CT2: Avaliar a Restrição de Unicidade do Flag "Padrão"**

* **Tipo:** Borda / Lógico
* **Pré-condição:** Ter ao menos dois depósitos listados (Depósito A sendo classificado como Padrão e Depósito B como convencional).
* **Dados de Entrada:** Ação de click e confirmação no pop-up via "Depósito B".
* **Passos:**
  1. Localizar a linha referencial ao "Depósito B".
  2. Abrir seu menu de contextos (reticências ou action box).
  3. Clicar para torná-lo Padrão.
* **Resultado Esperado:** O toast afirmativo relatará o sucesso operacional; a interface retirará a flag de Padrão do grid de A, depositando a insígnia unicamente no campo do "Depósito B".
* **Critério de Aprovação:** Impossibilidade imperativa do DOM e Banco manterem dois depósitos rotulados como centrais.
* **Origem:** Observado nas telas / Testado a partir dos comandos de Action.

**CT3: Invalidação de Integração de CEP (Busca Falha de Rua)**

* **Tipo:** Negativo
* **Pré-condição:** Etapa do Cadastro rodando normal até o Campo do CEP.
* **Dados de Entrada:** CEP puramente inexistente (ex: "00000-000").
* **Passos:**
  1. Inserir a numeração fantasma falseada na API do ViaCEP ou similar.
  2. Acionar a *lupa* ou perder o foco do componente (onBlur).
* **Resultado Esperado:** Os campos Logradouro, Cidade, Bairro e Estado continuam trancados ou estritamente em branco. O sistema lança o alerta ou desabilita o Save.
* **Critério de Aprovação:** O campo trava sua rotina automática na ausência de validação via WebService logístico.
* **Origem:** Inferido das boas-práticas de formulários UI da plataforma (extensão obrigatória de Teste QA).

***

### 📋 Regras de Negócio Testadas

* **RN1: Resolução de CEP Remota Ativa**
  * Casos de teste relacionados: CT1, CT3.
* **RN2: Unicidade Lógica do Flag Padrão de Expedição**
  * Casos de teste relacionados: CT2.

***

### ⚠️ Cenários de Exceção

* Tempo de resposta demasiadamente longo da API correios no CEP forçando um estado eterno de "*Loading*" travando a execução modal inteira do front-end. O botão de salvamento não pode habilitar durante o fetch.

***

### 📊 Matriz de Cobertura

| Funcionalidade                 | CT Positivo | CT Negativo | CT Borda |
| ------------------------------ | ----------- | ----------- | -------- |
| Cadastro de Depósito           | CT1         | -           | -        |
| Fluxo de CEP dinâmico          | CT1         | CT3         | -        |
| Mudança Lógica de Local Padrão | -           | -           | CT2      |

***

*Documentação gerada via DocVision Test*