Tiny ERP no ChatGPT (e em outras IAs): 10 análises que o MCP da Kondado entrega lendo seus dados

Como o Tiny ERP responde no ChatGPT?

A Kondado replica as 42+ tabelas do Tiny ERP V3 (pedidos, contas a pagar, contas a receber, NFe, estoque, contatos, produtos, marcadores, intermediadores de marketplace) para o Via Kondado, o destino canônico do cliente. Em seguida, o MCP da Kondado expõe o endpoint https://mcp.kondado.io/mcp para o ChatGPT, o Claude, o Cursor e qualquer outro cliente compatível com Model Context Protocol consultarem esses dados via KSQL autenticado em modo somente leitura.

Na prática: você abre o ChatGPT, conecta o MCP da Kondado uma vez e passa a perguntar em português coisas como "qual o ticket médio dos pedidos faturados no último trimestre por canal?" ou "quais SKUs estão com saldo abaixo de 5 unidades no depósito principal?". A resposta vem interpretada, com os números reais do seu Tiny, sem exportar CSV, sem reabrir a dashboard e sem montar consulta nova.

O que é o MCP da Kondado?

O Model Context Protocol (MCP) é um padrão aberto que permite que assistentes de IA conversem com fontes externas de dados de forma estruturada. O MCP da Kondado é a implementação que abre o seu Via Kondado para consulta direta por LLMs.

Características do MCP da Kondado:

1. Endpoint único: https://mcp.kondado.io/mcp. Funciona com o ChatGPT (conector custom GPT), o Claude (Claude Desktop ou pelo navegador), o Cursor, o Continue e qualquer cliente compatível com Model Context Protocol.
2. Autenticação por API key: a chave é gerada na sua conta Kondado e fica vinculada ao Via Kondado que você escolher (BigQuery, PostgreSQL, MySQL, Redshift, SQL Server, Excel, Google Sheets ou Amazon S3 como camada de dados).
3. Somente leitura (KSQL): o LLM consulta, não altera. Sem write, sem update, sem delete. Os dados ficam protegidos.
4. Conhece o esquema canônico: o MCP da Kondado entende os nomes literais das tabelas (tinyerp_v3_pedidos, tinyerp_v3_pedidos_detalhes, tinyerp_v3_contas_pagar_detalhes, tinyerp_v3_notas, etc.), os campos status-conditional e as relações de FK (por exemplo, notas.origem_id para pedidos.id). É esse contexto que diferencia uma resposta correta de um chute interpretado em cima de CSV solto.

Para se aprofundar, veja a visão geral do MCP da Kondado, o guia de configuração no ChatGPT e o guia de configuração no Claude.

Como conectar o Tiny ERP ao ChatGPT em 3 passos?

Passo 1: replique o Tiny ERP V3 no Via Kondado. Crie a integração de Tiny ERP na Kondado, autentique pelo OAuth2 da Olist Tiny (a Kondado gerencia automaticamente o refresh do token Keycloak, que tem validade de 24 horas e rotação a cada uso). Ative as integrações que você quer disponíveis para a IA: tipicamente pedidos, pedidos_detalhes, pedidos_detalhes_itens, contas_pagar_detalhes, contas_receber_detalhes, notas, produtos, estoque, estoque_depositos e contatos. Configure a frequência de atualização que faz sentido para o seu negócio.

Passo 2: escolha o destino (camada de dados) do Via Kondado. A Kondado replica os dados do Tiny para o destino que você escolher: BigQuery, PostgreSQL, MySQL, Redshift, SQL Server, Excel, Google Sheets ou Amazon S3. É essa camada que o MCP da Kondado consulta quando o ChatGPT manda uma pergunta. Se você não tem ambiente próprio, use uma das opções gerenciadas indicadas no setup.

Passo 3: ative o MCP da Kondado no seu cliente de IA preferido. No ChatGPT, abra a configuração de conectores e adicione um conector apontando para https://mcp.kondado.io/mcp com a sua API key. No Claude Desktop, edite o claude_desktop_config.json e adicione a mesma URL. No Cursor ou Continue, use a interface de MCP servers. A partir desse momento, o assistente passa a entender quais tabelas existem no seu Via Kondado e responde perguntas em português direto sobre elas.

10 análises que o ChatGPT responde lendo seu Tiny ERP via MCP

Cada bloco abaixo mostra uma pergunta natural que você pode digitar no ChatGPT, qual tabela da Kondado o LLM lê para responder e que decisão de negócio a resposta destrava. As perguntas estão entre aspas exatamente como você escreveria.

Vendas e pedidos

1. Ticket médio por canal de venda no trimestre.

• Pergunta no ChatGPT: "Qual o ticket médio dos pedidos faturados no último trimestre por canal de venda?"
• O LLM lê: tinyerp_v3_pedidos_detalhes (campos valortotalpedido, datafaturamento, ecommerce_canalvenda).
• Decisão que destrava: onde investir mais (Shopify, Nuvemshop, marketplace, loja física).

2. Top 10 SKUs mais vendidos em quantidade.

• Pergunta: "Top 10 SKUs mais vendidos em quantidade nos últimos 90 dias."
• O LLM lê: tinyerp_v3_pedidos_detalhes_itens (produto_sku, quantidade) cruzado com tinyerp_v3_produtos (descricao).
• Decisão: curadoria de catálogo, escolha de SKUs para remarketing, decisão de bundle.

3. Pedidos aprovados sem faturamento.

• Pergunta: "Quais pedidos estão aprovados há mais de 7 dias sem faturar?"
• O LLM lê: tinyerp_v3_pedidos filtrando situacao = 'Aprovado' e datacriacao < hoje - 7d.
• Decisão: alerta operacional para destravar gargalo na expedição.

4. Top 20 clientes em valor nos últimos 12 meses.

• Pergunta: "Top 20 clientes que mais compraram em valor nos últimos 12 meses."
• O LLM lê: tinyerp_v3_pedidos_detalhes agrupando por cliente_id e cliente_nome.
• Decisão: lista para programa VIP, ofertas direcionadas, gestão de conta para B2B.

5. Sazonalidade de receita em 24 meses.

• Pergunta: "Mostre a receita mensal dos últimos 24 meses para eu ver sazonalidade."
• O LLM lê: tinyerp_v3_pedidos_detalhes agrupando por mês de datafaturamento.
• Decisão: planejamento de estoque, calendário de mídia paga, contratação sazonal.

Financeiro e DRE

6. Despesa por categoria DRE no mês.

• Pergunta: "Quanto gastei por categoria DRE neste mês?"
• O LLM lê: tinyerp_v3_contas_pagar_detalhes (categoria_descricao, valorpago, datacompetencia). A DRE só existe nessa tabela de detalhes; a tabela contas_pagar simples não traz categoria_id, e o MCP da Kondado já sabe rotear para a tabela certa.
• Decisão: onde cortar custo no mês seguinte, validação contábil com o escritório.

7. Fluxo de caixa projetado em 30 dias.

• Pergunta: "Fluxo de caixa projetado para os próximos 30 dias, receber versus pagar."
• O LLM lê: tinyerp_v3_contas_receber e tinyerp_v3_contas_pagar (datavencimento, saldo).
• Decisão: antecipação de recebíveis, capital de giro, agenda de pagamento de fornecedor.

8. Inadimplência por cliente.

• Pergunta: "Quais clientes têm conta a receber vencida há mais de 30 dias?"
• O LLM lê: tinyerp_v3_contas_receber (filtro datavencimento < hoje - 30d e saldo > 0) cruzado com _contas_receber_detalhes e contatos para puxar contato.
• Decisão: cobrança direcionada, prioridade do time de financeiro.

Estoque

9. SKUs em risco de ruptura no depósito principal.

• Pergunta: "Quais SKUs estão com saldo abaixo de 5 unidades no depósito principal?"
• O LLM lê: tinyerp_v3_estoque_depositos (disponivel, nome do depósito) cruzado com tinyerp_v3_produtos (sku, descricao). O MCP da Kondado entende que disponivel é diferente de saldo (saldo inclui reservado) e usa o campo certo automaticamente.
• Decisão: ordem de compra emergencial, redistribuição entre depósitos.

10. Capital parado em produto sem giro.

• Pergunta: "Quais produtos têm saldo alto e zero venda nos últimos 90 dias?"
• O LLM lê: tinyerp_v3_estoque cruzado em LEFT JOIN com tinyerp_v3_pedidos_detalhes_itens (filtrando vazio) e tinyerp_v3_produtos (precos_precocusto).
• Decisão: campanha de liquidação, ajuste de previsão de demanda, redirecionamento de orçamento de compra.

NFe e conferência fiscal

11. NFe pendente versus pedido faturado.

• Pergunta: "Quais pedidos foram faturados mas ainda não geraram NFe?"
• O LLM lê: tinyerp_v3_pedidos em LEFT JOIN com tinyerp_v3_notas por notas.origem_id = pedidos.id, filtrando os pedidos sem nota.
• Decisão: compliance fiscal, evitar autuação, fechar o mês com tudo conciliado.

A NFe traz ainda os campos da reforma tributária mapeados (valortotalibsuf para IBS e valortotalcbs para CBS), além de regimetributario e finalidade, todos disponíveis em tinyerp_v3_notas_detalhes para perguntas de tributação.

Combinações que valem a pena no mesmo Via Kondado

O MCP da Kondado consulta o seu Via Kondado inteiro, não só o Tiny. Quando você replica outras integrações para o mesmo destino, abre joins que respondem perguntas de negócio que nenhum dashboard isolado responde.

Tiny ERP + Meta Ads: custo por venda real.

• Pergunta: "Custo por venda real no último mês: quanto gastei no Meta Ads dividido pelos pedidos pagos no Tiny no mesmo período?"
• O LLM cruza tinyerp_v3_pedidos_detalhes com as tabelas de Meta Ads no mesmo Via Kondado.
• Decisão: ROAS real (não ROAS plataforma), realocação de orçamento entre campanhas.

Tiny ERP + Google Ads: ROAS real por campanha.

• Pergunta: "ROAS real por campanha do Google Ads: receita Tiny dividida pelo gasto Google no mesmo período."
• Mesma mecânica do anterior, com as tabelas de Google Ads no Via Kondado.
• Decisão: campanha que vende versus campanha que só queima budget.

Tiny ERP + RD Station CRM: funil lead a pedido.

• Pergunta: "Quantos leads do RD viraram pedido no Tiny no último trimestre?"
• O LLM cruza contatos do RD com tinyerp_v3_pedidos_detalhes pelo e-mail ou pela UTM.
• Decisão: qualidade de lead por origem, calibragem do funil de marketing.

Tiny ERP + Instagram orgânico: correlação engajamento e venda.

• Pergunta: "Picos de venda no Tiny coincidem com picos de engajamento no Instagram? Mostre os 10 dias com maior engajamento e a venda associada."
• O LLM faz análise temporal sem chave compartilhada, cruzando as duas séries por data.
• Decisão: validar mix de conteúdo orgânico, calendário editorial, parcerias com criador de conteúdo.

Por que o MCP da Kondado responde com mais precisão?

A diferença entre perguntar ao ChatGPT lendo um CSV exportado do Tiny e perguntar ao ChatGPT via MCP da Kondado está no contexto canônico. O MCP da Kondado conhece padrões da API do Tiny V3 que um LLM olhando dado solto erra em silêncio.

1. OAuth2 Keycloak gerenciado. O Tiny V3 usa Keycloak com refresh_token de validade aproximada de 24 horas e rotação a cada uso. A Kondado mantém o token vivo automaticamente (refresh sincronizado com a integração). Sem esse gerenciamento, uma integração direta perderia conexão diariamente.

2. Janela de atualização configurável. A Kondado aplica a janela __kdd_update_window para identificar pedidos alterados depois do range processado. O default vem dos parâmetros da própria integração e pode ser ajustado por necessidade. Em vez de aceitar dado frozen sem aviso, o MCP entende essa janela e contextualiza a resposta quando faz sentido.

3. Campos status-conditional tratados corretamente. Os campos data_pagamento, data_faturamento e codigo_rastreamento chegam NULL quando situacao não corresponde (não pago, não faturado, não enviado). O ChatGPT calculando "tempo médio de pagamento" sem entender isso retornaria um número sem sentido. O MCP da Kondado filtra automaticamente pelo situacao certo.

4. DRE só está em contas_pagar_detalhes e contas_receber_detalhes. A tabela tinyerp_v3_contas_pagar não tem categoria_id. Quem traz a DRE é a tabela de detalhes. O MCP da Kondado roteia "despesa por categoria" para a tabela certa sem você precisar saber.

5. Conexão NFe e pedido pelo origem_id, não pelo número. O número da NFe é incrementado pela Receita, o do pedido é interno do Tiny. Eles não coincidem. A FK correta é notas.origem_id = pedidos.id. Um LLM sem esse contexto cruzaria pelo número e devolveria associações erradas.

6. Categorias achatadas pelo sourcer. A API V3 do Tiny entrega categorias como árvore recursiva. A Kondado já achata a hierarquia, e o idCategoriaPai permanece disponível para reconstruir caminhos quando necessário.

7. Janelas past_future para contas a pagar e receber. O cursor dessas tabelas é a data de vencimento (não a data de alteração). A Kondado processa janelas separadas para passado e futuro para que o seu fluxo de caixa projetado seja preciso.

8. Fatiamento de 180 dias para carga histórica. Cargas históricas longas (3+ anos) são fatiadas em janelas de 180 dias por design da Kondado. Isso é o que faz a primeira sincronização levar horas em vez de falhar por timeout, e o MCP entende o estado da carga.

9. Versão V3 versus V2 legado. A Kondado mantém duas versões do conector. A V3 atual cobre 42+ cenários de replicação (entre tabelas parent e sub-tabelas depth=1) e usa REST + OAuth2. A V2 legado (tinyerp_* sem o v3) ainda existe para integrações antigas, usa XML e cobre 15 cenários de replicação. Os roteamentos entre as duas versões são automáticos no backend da Kondado.

Marketplaces no mesmo modelo de pedido

Quando o pedido vem de Mercado Livre, Shopee, Magalu ou outro marketplace, o Tiny V3 entrega os identificadores dentro do objeto ecommerce do pedido. O MCP da Kondado lê esses campos sem precisar de tabela separada por marketplace:

• ecommerce_canalvenda: nome do canal (Mercado Livre, Shopee, etc.).
• ecommerce_numeropedidocanalvenda: o número do pedido no marketplace.
• ecommerce_numeropedidoecommerce: o número do pedido no e-commerce.
• ecommerce_nome e ecommerce_id: identificação do canal.

A tabela tinyerp_v3_intermediadores (atualização completa) mapeia os intermediadores de marketplace caso você precise consultar a relação canal a canal.

Perguntas frequentes

O ChatGPT lê o Tiny ERP direto?

Não. O ChatGPT lê o Via Kondado (o destino de dados da Kondado) via MCP. A Kondado é quem replica o Tiny para esse destino na frequência que você escolher. Esse desenho protege a sua conta Tiny (sem credenciais expostas ao LLM) e dá ao assistente o contexto canônico das tabelas para responder com precisão.

Preciso saber SQL ou KSQL?

Não. Você pergunta em português, o LLM traduz para KSQL internamente, consulta o seu Via Kondado e devolve a resposta interpretada. Quem quiser ver a consulta gerada pode pedir ao ChatGPT que a mostre.

O MCP da Kondado escreve ou altera dados?

Não. O MCP da Kondado é somente leitura. O LLM pode consultar, agregar e cruzar, mas não muda nada no seu Tiny nem no Via Kondado.

Quanto tempo leva a primeira carga do Tiny?

Depende do volume histórico. A Kondado fatia a carga em janelas de 180 dias por integração e por endpoint. Para uma loja com 3+ anos de histórico, a primeira sincronização pode levar horas. As atualizações seguintes são incrementais e rápidas.

Funciona com Claude, Cursor e outros clientes MCP?

Sim. O endpoint https://mcp.kondado.io/mcp segue o padrão aberto do Model Context Protocol, então funciona com o Claude Desktop, o Claude pelo navegador, o Cursor, o Continue e qualquer outro cliente compatível. A configuração muda pouco entre eles (URL + API key).

Quais destinos do Via Kondado o MCP consulta?

O MCP da Kondado consulta o Via Kondado nos destinos suportados pela camada de dados: BigQuery, PostgreSQL, MySQL, Redshift, SQL Server, Excel, Google Sheets e Amazon S3. Você escolhe um na configuração da Kondado, replica o Tiny para lá e o MCP passa a consultar.

E se eu quiser combinar o Tiny com Meta Ads, Google Ads, RD CRM, Mercado Livre, Instagram?

Replique essas integrações para o mesmo Via Kondado. O MCP da Kondado lê tudo na mesma camada de dados e o LLM faz o cruzamento. ROAS real, funil lead a pedido, correlação orgânico e venda, todos esses recortes ficam disponíveis a partir do mesmo endpoint MCP.

Comece agora

Conecte seu Tiny ERP ao Via Kondado, escolha o destino (BigQuery, PostgreSQL, MySQL, Redshift, SQL Server, Excel, Google Sheets ou Amazon S3) e habilite o MCP da Kondado. O ChatGPT, o Claude, o Cursor e outros assistentes passam a responder em linguagem natural sobre as suas 42+ tabelas do Tiny: vendas por canal, DRE, fluxo de caixa, alerta de estoque, NFe pendente, ROAS real cruzando Meta Ads e Google Ads, funil de lead a pedido cruzando RD Station. Sem exportar planilha, sem montar consulta nova. Comece o teste grátis da Kondado e ative o MCP em minutos.