# Troubleshooting e Testes

<div class="pw" id="bkmrk-"><div class="ph"></div></div>Problemas comuns, checklist de diagnóstico e como testar o endpoint manualmente.

## Problemas comuns

### 1. `vendas_ecommerce` sempre retorna vazio

<div class="pw" id="bkmrk-causas-poss%C3%ADveis-%E2%80%94-v"><div class="card"><div class="ct">Causas possíveis — verificar em ordem</div>1. O `cnpjLoja` não tem entidades ativas no MySQL:  
    `SELECT e.* FROM entidade e JOIN juridica j ON e.id_pessoa=j.id WHERE j.cnpj='CNPJ' AND e.situacao='ATIVO'`
2. A filial está como `TIPO_FILIAL = 'FRANQUIA'` no SQL Server — excluímos franquias.
3. A view `W_BI_FAT_VENDEDOR_VDK_OMNI_V0` não tem dados para o período/filial informados.
4. Falha na conexão SQL Server — verificar porta `1435` e extensão `pdo_sqlsrv`.

</div></div>### 2. Erro de nenhum registro por período além do limite

<div class="pw" id="bkmrk-causa"><div class="card"><div class="ct">Causa</div></div></div>O período informado ultrapassa **200 dias no passado**. A implementação atual monta um `fallback` internamente, mas a resposta final retorna `success:false` com mensagem de nenhum registro encontrado. Com a data de hoje **2026-06-09**, o limite de calendário recua até **2025-11-21**; por causa da comparação com horário atual, use **2025-11-22** como primeira data segura para evitar a borda.

```
// dataInicio: "2025-01-01" → excede → retorna success:false
// dataInicio: "2025-11-22" → dentro do limite com margem de segurança
```

### 3. Erro `success: false` — campo faltante

<div class="pw" id="bkmrk-solu%C3%A7%C3%A3o"><div class="card"><div class="ct">Solução</div></div></div>Verificar se o payload contém os três campos dentro de `parametros`: `dataInicio`, `dataFim` e `cnpjLoja`. Valores `null` ou string vazia também disparam a validação.

### 4. Trocas não aparecem mesmo com devoluções registradas

<div class="pw" id="bkmrk-causas-poss%C3%ADveis-a-t"><div class="card"><div class="ct">Causas possíveis</div>- A troca não está com `situacao = 'FINALIZADO'` — buscamos apenas finalizadas.
- O `tipo_estoque` não é `'TROCA'` — outros tipos de entrada são ignorados.
- A data de emissão da troca está fora do período solicitado.

</div></div><div class="pw" id="bkmrk--1"><div class="card"></div></div>## Checklist de diagnóstico

<div class="pw" id="bkmrk-%23-verifica%C3%A7%C3%A3o-comand"><div class="tw"><table><thead><tr><th>\#</th><th>Verificação</th><th>Comando / Query</th></tr></thead><tbody><tr><td>1</td><td>MySQL acessível?</td><td>`SELECT 1` via PDO</td></tr><tr><td>2</td><td>CNPJ existe em `juridica`?</td><td>`SELECT * FROM juridica WHERE cnpj = 'CNPJ'`</td></tr><tr><td>3</td><td>CNPJ tem filiais ativas?</td><td>`SELECT e.codigo FROM entidade e JOIN juridica j ON e.id_pessoa=j.id WHERE j.cnpj='CNPJ' AND e.situacao='ATIVO'`</td></tr><tr><td>4</td><td>Existem vendas PDV no período?</td><td>`SELECT COUNT(*) FROM movimentacao WHERE modulo='PDV' AND tipo='SAIDA' AND data_emissao BETWEEN '...' AND '...'`</td></tr><tr><td>5</td><td>SQL Server acessível?</td><td>`new \db_sqlserver(false, 'LX_ZERO_300', true)` — exception = falha de conexão</td></tr><tr><td>6</td><td>View tem dados?</td><td>No SSMS: `SELECT TOP 10 * FROM W_BI_FAT_VENDEDOR_VDK_OMNI_V0 WHERE EMISSAO >= 'data'`</td></tr><tr><td>7</td><td>Log da requisição salvo?</td><td>`SELECT * FROM wosk_webservice_retorno ORDER BY id DESC LIMIT 5`</td></tr></tbody></table>

</div></div>## Como testar o endpoint

### Via cURL

```
curl -X POST https://SEU_SERVIDOR/bibliotecas/<TOKEN_FULLSTORE> \
  -H "Content-Type: application/json" \
  -d '{
    "acao": "getVendas",
    "parametros": {
      "dataInicio": "2026-05-01",
      "dataFim":    "2026-05-31",
      "cnpjLoja":   "12345678000190"
    }
  }'
```

### Forçar erro (ambiente de testes)

```
{
  "acao":   "getVendas",
  "falha":  "teste",
  "parametros": {
    "dataInicio": "2026-05-01",
    "dataFim":    "2026-05-31",
    "cnpjLoja":   "12345678000190"
  }
}
```

## Interpretando a resposta

<div class="pw" id="bkmrk-cen%C3%A1rio-success-fall"><div class="tw"><table><thead><tr><th>Cenário</th><th>success</th><th>fallback</th><th>Arrays</th><th>Ação</th></tr></thead><tbody><tr><td>Funcionamento normal</td><td><span class="badge bg">true</span></td><td>`null`</td><td>Preenchidos</td><td>Processar normalmente</td></tr><tr><td>Sem movimento no período</td><td><span class="badge br">false</span></td><td>—</td><td>—</td><td>Validar se realmente não há dados no período</td></tr><tr><td>Período além do limite</td><td><span class="badge br">false</span></td><td>Não exposto na resposta atual</td><td>—</td><td>Ajustar datas da consulta</td></tr><tr><td>Parâmetro faltando</td><td><span class="badge br">false</span></td><td>—</td><td>—</td><td>Corrigir payload</td></tr><tr><td>Falha de banco de dados</td><td><span class="badge br">false</span></td><td>—</td><td>—</td><td>Verificar conectividade e logs PHP</td></tr></tbody></table>

</div><div class="sb">**Regra de ouro: verificar success antes dos arrays** Toda integração deve checar o campo top-level `success` antes de processar qualquer array. Na implementação atual, resposta sem nenhum registro retorna `success:false`; arrays vazios só aparecem quando pelo menos o envelope de dados é retornado.</div>  
</div>