Pular para conteúdo

Pré-projeto — Integração PIED → X-Adm

Documento Pré-projeto (avaliação de viabilidade e caminhos)
Versão 1.0 — decidido
Data 2026-06-15 (decisão registrada em 2026-07-09)
Autor Gustavo Madruga
Status Aprovado — Caminho 2 (Robusto)
Aprovador Marcelo Garabeli

Para que serve este documento: avaliar a viabilidade de integrar a plataforma PIED ao ERP X-Adm, apresentar os caminhos possíveis (com prós, contras e custos) e pedir uma decisão. É propositalmente não-técnico. Aprovado este pré-projeto, segue-se o Projeto (documento técnico): endpoints, estrutura de dados, eventos, contratos e plano de testes.

::: {custom-style="Decisao"} ► DECISÃO DA DIRETORIA (2026-07-09 — Marcelo Garabeli): aprovado o Caminho 2 (Robusto) — servidor always-on na nuvem, com webhook (tempo real) + poll REST + entrega desacoplada via PowerSync. A implantação é em fases (§10): a Fase 1 (captura raw) entra em produção primeiro; a Fase 2 (transform + entrega ao X-Adm) segue com os dados reais já acumulados. O detalhamento técnico está no Projeto e na decisão 0002. :::


1. Sumário Executivo

A Maxsul (cliente da X-Adm) adquiriu uma empresa de painéis solares que opera na plataforma PIED. Hoje, cada venda feita na PIED é redigitada manualmente no X-Adm — produto, cliente e pedido — para só então emitir a nota fiscal. É lento, repetitivo e sujeito a erro. A Maxsul pediu à X-Adm uma integração que elimine essa redigitação.

É viável. A PIED disponibiliza todos os dados necessários por uma API, e confirmamos que conseguimos trazê-los para o X-Adm de forma automática e auditável.

Há dois caminhos: - Caminho 1 (Simples): um programa que puxa os dados da PIED periodicamente ou sob demanda. Baixo custo e risco, cobre 100% dos dados — mas sem tempo real. - Caminho 2 (Robusto): um servidor na nuvem que recebe os pedidos em tempo real e mantém tudo sincronizado automaticamente com o X-Adm. Mais robusto, com custo/esforço um pouco maiores.

Decisão solicitada: aprovar o início do projeto, definindo qual caminho seguir.


2. Contexto e problema

Quem é quem. A X-Adm fornece à Maxsul (nosso cliente) o ERP com toda a parte fiscal — notas, cadastros, impostos. A Maxsul adquiriu uma empresa de painéis solares, e essa empresa opera na plataforma PIED, onde cadastra produtos, clientes e registra as vendas (pedidos).

A dor. Hoje, cada venda fechada na PIED é redigitada manualmente no X-Adm — todos os cadastros (produto, cliente, pedido) — para só então emitir a nota fiscal. É lento, repetitivo, sujeito a erro e consome tempo da equipe da Maxsul.

A demanda. A própria Maxsul solicitou à X-Adm que automatize essa ponte, eliminando a redigitação. O objetivo é um fluxo automático, incremental (só o que muda) e auditável da PIED para o X-Adm.

📌 Nota de atenção — benefício ainda qualitativo. Hoje o ganho está descrito apenas de forma qualitativa ("elimina a redigitação, ganha tempo"). Seria interessante quantificar o tempo economizado, pela fórmula:

Economia (h/mês) = pedidos fechados/dia × tempo de redigitação por pedido (min) × dias úteis/mês ÷ 60

Pressuposto inicial: funil de ~5 orçamentos/dia → ~1 pedido fechado/dia; ~22 dias úteis/mês. Falta medir com a Maxsul o tempo de redigitação por pedido (cliente + produtos + pedido). Exemplo ilustrativo (a confirmar): 1 pedido/dia × 20 min × 22 dias ÷ 60 ≈ ~7 h/mês. Quanto maior o volume de pedidos, maior o retorno — vale levantar o número real antes da decisão.


3. Objetivo e escopo

Objetivo: trazer da PIED para o X-Adm, de forma automática e confiável, os dados de produtos, clientes e pedidos, prontos para emissão de NF e contabilidade.

3.1 Dentro do escopo

  • Importação automática, incremental e auditável de produtos, clientes e pedidos da PIED → X-Adm.
  • Implementar uma das duas modalidades de integração:
  • Integração simples — o X-Adm consome a API REST da PIED de tempos em tempos ou sob demanda (Caminho 1).
  • Integração robusta — servidor em nuvem com comunicação em tempo real (Caminho 2).

3.2 Fora do escopo (nesta fase)

  • Orçamentos no X-Adm (podem ser coletados para uso interno, mas não entram no ERP).
  • Devolver dados do X-Adm para a PIED (status/preço/estoque).
  • Definição técnica detalhada (endpoints, estrutura de dados, eventos) — fica para o Projeto.
  • Regras fiscais finais da baixa no núcleo do ERP.

3.3 Premissas

  • A PIED disponibiliza os dados via API com token de acesso.
  • A infraestrutura de nuvem já existe (Nuvem Wiechert).
  • Há pontos a confirmar com PIED/X-Adm que não impedem iniciar (§9).

4. Partes interessadas

Papel Quem
Cliente / solicitante Maxsul
Operação de origem (vendas na PIED) Empresa de painéis solares (adquirida pela Maxsul)
Fornecedor da solução / execução X-Adm — Equipe de Integração
Patrocínio / decisão (interno X-Adm) Diretoria X-Adm
Fonte dos dados PIED (plataforma / suporte)
Destino dos dados ERP X-Adm (usado pela Maxsul)
Infraestrutura Nuvem Wiechert

5. Viabilidade — o que já confirmamos

  • A PIED disponibiliza todos os dados necessários por API. Produtos, clientes e pedidos: viável.
  • Existem dois jeitos de receber os dados:
  • Puxar (perguntar "o que mudou?" de tempos em tempos) — cobre tudo.
  • Receber aviso em tempo real (a PIED avisa quando um pedido muda) — cobre só pedidos, com algumas lacunas; não cobre produtos.
  • Puxar já é suficiente para ter todos os dados. O tempo real é ganho de agilidade, não requisito de completude.
  • Pontos a confirmar com PIED/X-Adm existem, mas nenhum impede começar (§9).

As APIs da PIED foram validadas (a nível de documentação/contrato) e a viabilidade do projeto está OK. Para sacramentar restam duas verificações, que serão feitas na fase de Projeto: (1) acesso direto à API da PIED com token real (confirmar payloads e comportamento ao vivo); e (2) resolver as lacunas de mapeamento de dados (campos com regra de negócio em aberto — ../../PENDENCIAS.md). Nenhuma delas muda a conclusão de viabilidade.

Os contratos da PIED e a modelagem do X-Adm que sustentam esta viabilidade estão nos Anexos A–C (ao final do documento).


6. Caminho 1 — Simples (puxar via REST)

Como funciona: um programa Java enxuto (PiedRestClient) é acionado de tempos em tempos (agendado) ou sob demanda (o próprio X-Adm dispara). Conecta na PIED, baixa produtos/clientes/pedidos e grava no banco do X-Adm. Não exige nada rodando o tempo todo.

flowchart TB
    XADM["X-Adm<br/>(agendado ou sob demanda)"] -->|dispara| PRC["PiedRestClient<br/>(Java)"]
    PRC -->|puxa produtos / clientes / pedidos| PIED["PIED API"]
    PRC -->|grava| DB[("Banco do X-Adm")]

Prós - Mais simples e mais barato: não precisa de servidor ligado 24 horas. - Menos peças, menos pontos de falha; manutenção fácil. - Roda agendado ou sob demanda — só consome recurso quando executa. - Já traz 100% dos dados necessários. - Fácil de reexecutar se falhar; controle total do ritmo (respeita o limite de uso da API).

Contras - Sem tempo real: dados só atualizam quando o programa roda. - Disparo sob demanda gera uma espera (aciona e aguarda). - A frequência precisa ser calibrada (rara demais atrasa; frequente demais bate no limite da API).

Quando faz sentido: quando atualizar "de tempos em tempos" atende o negócio. Ideal para começar e validar com baixo custo e risco.


7. Caminho 2 — Robusto (servidor na nuvem + sincronização)

Como funciona: um servidor na nuvem ligado o tempo todo que (a) recebe avisos instantâneos da PIED quando um pedido muda (tempo real) e (b) também sabe puxar o resto via REST (reaproveitando o programa do Caminho 1). Mantém um banco na nuvem sempre atualizado. Um segundo programa Java, com sincronização automática (PowerSync), repassa as mudanças ao X-Adm — sem o X-Adm precisar perguntar.

flowchart TB
    PIED["PIED"] -->|avisa em tempo real| SRV["Servidor na nuvem<br/>(webhook + REST)"]
    SRV -->|puxa o resto| PIED
    SRV -->|grava| DBC[("Banco na nuvem")]
    DBC -->|sincronização automática| JAVA["Programa Java<br/>(PowerSync)"]
    JAVA -->|envia| XADM["X-Adm"]

Prós - Tempo real para pedidos. - O X-Adm recebe as atualizações automaticamente — não precisa puxar nem esperar. - Mais resiliente: se a conexão cair, recupera sozinho e não perde atualização. - Desacoplado: coleta (nuvem) e entrega (X-Adm) evoluem separadamente. - Cobre tudo (tempo real + puxar o resto).

Contras - Mais peças (servidor sempre no ar, banco na nuvem, sincronização) → mais a manter/monitorar. - Maior esforço inicial. - A tecnologia de sincronização exige uma pequena parte em Kotlin (detalhe técnico isolado). - Pontos em aberto com a PIED pesam mais aqui (segurança e reenvio dos avisos em tempo real).

Quando faz sentido: quando o negócio precisa dos pedidos quase em tempo real no X-Adm e/ou não se quer depender de alguém acionar a sincronização.


8. Comparativo

Critério Caminho 1 — Simples (REST) Caminho 2 — Robusto (Servidor)
Tempo real (pedidos) ❌ Periódico / sob demanda ✅ Sim
Cobertura de dados ✅ Completa ✅ Completa
Custo de infraestrutura 🟢 Baixo 🟢 Baixo (infra já existe na Nuvem Wiechert)
Esforço de desenvolvimento 🟢 Baixo 🟡 Médio
Manutenção / nº de peças 🟢 Simples 🟡 Médio (simples, porém com mais peças)
Resiliência 🟢 Boa (reexecuta) 🟢 Alta (auto-recuperação)
X-Adm precisa "puxar"? Sim (agendado/sob demanda) Não (recebe automático)
Dependências externas em aberto 🟢 Poucas 🟡 Mais (segurança do webhook)

9. Riscos e pontos a confirmar

  • Com a PIED: segurança e política de reenvio dos avisos em tempo real; limites de uso da API; existência de ambiente de testes.
  • Com a X-Adm: algumas regras fiscais/de negócio (ex.: classificação fiscal do pedido, condição de pagamento).
  • Mitigação: o Caminho 1 depende de poucos desses pontos; nenhum impede iniciar a Fase 1. O detalhamento técnico e as prioridades estão em ../../PENDENCIAS.md.

10. Recomendação — caminho em fases

Os dois caminhos compartilham o mesmo núcleo (o cliente REST do Caminho 1 é reaproveitado dentro do servidor do Caminho 2). Começar simples não é trabalho jogado fora.

Fase O quê Esforço Estimativa¹
1 — Integração simples (Caminho 1) Puxar tudo da PIED e popular o X-Adm. 🟢 Baixo ~1 semana
2 — Tempo real (Caminho 2) Servidor na nuvem + sincronização automática; reaproveita a Fase 1. 🟡 Médio ~2 semanas

¹ Estimativas preliminares (chute de ordem de grandeza), a confirmar no Projeto (fase técnica).

Assim a diretoria decide o investimento em tempo real depois de ver a viabilidade comprovada.

Valor estratégico do Caminho 2 (além desta integração)

Hoje o X-Adm tem bem resolvido o fluxo de SAÍDA de dados: extração em batch para BI e em tempo real para a Nota Sul Plata. O que ainda é frágil é o X-Adm RECEBER dados de APIs externas — não há um caminho consolidado.

O Caminho 2 não serve só para a PIED: ele pavimenta e solidifica esse processo de entrada de dados externos (servidor na nuvem + sincronização confiável + idempotência). Construído uma vez, vira base reutilizável para futuras integrações de entrada (outros fornecedores, marketplaces, parceiros), reduzindo custo e risco de cada próxima integração. Parte do investimento é, portanto, infraestrutura estratégica, não custo exclusivo desta integração.


11. Critérios de sucesso

  • Os dados da PIED (produto, cliente, pedido) chegam ao X-Adm de forma automática e correta.
  • A sincronização não gera retrabalho nem duplicidade (atualiza só o que muda).
  • Elimina a redigitação manual hoje feita pela Maxsul para emitir a nota fiscal.

12. Decisão solicitada e próximos passos

::: {custom-style="Decisao"} ► DECISÃO SOLICITADA À DIRETORIA: aprovar uma das opções — Fase 1 (mais rápida e barata, ~1 semana) ou Fase 2 (mais robusta, pavimentando o caminho para integrações futuras, ~2 semanas). :::

Após aprovação: elaboração do Projeto (documento técnico) — define endpoints, estrutura de dados, eventos, contratos, plano de testes e de implantação. O Projeto também sacramenta a viabilidade com acesso direto à API da PIED (token real) e a resolução das lacunas de mapeamento (../../PENDENCIAS.md). Em seguida, execução da fase aprovada.


13. Glossário

Termo Significado
Maxsul Cliente da X-Adm que solicitou a integração; adquiriu a empresa de painéis solares que opera na PIED.
PIED Plataforma B2B onde acontecem os negócios (orçamentos/pedidos de energia solar). Fonte dos dados.
API / REST Forma de um sistema oferecer dados a outro de forma programática.
Webhook Aviso automático que a PIED envia quando algo muda (base do "tempo real").
PowerSync Tecnologia que mantém dados sincronizados automaticamente entre um banco na nuvem e um programa.
Idempotência Garantia de que reprocessar o mesmo dado não cria duplicidade.
Nuvem Wiechert Infraestrutura de nuvem já existente onde os serviços rodam.

Anexos

Documentos-base que fundamentam o escopo (anexados na sequência):

  • Anexo A — Contrato da API REST da PIED (001-pied-rest-api.md) — endpoints, autenticação e JSON de request/reply das principais chamadas.
  • Anexo B — Contrato de Webhook da PIED (002-pied-webhook.md) — eventos, JSON do POST recebido, lacunas e segurança.
  • Anexo C — Modelagem do envio ao X-Adm (003-xadm-modelagem.md) — JSON que o X-Adm espera (cliente, produto, pedido).