Troubleshooting e Testes
Problemas comuns, checklist de diagnóstico e como testar o endpoint manualmente.
Problemas comuns
1. vendas_ecommerce sempre retorna vazio
Causas possíveis — verificar em ordem
- O
cnpjLojanã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' - A filial está como
TIPO_FILIAL = 'FRANQUIA'no SQL Server — excluímos franquias. - A view
W_BI_FAT_VENDEDOR_VDK_OMNI_V0não tem dados para o período/filial informados. - Falha na conexão SQL Server — verificar porta
1435e extensãopdo_sqlsrv.
2. Erro de nenhum registro por período além do limite
Causa
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
Solução
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
Causas possíveis
- A troca não está com
situacao = 'FINALIZADO'— buscamos apenas finalizadas. - O
tipo_estoquenão é'TROCA'— outros tipos de entrada são ignorados. - A data de emissão da troca está fora do período solicitado.
Checklist de diagnóstico
| # | Verificação | Comando / Query |
|---|---|---|
| 1 | MySQL acessível? | SELECT 1 via PDO |
| 2 | CNPJ existe em juridica? |
SELECT * FROM juridica WHERE cnpj = 'CNPJ' |
| 3 | CNPJ tem filiais ativas? | SELECT e.codigo FROM entidade e JOIN juridica j ON e.id_pessoa=j.id WHERE j.cnpj='CNPJ' AND e.situacao='ATIVO' |
| 4 | Existem vendas PDV no período? | SELECT COUNT(*) FROM movimentacao WHERE modulo='PDV' AND tipo='SAIDA' AND data_emissao BETWEEN '...' AND '...' |
| 5 | SQL Server acessível? | new \db_sqlserver(false, 'LX_ZERO_300', true) — exception = falha de conexão |
| 6 | View tem dados? | No SSMS: SELECT TOP 10 * FROM W_BI_FAT_VENDEDOR_VDK_OMNI_V0 WHERE EMISSAO >= 'data' |
| 7 | Log da requisição salvo? | SELECT * FROM wosk_webservice_retorno ORDER BY id DESC LIMIT 5 |
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
| Cenário | success | fallback | Arrays | Ação |
|---|---|---|---|---|
| Funcionamento normal | true | null |
Preenchidos | Processar normalmente |
| Sem movimento no período | false | — | — | Validar se realmente não há dados no período |
| Período além do limite | false | Não exposto na resposta atual | — | Ajustar datas da consulta |
| Parâmetro faltando | false | — | — | Corrigir payload |
| Falha de banco de dados | false | — | — | Verificar conectividade e logs PHP |
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.
No comments to display
No comments to display