329 lines
13 KiB
Plaintext
329 lines
13 KiB
Plaintext
PLANO DE ENTREGA
|
||
|
||
|
||
|
||
Sistema DTF
|
||
Plano de entrega
|
||
Uma operação em que o cliente envia a arte, recebe análise, paga e
|
||
acompanha a produção sem depender de WhatsApp, pastas ou repasse
|
||
manual.
|
||
|
||
|
||
|
||
OBJETIVO DECISÃO DE ARQUITETURA
|
||
|
||
|
||
Portal e Kanban online +
|
||
Transformar capacidade ociosa Cloudflare R2 + VPS existente. A
|
||
em atendimento e produção 24 impressão continua manual na
|
||
horas. fábrica.
|
||
|
||
|
||
|
||
Consolidação das discussões técnicas e comerciais - setembro de 2026
|
||
DTF Dropstar - plano de entrega
|
||
|
||
|
||
|
||
CONTEXTO
|
||
|
||
|
||
O problema que vamos resolver
|
||
A sala de DTF tem capacidade instalada muito maior que a produção atual. O gargalo não é a máquina:
|
||
é o fluxo entre o pedido, a arte, o designer e a sala. Hoje o cliente envia arquivo no WhatsApp, o
|
||
atendimento repassa, o designer descobre problemas tarde e o status fica escondido em pastas de rede.
|
||
|
||
O projeto resolve quatro falhas do processo:
|
||
• Recebimento limitado pelo horário: um cliente que chega no fim do dia espera até o turno seguinte.
|
||
• Arquivo sem rastreabilidade: WhatsApp e nomes digitados manualmente facilitam perda e erro.
|
||
• Arquivo ruim chega tarde ao designer: qualidade, dimensão e transparência são verificadas depois de
|
||
consumir tempo humano.
|
||
• Produção sem números: não há registro confiável de espera, velocidade real, fila ou retrabalho.
|
||
|
||
|
||
ANTES DEPOIS
|
||
|
||
|
||
Pedido e arte circulam por WhatsApp e pastas. Site DTF recebe a arte, analisa, precifica e registra o
|
||
fluxo.
|
||
|
||
|
||
Designer corrige indiscriminadamente. Arte pronta segue rápido; exceções vão para atendimento
|
||
humano.
|
||
|
||
|
||
Sala não enxerga fila real nem tempos. Kanban online organiza a fila e registra cada movimento
|
||
manualmente.
|
||
|
||
|
||
|
||
|
||
Página 2
|
||
DTF Dropstar - plano de entrega
|
||
|
||
|
||
|
||
MODELO OPERACIONAL
|
||
|
||
|
||
Como será a jornada do pedido
|
||
|
||
Escolhe o produto, envia a arte e vê o valor conforme as regras comerciais
|
||
Cliente entra no site DTF
|
||
1 já configuradas.
|
||
|
||
|
||
Calcula a metragem e prepara o pedido. O pré-flight automático será
|
||
Sistema registra a arte
|
||
2 validado depois da entrega, com arquivos reais.
|
||
|
||
|
||
O checkout é do Mercado Pago; os dados do cartão não passam pelo nosso
|
||
Cliente paga
|
||
3 servidor.
|
||
|
||
|
||
Depois da confirmação do pagamento, o pedido é criado no Tiny e aparece
|
||
Pedido entra no sistema
|
||
4 no Kanban.
|
||
|
||
|
||
O operador baixa o arquivo final no Kanban, importa no FlexiPRINT e
|
||
Equipe baixa e imprime
|
||
5 atualiza o card.
|
||
|
||
|
||
|
||
|
||
Onde o WhatsApp entra
|
||
O WhatsApp deixa de ser o lugar onde a arte é enviada. Ele serve para avisar o cliente: pagamento
|
||
aprovado, pedido em produção, pedido pronto ou necessidade de correção. Quando houver problema, a
|
||
mensagem leva o cliente de volta para o site.
|
||
|
||
Cuidados na automação: se Mercado Pago, Tiny ou WhatsApp reenviar um aviso por falha, o sistema confere antes de
|
||
agir. Assim, não cria dois pedidos nem manda a mesma mensagem duas vezes.
|
||
|
||
|
||
|
||
|
||
Página 3
|
||
DTF Dropstar - plano de entrega
|
||
|
||
|
||
|
||
PRODUÇÃO
|
||
|
||
|
||
Arquitetura de software e infraestrutura
|
||
Todo o sistema roda na nuvem: recebe, processa, integra e disponibiliza o arquivo final. A fábrica acessa
|
||
o Kanban pelo navegador e baixa o arquivo quando for produzir; não há componente instalado na rede
|
||
interna.
|
||
|
||
CLIENTE E INTEGRAÇÕES NUVEM / VPS EQUIPE DA FÁBRICA
|
||
|
||
|
||
|
||
|
||
Site DTF API FastAPI R2 Kanban online
|
||
arte, preço e checkout pedido, upload originais e fila, status e
|
||
acompanhamento do pedido e integrações arte final privada download seguro
|
||
|
||
|
||
|
||
|
||
Integrações externas Worker PostgreSQL Operador
|
||
Mercado Pago · Tiny/Olist antivírus e pedidos, jobs baixa e importa
|
||
WhatsApp Business pré-flight e histórico no FlexiPRINT
|
||
|
||
|
||
|
||
|
||
NUVEM Site DTF, Kanban online, API FastAPI, worker, ClamAV, PostgreSQL e Cloudflare R2.
|
||
|
||
|
||
FÁBRICA Navegador, operador e FlexiPRINT atual. O arquivo é baixado e importado manualmente.
|
||
|
||
|
||
TERCEIROS Mercado Pago, Tiny/Olist e WhatsApp Business API.
|
||
|
||
|
||
• Upload grande: o navegador manda o arquivo direto para o R2, em partes. O VPS não precisa receber 5
|
||
GB de uma vez.
|
||
• Fila: o banco guarda o que precisa ser analisado, enviado ao Tiny, avisado no WhatsApp ou apagado no
|
||
prazo certo.
|
||
• Segurança: o arquivo entra em quarentena, passa pelo antivírus e só depois é analisado e liberado no
|
||
Kanban.
|
||
• Se a fábrica ficar sem internet: o site continua no ar. A equipe apenas não consegue baixar arquivo
|
||
novo ou atualizar o Kanban até a conexão voltar.
|
||
|
||
|
||
|
||
|
||
Página 4
|
||
DTF Dropstar - plano de entrega
|
||
|
||
|
||
|
||
CLOUDFLARE
|
||
|
||
|
||
R2: custos e retenção
|
||
O R2 é onde os arquivos ficam guardados. Ele é privado: o operador só baixa pelo Kanban, com link
|
||
temporário. O custo vem principalmente da média de GB guardados no mês; leitura e gravação
|
||
costumam pesar bem menos. O download não tem cobrança de saída de dados.
|
||
|
||
|
||
MÉDIA ARMAZENADA R2 / MÊS APROX. EM R$*
|
||
|
||
|
||
100 GB US$ 1,35 R$ 7
|
||
|
||
|
||
500 GB US$ 7,35 R$ 38
|
||
|
||
|
||
1 TB US$ 14,85 R$ 76
|
||
|
||
|
||
3 TB US$ 44,85 R$ 230
|
||
|
||
* Referência de US$ 1 = R$ 5,13; câmbio, impostos e tarifas do meio de pagamento podem variar.
|
||
|
||
|
||
ARTEFATO PRAZO REGRA
|
||
|
||
|
||
Upload multipart incompleto 1 dia Abortado automaticamente.
|
||
|
||
|
||
Recusado ou infectado 3 dias Suporte pode conferir; depois apaga.
|
||
|
||
|
||
Original do cliente até 7 dias Após aprovação, não fica guardado sem necessidade.
|
||
|
||
|
||
Arte pronta para impressão máx. 30 dias Prazo conta do primeiro upload; permite correção ou
|
||
reimpressão recente.
|
||
|
||
|
||
Histórico e métricas banco Sem manter a imagem.
|
||
|
||
|
||
Decisão: não haverá biblioteca infinita de artes. Após o prazo, o cliente reenvia o arquivo; o pedido e sua
|
||
rastreabilidade permanecem registrados.
|
||
|
||
|
||
|
||
|
||
Página 5
|
||
DTF Dropstar - plano de entrega
|
||
|
||
|
||
|
||
OPERAÇÃO, PUBLICAÇÃO E CONTINUIDADE
|
||
|
||
|
||
Como fica em produção
|
||
A primeira entrega será operada como uma única aplicação na VPS. Portal, Kanban, processamento e
|
||
banco seguem o mesmo ciclo de publicação, com acesso da fábrica exclusivamente pelo navegador.
|
||
Isso reduz pontos de manutenção e mantém a operação independente da rede interna.
|
||
|
||
|
||
AMBIENTE COMPONENTES OPERAÇÃO
|
||
|
||
|
||
Sistema DTF site DTF, Kanban online, API, processamento, antivírus, banco VPS com armazenamento
|
||
de dados e cópia diária de segurança persistente; operação e
|
||
acompanhamento
|
||
centralizados
|
||
|
||
|
||
|
||
|
||
Publicação com controle
|
||
• Toda alteração passa por testes automáticos antes de poder chegar ao ambiente de produção.
|
||
• Cada publicação fica identificada pela versão do código, permitindo restaurar rapidamente a versão
|
||
anterior se houver qualquer problema.
|
||
• As mudanças são conferidas primeiro em ambiente de validação e só então liberadas para a operação.
|
||
• Ao final da publicação, uma verificação confirma que os serviços essenciais voltaram a responder antes
|
||
de encerrar o processo.
|
||
• Credenciais de storage, pagamentos, integrações e banco permanecem fora do código e são tratadas
|
||
como dados restritos do ambiente.
|
||
|
||
|
||
Acompanhamento operacional
|
||
A rotina de operação acompanha disponibilidade do site e do Kanban, andamento da fila de processamento, falhas de
|
||
integração e resultado das cópias de segurança. Assim, qualquer desvio é identificado antes de interromper o
|
||
atendimento ou a produção.
|
||
|
||
|
||
|
||
|
||
Página 6
|
||
DTF Dropstar - plano de entrega
|
||
|
||
|
||
|
||
MVP EM ATÉ 3 SEMANAS
|
||
|
||
|
||
Roadmap de implementação
|
||
O cronograma considera a base de código existente e dedicação integral. A prioridade é concluir o fluxo
|
||
completo - envio, pagamento, frete, pedido e acompanhamento - antes de qualquer integração com as
|
||
máquinas. As regras comerciais seguem exatamente o que já está configurado no Site DTF.
|
||
|
||
|
||
QUANDO ENTREGA RESULTADO
|
||
|
||
|
||
Sem. 1 Infraestrutura e upload VPS, domínio, banco, R2, upload multipart, antivírus e base do
|
||
serviço.
|
||
|
||
|
||
Sem. 2 Pagamento, frete e pedido Mercado Pago, cotação de frete, criação idempotente no Tiny,
|
||
geração do arquivo final e estados principais do Kanban.
|
||
|
||
|
||
Sem. 3 Kanban e entrega Kanban online, download seguro, mensagens de status no WhatsApp,
|
||
retenção de 30 dias e orientação à operação.
|
||
|
||
|
||
|
||
|
||
Fora da primeira entrega
|
||
A primeira entrega termina no download do arquivo final pelo Kanban e na orientação de uso à operação. Integração
|
||
direta com FlexiPRINT, agente dentro da fábrica, pasta monitorada, painel de sala e relatórios avançados não fazem
|
||
parte deste prazo. O pré-flight automático será validado depois da entrega, com arquivos e impressão reais. A fábrica
|
||
mantém esses recursos no ambiente atual; após a entrega, damos suporte e avaliamos mudanças conforme a
|
||
necessidade.
|
||
|
||
|
||
O que fica com a operação
|
||
• Acessar o Kanban, baixar o arquivo final e importá-lo manualmente no FlexiPRINT atual.
|
||
• Realizar os testes de impressão e informar qualquer diferença encontrada no arquivo ou no resultado
|
||
impresso.
|
||
• Manter computadores, FlexiPRINT, perfis de impressão, impressoras e eventuais pastas internas
|
||
funcionando.
|
||
• A conexão local é necessária apenas para a equipe acessar o Kanban e baixar o arquivo na fábrica. Se
|
||
ela cair, portal, pagamentos, uploads e fila continuam ativos na nuvem; a produção retoma quando o
|
||
acesso local voltar.
|
||
• Comunicar mudanças de preços, frete ou regras operacionais que precisem ser refletidas no sistema.
|
||
|
||
|
||
O que precisamos para começar
|
||
• Credenciais do Mercado Pago, incluindo a configuração do webhook para confirmação de pagamento.
|
||
• Dados da integração de frete: plataforma(s) já utilizada(s), acesso à API, CEP de origem, serviços
|
||
oferecidos, regra de cobrança e referência de peso e dimensões por pacote.
|
||
|
||
|
||
Antes de começar
|
||
Com esses acessos e dados liberados, a primeira semana pode começar. A tabela, os descontos e as regras comerciais
|
||
já existentes no Site DTF serão mantidos. Tiny/Olist e WhatsApp já estão disponíveis; durante o desenvolvimento será
|
||
definida a ligação técnica dessas integrações com os eventos do pedido. A fábrica valida a impressão depois, baixando
|
||
o arquivo final pelo Kanban.
|
||
|
||
|
||
|
||
|
||
Página 7
|
||
|