CADERNO FUNCIONAL · PROPOSTA PARA APROVAÇÃO
Escopo, telas, regras e entregas — sem itens implícitos
Este caderno enumera o objeto de E1–E4, cadastros necessários, integrações, critérios de validação e limites. O que não estiver listado não é requisito assumido: entra somente mediante solicitação e aprovação formal de mudança.
MAPA DO PRODUTO
Quatro entregas; cada tela tem cadastro, regra e evidência
Ticketeria + administração
Usuários/perfis, evento, categorias/lotes, pedido/checkout PSP, pagamento, ingresso digital, validação, cadastro do comprador/CRM, painel e split suportado no fluxo da ticketeria.
Ver abas e funções →Cashless próprio
Cartões/leitores compatíveis, conta de créditos, carga PSP, ledger, catálogo/PDV, consumo, troca/resgate interno, bloqueio, ajustes autorizados, split interno definido pelo contratante e conciliação.
Ver abas e funções →Quiosques/estacionamento
Inventário individual de POS Stone, vínculo terminal–local–PDV–recebedor, regra de split por POS, teste real/sandbox e evidência financeira por terminal.
Ver abas e funções →Integração e prontidão
Testes ponta a ponta, carga de 10 TPS, permissões, reconciliação, implantação, documentação/runbook, treinamento, ensaio e decisão go/no-go.
Ver abas e funções →O objeto contratual é a lista de funcionalidades e critérios descritos neste caderno, em conjunto com a proposta e o contrato.
Taxas, recebedores, políticas, conteúdo, equipamentos e credenciais são fornecidos/aprovados pelo contratante; o provedor habilita sua própria conta/API.
Nova aba, relatório, integração, regra ou tipo de hardware exige pedido de mudança com impacto em preço, prazo, teste e aceite antes da execução.
Fluxo financeiro sem mistura: ingressos, pagamento da recarga, crédito no ledger, consumo/resgate, split interno calculado e transferência bancária são eventos distintos e mantêm identificadores e estados próprios.
ENTREGA E1 · 20 OUT–19 NOV
Ticketeria: abas, cadastros, integrações e aceite
Gate de base: 28/10 · entrega/aceite funcional E1: 19/11. Não inclui assentos numerados, app nativo, CRM de marketing ou outro PSP além do PSP contratado sem aditivo.
Aba: Usuários e permissões
- Funções incluídas
- Criar/editar/desativar usuário; autenticar; atribuir perfis Administrador, Financeiro, Supervisor e Operador; restringir ações por perfil; encerrar/revogar acesso; registrar auditoria de alterações críticas.
- Cadastros
- Nome, e-mail/login, estado, perfil, evento/escopo de acesso e responsável aprovador. Senhas são definidas em fluxo seguro; não ficam no checklist.
- Dependências / aceite
- Contratante indica usuários, perfis e aprovadores. Testar permissão permitida e negada em servidor; evidência com ator, horário, ação e resultado. Não inclui SSO corporativo sem previsão.
Aba: Configuração geral
- Funções incluídas
- Configuração do evento ativo, fuso/data, estados, parâmetros operacionais listados e vínculo de pontos de venda às áreas do evento.
- Cadastros
- Dados legais/comerciais do evento, contatos operacionais, setores, bares, quiosques e respectivos responsáveis.
- Dependências / aceite
- Cliente entrega dados aprovados e domínio. Auditoria registra quem alterou configuração e quando. Nuvem, domínio, DNS, e-mail/SMS e suas licenças são externos salvo contrato.
Aba: Eventos e locais
- Funções incluídas
- Criar/editar/publicar/encerrar evento; definir nome, datas, fuso, local, descrição, capacidade informada e estado; cadastrar setores e associar oferta ao evento.
- Cadastros do contratante
- Nome oficial, datas/horários, endereço, capacidade, textos, logotipo/arte licenciada pelo cliente, contatos e estrutura de setores/pontos de venda.
- Integrações / aceite
- Domínio e DNS são administrados pelo titular indicado pelo cliente. Teste de criação, edição autorizada, publicação e isolamento entre eventos.
Aba: Categorias e lotes
- Funções incluídas
- Cadastrar categoria/lote; preço, estoque total, limite por pedido, início/fim de venda, estado ativo/inativo; mostrar disponibilidade; impedir venda acima do estoque com reserva/transição segura.
- Cadastros do contratante
- Nome, descrição, valor, quantidade, período, taxas/comissões, política de venda e limite por comprador.
- Integrações / aceite
- Sem integração de assento numerado. Testar lote futuro/encerrado, estoque esgotado e concorrência na última unidade; demonstrar que a venda respeita o estoque disponível.
Aba pública: Seleção e pedido
- Funções incluídas
- Selecionar evento/oferta e quantidades; validar janela/estoque; coletar dados do comprador/participante definidos; calcular subtotal, taxas declaradas e total; criar pedido com ID único e estado rastreável.
- Cadastros
- Campos obrigatórios, regras de CPF/idade, identificação do participante, consentimentos e mensagens de compra são definidos pelo contratante.
- Aceite
- Pedido associado a evento, lote, itens, comprador e valor; requisição repetida não duplica pedido/venda. Sem funcionalidade de fila virtual presumida.
Aba pública: Checkout PSP
- Funções incluídas
- Solicitar cobrança no PSP contratado; apresentar estado pendente/aprovado/recusado/expirado; receber webhook/consulta segura; conciliar pedido e pagamento; tratar timeout/repetição de forma idempotente.
- Integração
- Uma integração PSP aprovada para ticketing, definida no contrato; sandbox, credenciais de teste e produção, documentação e conta recebedora habilitada.
- Limite / aceite
- O PSP processa meios elegíveis e dados de cartão. MS não armazena PAN/CVV. Sem acesso ou aprovação do PSP, status de integração fica bloqueado, não “concluído”.
Aba: Ingressos e participantes
- Funções incluídas
- Após confirmação válida, emitir ingresso digital único; associar ao pedido/participante; exibir/consultar estado; cancelar ou invalidar conforme autorização; registrar histórico.
- Cadastros
- Tipo de ingresso, dados do participante, texto/regras de uso e política de transferência/alteração definidos pelo cliente.
- Aceite / limite
- Pagamento pendente/recusado não emite ingresso. QR/código único; segunda leitura não autoriza reutilização. Envio por e-mail depende de serviço SMTP/terceiro configurado; acesso/download no portal incluído. Não inclui emissão física/impressora.
Aba: Validação de acesso
- Funções incluídas
- Leitor web em dispositivo compatível; consultar autenticidade/estado; liberar ou negar; registrar ingresso, evento, data/hora, operador e dispositivo/porta quando informado.
- Dependências
- Cliente fornece dispositivos, rede, quantidade de portões, operadores e plano de contingência. Validar câmera/browser e volume antes do evento.
- Limite / aceite
- Teste de válido, usado, cancelado, inválido e concorrência. Modo offline, app nativo, catraca e sincronização posterior não estão incluídos sem especificação e aditivo.
Aba: Regra de split da ticketeria
- Funções incluídas
- Informar/registrar recebedores e regra de distribuição na venda de ingresso; validar soma/base, manter versão/aprovador, enviar no pedido quando o PSP habilitar e registrar retorno.
- Cliente define
- Beneficiários/CNPJ, percentual/valor, base bruta/líquida, taxas, chargebacks, estornos, saldo residual, vigência e regra por evento/categoria.
- Dependência / limite
- Split executado no fluxo do PSP somente se conta, contrato e API autorizarem. Painel registra configuração/estado; não garante liquidação ou transferência bancária. Regra final e credenciamento até 23/10.
Aba: Financeiro da ticketeria
- Funções incluídas
- Consultar pedidos, pagamentos, taxas informadas, cancelamentos/reembolsos, parcelas de split e estados conhecidos; separar bruto, taxas, líquido calculado, liquidado e repassado.
- Cadastros / origem
- IDs e estados são obtidos do PSP; despesas/custos de evento são cadastrados por usuário autorizado e identificados como previstos ou realizados.
- Aceite
- Relatório reconcilia conjunto de transações de teste com PSP e memória de cálculo. Não tratar “aprovado” como “depositado”.
Aba: Compradores / CRM operacional
- Funções incluídas
- Pesquisar comprador e pedidos, consultar histórico e exportar dados permitidos por perfil; vincular participante, ingresso e pedido.
- Cadastros
- Somente campos necessários aprovados pelo cliente; base legal, aviso de privacidade, retenção e atendimento definidos pelo controlador/contratante.
- Limite
- Não inclui automação de campanhas, disparo de marketing, enriquecimento externo ou CRM comercial avançado sem item explícito.
Aba: Painel e relatórios E1
- Indicadores incluídos
- Ingressos/pedidos por evento, categoria/lote e período; pedidos por estado; bruto, taxas disponíveis, líquido calculado, cancelamentos e split por estado.
- Filtros/exportação
- Evento, período, lote e estado; exportação tabular CSV dos campos exibidos.
- Aceite
- Comparar totais/filtros com conjunto de teste conhecido; respeitar perfil, registrar exportação quando sensível e não misturar liquidado com calculado.
SUBENTREGAS E1E1.1 ambientes/perfis · E1.2 eventos/lotes · E1.3 pedido/PSP · E1.4 ingresso/CRM/acesso · E1.5 dashboard/custos/split · E1.6 UAT. Gate base 28/10; entrega/aceite E1 19/11.
ENTREGA E2 · 16–27 NOV
Cashless próprio: desenvolvimento do zero
Não será utilizada nem integrada uma plataforma cashless pronta. O código/serviço, regras do ledger, painel e PDV cashless são construídos para este evento; PSP e hardware são dependências específicas.
Aba: Cartões e carteiras
- Funções incluídas
- Registrar ID do cartão; associar a uma carteira/cliente; ativar, bloquear, perder, substituir e consultar estado/saldo; manter histórico de vínculo.
- Cadastros
- Identificador de cartão, tecnologia, situação, carteira/cliente, data de emissão/ativação, operador e motivo de bloqueio/substituição.
- Dependência / aceite
- Contratante escolhe fornecedor e entrega marca/modelo/protocolo, leitor e cartões de teste. Cartões/leitores de amostra até 13/11; validação física 16/11. Compatibilidade não presumida; vínculo ativo duplicado é rejeitado.
Aba: Funcionários e dispositivos
- Funções incluídas
- Criar operadores/supervisores; vincular operador a bar/PDV; autenticar e restringir funções de carga/consumo/estorno; registrar dispositivo/estação.
- Cadastros
- Nome/login, perfil, ponto de venda, status, dispositivo, versão do cliente/driver e horário da operação.
- Limite
- Hardware deve vir acompanhado de documentação e amostra. Firmware, fabricação de cartão, aplicativo de fornecedor ou alteração de equipamento ficam fora do código do cashless.
Aba: Recarga de créditos
- Funções incluídas
- Selecionar carteira/cartão, informar valor, criar solicitação de pagamento, mostrar pendente/aprovado/recusado/expirado e lançar crédito somente após confirmação confiável do PSP.
- Cadastros / regra
- Valores mínimos/máximos, métodos, eventuais taxas/caução do cartão, textos, política de cancelamento e PSP são definidos/aprovados pelo cliente.
- Integração / aceite
- Uma API de PSP para carga cashless, a escolher/aprovar, sandbox + produção, webhooks assinados/consultas e credenciais. Repetição não duplica crédito. Nox/solução pronta não será integrada.
Aba: Retorno e comprovantes
- Funções incluídas
- Associar ID interno ao ID PSP; registrar payload sanitizado/estado; permitir consulta de transação e apresentar retorno/comprovante eletrônico do sistema.
- Dependências
- Cliente abre/credencia conta e libera documentação/sandbox até 26/10; PSP define meios, prazo, estorno, taxa e webhook.
- Limite
- Não armazenar cartão bancário. E-mail/SMS de comprovante depende de serviço/credencial e custos externos; emissão impressa requer impressora homologada fornecida.
Aba: Extrato / ledger imutável
- Funções incluídas
- Gravar lançamentos de carga, consumo, resgate, estorno e ajuste; guardar valor, tipo, origem, data/hora, operador, cartão/carteira, PDV e referência externa.
- Regra
- Saldo derivado de créditos confirmados menos débitos autorizados, mais estornos/ajustes permitidos. Não apagar lançamento: corrigir por novo movimento referenciado.
- Aceite
- Recalcular saldo pelo histórico; testar duplicidade, concorrência, rejeição por saldo insuficiente e estorno único. Nenhum saldo é tratado como liquidação bancária.
Aba: Ajustes autorizados
- Funções incluídas
- Estorno/ajuste manual somente a perfil autorizado, com referência à origem, motivo obrigatório, aprovador, antes/depois e trilha.
- Decisões do cliente
- Quem solicita/aprova, estados, expiração, saldo não utilizado, caução/devolução do cartão e procedimento de disputa.
- Limite
- Correção administrativa não efetua reembolso bancário; reembolso depende do PSP e de política autorizada.
Aba: Catálogo de consumo
- Funções incluídas
- Cadastro de produto/categoria, preço em créditos/pontos, disponibilidade, ponto de venda e estado; alteração sujeita a perfil e auditoria.
- Cadastros
- Nome, SKU interno opcional, categoria, preço/regra em pontos, validade, PDV/bar, imagem/texto se fornecido e data de vigência.
- Aceite
- Cliente entrega catálogo e preços; testar itens ativos/inativos, valor e segregação por evento/ponto.
Aba: PDV cashless
- Funções incluídas
- Identificar operador/PDV e cartão; montar venda com itens/quantidades; consultar saldo; autorizar débito atômico uma vez; mostrar aprovada/negada e recibo interno.
- Dependências
- Cartões/leitores aprovados, dispositivos, rede, quantidade de caixas, operadores e produtos; layout e resolução de conflito definidos na homologação.
- Limite / aceite
- Testar venda, saldo insuficiente, duas vendas concorrentes, timeout e repetição. PDV offline, modo store-and-forward, estoque ERP e operação via hardware não validado não estão incluídos.
Aba: Troca de pontos/créditos
- Funções incluídas
- Consultar saldo de pontos/créditos elegíveis; listar conversões/produtos disponíveis; cotar troca; confirmar; debitar saldo de origem e creditar destino uma única vez; emitir comprovante/histórico.
- Cadastros definidos pelo contratante
- Origem/destino, fator de conversão, pontos necessários, valor monetário equivalente se houver, limites, elegibilidade, vencimento, estorno e saldo residual.
- Dependência / aceite
- Especificação escrita de cada conversão e testes com valores de referência. Não presumir 1 ponto = R$1, nem intercâmbio com programa de fidelidade externo.
Split interno da troca/resgate
- Função explicitamente separada
- Calcular e registrar alocação interna entre participantes quando uma carga/troca/resgate é confirmada, segundo uma regra versionada aprovada pelo contratante.
- Regra a fornecer
- Base (carga confirmada, crédito trocado ou consumo conciliado), participantes, percentuais/valores, taxas, responsabilidade por estorno e tratamento do crédito não consumido.
- Limite importante
- O resultado deste split pode ser uma distribuição contábil/ledger. Não transfere dinheiro automaticamente. Transferência bancária exigiria pagamento/PSP, recebedores habilitados e item contratual/homologação explícitos.
Aba: Bloqueios e exceções
- Funções incluídas
- Consultar transações pendentes/falhas; bloquear cartão/carteira; substituir identificador; registrar timeout, saldo insuficiente, duplicidade, ajuste/estorno e motivo.
- Dependências
- Contratante aprova matriz de estados e responsáveis; plataforma não presume operação offline ou sincronização posterior.
- Aceite
- Casos de sucesso, erro, repetição, recuperação e trilha reproduzíveis.
Aba: Relatórios e conciliação E2
- Relatórios incluídos
- Cartões associados/bloqueados; cargas por PSP/estado; saldo; consumo por produto/PDV; trocas; estornos/ajustes; divergência por ID/período.
- Exportação
- CSV dos campos exibidos; perfil autorizado. Filtros por evento, período, cartão/PDV e estado.
- Aceite
- Relatório compara PSP e ledger; provar saldo inicial + créditos − débitos + ajustes. Aprovação E2 em 27/11.
SUBENTREGAS E2E2.1 cartões/leitores · E2.2 associação · E2.3 PSP/carga · E2.4 ledger · E2.5 consumo/troca/exceções · E2.6 conciliação/UAT. Compatibilidade física: sessão em 16/11; aceite E2 27/11.
ENTREGA E3 · 30 NOV–04 DEZ
Estacionamento e quiosques: split independente por terminal
A implementação-alvo usa fluxo oficial Stone Connect / API integrada, condicionado à conta Stone, modelo POS, credenciamento, recebedores e homologação. Um POS não representa todos os demais.
Aba: Inventário de terminais
- Funções incluídas
- Cadastrar terminal por serial/ID lógico, fabricante/modelo, modalidade, estado de credenciamento e responsável; ativar/desativar dentro do escopo.
- Dados obrigatórios do cliente
- Quantidade total exata, cada ID/serial, setor/local, PDV, modelo, titular/conta Stone, estado, contato do provedor e possibilidade de teste. Prazo: 20/11.
- Aceite
- Contagem da matriz = quantidade declarada. Cada terminal tem estado conhecido; ausente/incompatível é bloqueio/ressalva, não integração presumida.
Aba: Locais e pontos externos
- Funções incluídas
- Cadastrar estacionamento/quiosque/local, ponto de venda, equipe responsável e relacionamento com terminal.
- Cadastros
- Nome do estabelecimento, PDV, setor/local, identificador, operador responsável, horário de operação e beneficiários.
- Limite
- Não inclui sistema de estacionamento, controle de cancela, estoque comercial ou ERP do quiosque sem item expresso.
Aba: Vínculo POS–PDV–recebedor
- Funções incluídas
- Associar cada terminal a exatamente um ponto/estabelecimento ativo e à matriz de recebedores do período; visualizar vínculo e histórico.
- Dados necessários
- POS ID, estabelecimento, conta/recebedor, CNPJ, vigência, usuário aprovador e status Stone.
- Aceite
- Relatório identifica POS sem vínculo, duplicado, inativo ou com conflito. Cliente aprova matriz antes de enviar split; alteração registra autor/data.
Integração Stone
- Fluxo alvo
- Criar pedido pelo software integrado/PSP quando a modalidade Stone Connect aceita; cliente conclui no POS compatível; receber retorno transacional e correlacionar os IDs.
- Pré-requisitos
- Conta Stone credenciada, programa/API habilitado, POS compatível, acesso ao sandbox/documentação, recebedores habilitados e regra aprovada.
- Limite
- Se a conta/modelo não for elegível ou API não liberar função, registrar bloqueio e submeter alternativa/aditivo. Não afirmar automação de uma maquininha autônoma não integrada.
Aba: Configuração e split de cada POS
- Funções incluídas
- Registrar regra aprovada por ID terminal; criar/atualizar configuração via fluxo oficial, se habilitado; guardar versão, payload/retorno sanitizado e estado.
- Cliente decide
- Recebedores, CNPJ, percentual/valor, base bruta/líquida, taxas, vigência, cancelamento, chargeback, estorno e conta responsável para cada POS. Matriz inicial até 27/11.
- Aceite
- Teste individual de terminal, retorno do provedor e memória de cálculo. A alteração em POS A não pode mudar B. Estado configurado não significa valor liquidado.
Exceções por terminal
- Funções incluídas
- Marcar sem credenciamento, indisponível, recusado, timeout, regra divergente ou falta de evidência; associar responsável e próxima ação.
- Resultado
- Relatório mostra 100% dos POS do escopo como testado/aceito, bloqueado ou ressalvado formalmente.
- Limite
- Configuração manual em portal de terceiro só entra se procedimento, prova e responsabilidade forem aprovados; não se declara integração por configuração manual invisível.
Aba: Transações e conciliação
- Campos acompanhados
- ID PSP, ID POS, pedido, valor, taxa, recebedores/parcelas, estado autorização/captura, cancelamento/estorno e estado de liquidação se fornecido.
- Relatórios incluídos
- Transações por data, local, terminal, estado e recebedor; totais por POS; divergências e pendências; CSV dos campos exibidos.
- Aceite E3
- Em 04/12, comparar regra e transação de teste com retorno/relatório Stone por unidade; todas as exceções explicitadas.
Teste por unidade
- Procedimento
- Conferir serial e local; confirmar regra; executar venda teste aprovada/recusada conforme ambiente; verificar retorno, divisão calculada e reconciliação.
- Evidência
- POS ID, caso de teste, data, valor, IDs correlatos, resultado, arquivos sanitizados, aprovador e bloqueios.
- Dependência
- Contratante/Stone disponibiliza todos os POS do escopo e acesso. Sem isso, aquela unidade não fecha.
SUBENTREGAS E3E3.1 inventário completo até 20/11 · E3.2 matriz terminal/PDV/recebedor aprovada até 27/11 · E3.3 configuração 30/11–02/12 · E3.4 teste 02–03/12 · E3.5 conciliação e aceite individual em 04/12.
ENTREGA E4 · 07–09 DEZ
Integração, testes, treinamento e go/no-go
E4 integra somente os fluxos E1–E3 contratados e homologados; não adiciona módulos novos. Meta de carga informada: 10 transações por segundo.
Interfaces externas são versionadas e possuem credenciais próprias. Segredos de API não são enviados por e-mail comum nem copiados neste documento.
Testes funcionais e financeiros
- E1: venda, limite de estoque, aprovado/recusado/pendente no PSP, webhook repetido, emissão/cancelamento/leitura do ingresso.
- E2: cadastro/associação/bloqueio de cartão, estados de recarga, ledger, consumo, troca de pontos, estorno e cálculo de split interno.
- E3: conferir cada POS do inventário, vínculo da regra, retorno de pagamento e conciliação por terminal.
- Ponta a ponta: correlacionar evento/pedido/pagamento/ingresso; cartão/pagamento/ledger/consumo; POS/pedido/split/liquidação.
Teste de carga e falhas
- Executar teste de carga em ambiente de teste com meta de 10 transações por segundo.
- Contratante confirma duração do pico, janela, limites dos provedores e dados representativos antes da execução.
- Testar duplicidade, timeout, perda/recuperação de rede, débito concorrente, perfil negado e leitura duplicada.
- Evidência registra versão, ambiente, duração, vazão observada, taxa de erros e bloqueios. SLA, disponibilidade ou RTO não são prometidos sem previsão expressa no contrato.
Implantação controlada
- Inclui
- Release candidate, checklist de produção, permissão, configuração aprovada, migração de cadastros de escopo, smoke test, registro de versão e caminho de rollback documentado.
- Entradas do contratante
- Domínio/TLS, contas e custos de cloud, credenciais seguras, dados aprovados, usuários e contatos operacionais.
- Não inclui
- Custos de cloud/domínio, links, energia, SMS/e-mail, licenças, contratação de PSP, taxas, impressoras, cartões ou suporte presencial sem previsão expressa.
Runbook e treinamento
- Runbook
- Inicialização/encerramento, monitoramento, fila/estados pendentes, consulta de transação, reconciliação, bloqueio/estorno autorizado, contatos e escalonamento.
- Treinamento incluído
- Sessão remota para usuários indicados, roteiro e material de apoio nos módulos contratados; presença, plantão e horas adicionais dependem de contratação.
- Teste
- Cliente demonstra procedimentos críticos com usuário/perfil de operação; registrar dúvidas e pendências no termo.
Critério de saída E4
- Roteiros E1–E3 executados no ambiente acordado, resultados reproduzíveis.
- 10 TPS testados e resultado medido registrado.
- Nenhum defeito crítico aberto para cobrança, ingresso, saldo/ledger, duplicidade ou divisão financeira.
- Defeito não crítico/limitação listados com impacto, alternativa, responsável e data.
- Relatório, versão, runbook, UAT, treinamento e decisão formal do contratante entregues.
Fora do aceite automático
- Terceiro indisponível ou sem credenciamento não conta como integração aprovada.
- Integração não homologada não pode ser descrita como produção pronta.
- Funcionalidade não listada, hardware não fornecido e prazo de terceiro não são assumidos.
- Nova solicitação durante folga 10–14/12 não entra na correção de defeito sem análise de mudança.
SUBENTREGAS E4E4.1 integração consolidada (07/12) · E4.2 testes/evidências e 10 TPS (07–08/12) · E4.3 UAT cliente (08/12) · E4.4 produção/runbook/treino (08/12) · E4.5 ensaio e aceite formal (09/12).
INVENTÁRIO FUNCIONAL · BASE DE CONTAGEM
54 funções principais, decompostas em ações rastreáveis
Exemplo de hierarquia: E1-F15 = CRM e relatórios; E1-F15.1 = pesquisar comprador; E1-F15.2 = consultar pedidos/ingressos; E1-F15.3 = filtrar; E1-F15.4 = exportar CSV. Cada subfunção recebe um ID e critério verificável.
—subfunções numeradas nos 54 requisitos · contagem automática
—ações detalhadas na hierarquia Módulo → Função → Subfunção · exemplo do usuário CRM incluído abaixo
54 funções listadas
E1 · 20/10–19/11 · TICKETERIA E ADMINISTRAÇÃO15 funções | Gate de base 28/10 | entrega/aceite E1 19/11 | Dependência chave: dados comerciais e PSP aprovado.
| ID / aba | Comportamento incluído | Subfunções numeradas | Dados e regra principal | Dependência / evidência objetiva |
|---|---|---|---|---|
E1-F01Organização e evento | Criar, editar, publicar, suspender e encerrar evento por estado permitido. | Nome, data/hora, fuso, local, capacidade, status e responsável. | Dados aprovados pelo cliente; demonstrar ciclo rascunho→publicado→encerrado e trilha. | |
E1-F02Setores e locais | Criar setores/áreas e relacioná-los ao evento e a uma oferta/ponto quando aplicável. | EventID, nome, código, estado, capacidade declarada e ordem. | Planta/lista fornecida pelo cliente; filtro e isolamento por evento comprovados. | |
E1-F03Usuários e autenticação | Criar/editar/desativar usuários e iniciar/encerrar sessão. | Nome, login, status, perfil e escopo; segredo não aparece em logs. | Lista de usuários e aprovador pelo cliente; login ativo/inativo demonstrado. | |
E1-F04Perfis e permissões | Restringir ações de administrador, financeiro, supervisor e operador. | UserID, RoleID, EventID e permissões por ação. | Matriz aprovada; teste positivo e negativo no servidor, com evidência de auditoria. | |
E1-F05Categorias e lotes | Criar categoria/lote, preço, quantidade, janela, limite/pedido e estado. | CategoryID, EventID, preço, estoque, início/fim e limite. | Regras/preços do contratante; lote futuro, encerrado e ativo demonstrados. | |
E1-F06Disponibilidade e estoque | Calcular disponibilidade e impedir venda acima do estoque em solicitações concorrentes. | Estoque total, reserva/pedido, vendido, liberado e estado. | Teste estoque esgotado e duas compras pela última unidade; nunca exceder limite. | |
E1-F07Dados do comprador | Coletar os campos de comprador/participante definidos como obrigatórios no formulário. | BuyerID, campos aprovados, consentimentos e versão do aviso. | Cliente aprova campos, textos e política; validação e minimização demonstradas. | |
E1-F08Pedido e itens | Criar pedido, itens, quantidades, valor, estado e identificador único. | OrderID, BuyerID, LotID, OrderItem, total, moeda, idempotency key. | Pedido reproduzível; retry não duplica pedido ou venda. | |
E1-F09Integração PSP de ticketing | Enviar pedido de cobrança ao PSP contratado e guardar os identificadores relacionados. | ProviderID, PSPOrderID, PaymentID, método e estado externo. | Uma API nominada e credenciada; sandbox, documentação e credenciais fornecidas. | |
E1-F10Webhook/estado/idempotência | Validar retorno assinado/consulta e tratar repetição, recusa, timeout e estado pendente sem transição duplicada. | ProviderEventID único, hash/metadata sanitizados, occurredAt e status. | Eventos de teste PSP; repetição gera mesmo resultado e evidência correlacionável. | |
E1-F11Ingresso digital | Emitir código/QR único somente após confirmação válida; cancelar/invalidar conforme ação autorizada. | TicketID, OrderItemID, código único, status e participante. | Pagamento não confirmado não emite; teste de ingresso cancelado e único. | |
E1-F12Validação de entrada | Consultar ingresso e autorizar/negar entrada; gravar leitura e operador. | TicketID, EventID, AccessScan, device/operator, horário e resultado. | Dispositivo/browser e rede fornecidos; válido/usado/cancelado/duplicado testados. | |
E1-F13Split da ticketing | Versionar a regra e enviá-la no pedido quando PSP/conta autorizarem; armazenar retornos/alocações. | SplitRule, recipient, base, percent/value, fee/chargeback e vigência. | Regra definida pelo contratante e recebedores habilitados; memória de cálculo e resposta sandbox. | |
E1-F14Painel financeiro E1 | Consultar pedidos, taxas disponíveis, valores calculados e estados externos separados. | EventID, período, lote, Payment state, calculated/net/settlement fields. | Conferir totals contra conjunto de teste PSP; aprovado não é marcado como depositado. | |
E1-F15Compradores, relatório e CSV | Pesquisar pedido/comprador e filtrar/exportar os campos listados por perfil. | EventID, período, lote/status; export metadata e actor. | Campos/retention aprovados pelo controlador; comparar export e tela com fixture. |
E2 · 16–27/11 · CASHLESS CONSTRUÍDO DO ZERO15 funções | Amostras até 13/11, teste físico 16/11 | PSP de recarga a selecionar | sem integração a solução pronta.
| ID / aba | Comportamento incluído | Subfunções numeradas | Dados e regra principal | Dependência / evidência objetiva |
|---|---|---|---|---|
E2-F01Cadastro de carteira | Criar e consultar carteira de créditos vinculada a participante/cliente e evento. | WalletID, BuyerID opcional, EventID, status, createdAt. | Campos de identificação aprovados; isolamento por evento validado. | |
E2-F02Inventário de cartões | Registrar UID, modelo/tecnologia e estados de cartão. | CardUID único, CardModel, estado, lote de aquisição, datas. | Modelo/protocolo/datasheet e amostra do cliente; leitor físico testado em 16/11. | |
E2-F03Vínculo carteira–cartão | Associar, ativar, bloquear, declarar perdido e substituir cartão mantendo histórico. | CardWalletLink, validFrom/To, motivo, actor; um vínculo ativo permitido. | Testar associação duplicada, bloqueio e substituição com referência ao anterior. | |
E2-F04Operadores e estações | Manter usuários e associar perfil, bar/PDV e dispositivo homologado. | UserID, RoleID, ServicePointID, DeviceID, status. | Lista de funcionários, pontos e dispositivos pelo cliente; ação indevida negada. | |
E2-F05Solicitar recarga | Criar pedido de carga para uma carteira/cartão, valor e PSP/forma selecionados. | RechargeID, WalletID, amount, currency, idempotency key, provider. | PSP de carga e limites aprovados; pedido associa um ID interno único. | |
E2-F06Confirmar pagamento da recarga | Confirmar por webhook verificado/consulta antes de lançar crédito. | ProviderPaymentID, ProviderEventID, status, confirmedAt. | Sandbox/documentação PSP; pendente/recusado/timeout não credita carteira. | |
E2-F07Crédito idempotente | Lançar crédito uma única vez e rejeitar repetição ou evento incompatível. | LedgerEntry origin type/id; unique source reference. | Reentrega do evento de pagamento não duplica o saldo; IDs antes/depois. | |
E2-F08Extrato imutável | Persistir créditos, débitos, resgates, estornos e ajustes como lançamentos auditáveis. | LedgerEntryID, WalletID, amount signed, type, source, timestamp, actor. | Não editar/apagar lançamento; ajuste cria contra-lançamento relacionado. | |
E2-F09Consultar saldo | Exibir saldo derivado e extrato conforme evento/carteira/permissão. | Saldo = créditos confirmados − débitos autorizados + ajustes válidos. | Reconstruir saldo do ledger e comparar painel para casos de referência. | |
E2-F10Catálogo cashless | Criar categoria/produto, preço em crédito/pontos, disponibilidade e PDVs elegíveis. | ProductID, SKU, category, point price, status, servicePoint mapping. | Catálogo e preços aprovados pelo cliente; testar produto ativo/inativo e preço. | |
E2-F11Venda no PDV cashless | Identificar operador/cartão/itens, consultar saldo, autorizar débito único e exibir resultado. | CashlessSaleID, WalletID, Device/ServicePoint, items, total, state. | Leitor/dispositivo e operadores disponíveis; saldo insuficiente não debita. | |
E2-F12Concorrência e repetição | Serializar/validar débitos para duas vendas concorrentes e requisições repetidas. | IdempotencyKey, wallet version/transaction boundary. | Testar saldo exato e chamadas concorrentes; sem saldo negativo por corrida. | |
E2-F13Troca de pontos/créditos | Simular, aprovar e executar conversão origem→destino uma vez; emitir comprovante. | ExchangeRule version, input/output units, rounding, limits, wallet refs. | Fator, elegibilidade, arredondamento, expiração e estorno definidos pelo contratante. | |
E2-F14Split interno da troca | Calcular e registrar alocações internas vinculadas à carga/troca/consumo na base escolhida. | InternalSplitRule, baseEvent, recipients, percentages, residual, ledger refs. | Contratante escolhe se split decorre de recarga, troca ou consumo; sem transferência bancária implícita. | |
E2-F15Bloqueio, estorno e relatórios | Bloquear cartão, autorizar contra-lançamento e consultar cargas/saldos/consumo/exceções. | reason, approver, source entry, status, filters event/date/POS. | Estorno requer origem e autorização; relatório reconcilia PSP, ledger e PDV. |
E3 · 30/11–04/12 · OPERAÇÃO EXTERNA12 funções | Número, modelo e serial exatos de POS fornecidos pelo contratante até 20/11.
| ID / aba | Comportamento incluído | Subfunções numeradas | Dados e regra principal | Dependência / evidência objetiva |
|---|---|---|---|---|
E3-F01Estabelecimentos | Cadastrar estacionamento/quiosque, local, estado e contato operacional. | BusinessLocationID, event, name, address/reference, responsible. | Lista de locais e responsáveis aprovada; relacionar ao evento correto. | |
E3-F02Pontos de venda | Criar PDV externo e vinculá-lo a estabelecimento/área. | ServicePointID, locationID, code, kind (parking/kiosk), status. | Cliente entrega mapa/lista; PDV ativo e inativo filtráveis. | |
E3-F03Inventário exato de POS | Registrar cada serial/ID lógico, fabricante/modelo, modalidade e status. | TerminalID, providerAccountID, serial/model, location, credential state. | Contagem bate quantidade contratante; documento/serial por terminal até 20/11. | |
E3-F04Vínculo POS–PDV | Associar POS a um ponto externo e manter histórico de atribuições/vigência. | TerminalID, ServicePointID, validFrom/To, actor. | Não permitir vínculo conflitante ativo; relatório de terminais sem associação. | |
E3-F05Cadastro de recebedores | Registrar referência/ID de beneficiário habilitado pelo provedor. | BeneficiaryID, CNPJ reference, PSP recipient ID, status; sem credencial bancária. | Contratante/provedor credencia contas; IDs não secretos e estado confirmados. | |
E3-F06Matriz de split por POS | Versionar regra independente por terminal e vigência. | TerminalID, recipients, base, percent/value, fee/residual, approver. | Regra final fornecida/aprovada pelo contratante até 27/11; versão imutável. | |
E3-F07Enviar/configurar split | Aplicar regra via API/modalidade oficial habilitada e guardar retorno. | Provider request/response IDs, rule version, status, sanitized payload. | Stone Connect/API habilitada e ambiente; sem suporte oficial = bloqueio/alternativa formal. | |
E3-F08Criar venda externa | Correlacionar pedido/valor/local/terminal com solicitação de pagamento externo. | ExternalSaleID, TerminalID, ServicePointID, amount, currency, order ref. | Fluxo oficial e origem do pedido aprovados; ID único e regra da unidade anexada. | |
E3-F09Estados do pagamento POS | Registrar pendente, aprovado, recusado, cancelado, timeout ou desconhecido conforme retorno. | PSP transaction ID, authorization/capture state, event timestamp. | Sandbox/transações de teste e documentação; evento repetido idempotente. | |
E3-F10Mapear transação e parcela | Correlacionar pagamento, POS, PDV, recebedor, regra e parcelas retornadas. | PaymentID, split allocation IDs, fees, net, external settlement state. | Teste individual em cada POS incluído; sem extrapolar homologação entre terminais. | |
E3-F11Fila de exceções | Listar POS sem credenciamento, regra, retorno, ou com divergência. | exception type, terminal, owner, due date, blocker state and evidence. | Exceção possui dono/próxima ação; nenhuma unidade sem prova marcada como concluída. | |
E3-F12Relatório e aceite por POS | Filtrar/exportar resultado, regra, venda teste, taxas, liquidação disponível e ressalvas. | Event, date, terminal, service point, recipient, status. | Em 04/12 evidência para 100% do inventário aprovado ou exceção formal assinada. |
E4 · 07–09/12 · HOMOLOGAÇÃO E PRONTIDÃO12 funções | Carga-alvo 10 TPS | Entradas E1–E3 aceitas e integrações liberadas.
| ID / aba | Comportamento incluído | Subfunções numeradas | Dados e regra principal | Dependência / evidência objetiva |
|---|---|---|---|---|
E4-F01Mapa de integrações | Registrar fluxos autorizados, ambiente, versão API, dono e estado por fornecedor. | Provider, integration name/version, environment, owner, status. | Documentação/acesso PSP e Stone; cada item com evidência ou blocker explícito. | |
E4-F02Correlação ponta a ponta | Pesquisar IDs relacionados entre order/payment/ticket, recharge/wallet/ledger e POS/split. | CorrelationID interno + provider IDs; sem inserir segredo/payload sensível. | Roteiros cross-module reproduzíveis; rastreio até fonte de origem. | |
E4-F03Execução de casos UAT | Registrar caso, pré-condição, passos, esperado/observado, status, build e aprovador. | TestCaseID, requirement/WBS, environment, run, evidence link. | Contratante nomeia validadores; aprovado/reprovado/bloqueado formal. | |
E4-F04Testes de falha | Verificar timeout, repetição, perda/recuperação e estado desconhecido sem duplicar operação. | Provider event, idempotency key, state transitions, recovery result. | Credenciais/sandbox; logs sanitizados e replay controlado documentados. | |
E4-F05Consistência financeira | Reconciliar valores de PSP, ledger interno e transações POS; separar calculado/capturado/liquidado. | Gross, fees, net, allocations, settlements and source IDs. | Relatório base comparado a dados PSP/Stone fornecidos em ambiente autorizado. | |
E4-F06Teste de capacidade 10 TPS | Executar teste em ambiente acordado e registrar vazão/erros/duração observados. | Target=10 TPS; test duration, payload profile, concurrency, result. | Contratante aprova duração/janela; PSP rate limits conhecidos; atingir meta sob perfil declarado. | |
E4-F07Revisão de perfis e auditoria | Verificar ações permitidas/negadas em funções e integridade de trilha. | User/Role, action, event ID, actor, timestamp, result. | Lista de usuários e matriz de permissão aprovadas; evidência por papel. | |
E4-F08Release de produção | Preparar release, checagem de configuração e smoke tests, registrar versão e rollback. | ReleaseID, build/hash, environment, approver, deployment result. | Domínio/cloud/segredos/contas fornecidos; aprovação explícita antes da produção. | |
E4-F09Runbook operacional | Entregar passos para iniciar/fechar, verificar status, consultar transação e escalar falhas. | Runbook version, service, owner, support contacts, escalation path. | Revisão com contato indicado pelo contratante; suporte além do contrato é separado. | |
E4-F10Treinamento | Realizar sessão remota para perfis indicados e registrar conteúdo/presença/dúvidas. | Session, module, roles trained, material version, attendees. | Participantes, horário e acesso remoto confirmados; presencial só contratação. | |
E4-F11Defeitos e pendências | Classificar defeito/risco/bloqueio, responsável, impacto, workaround e reteste. | IssueID, severity, release, WBS, owner, due date, evidence. | Crítico impede prontidão até correção ou decisão formal contratual aplicável. | |
E4-F12Go/no-go e aceite final | Consolidar checklist final, riscos aceitos, pendências e aprovação/rejeição do contratante. | AcceptanceID, delivery E4, evidence index, approver, signed date. | Termo formal até 09/12; folga 10–14/12 apenas estabilização/correções do escopo. |
TOTAL FUNCIONAL LISTADO—Requisitos funcionais identificados para este baseline. Nova função precisa de mudança aprovada; contagem não inclui tarefas internas nem itens de terceiros.
TRÊS CONTEXTOS FINANCEIROS INDEPENDENTES
Um motor de regras; três bases de cálculo sem confusão
Cada regra tem contexto explícito, versão, base, destinatários, aprovador e transação de origem. O contratante fornece regras/percentuais; o provedor aprova o que pode ser efetivamente transferido.
Split de venda de ingresso
Evento / pedido aprovado no checkout
- Origem: pedido do ingresso e pagamento confirmado pelo PSP.
- Configurar: recebedores, percentual/valor por evento/categoria, base bruta/líquida, taxas, chargebacks, cancelamento/estorno e vigência.
- Executar: adicionar regra ao pedido na API quando PSP habilitar; persistir request/result IDs e estado.
- Validar: soma/valor, participante habilitado, pagamento e retorno de split em sandbox.
- Limite: liquidação e repasse obedecem PSP/contrato; aprovação de pedido não prova depósito.
Split por POS Stone: quiosque/estacionamento
Cada terminal, cadastrado e homologado individualmente
- Origem: transação presencial relacionada a terminal ID, PDV e pedido.
- Configurar: matriz POS→ponto→recebedor, regra/base, percentuais, taxas e vigência.
- Executar: enviar/configurar apenas pela modalidade API/Connect oficialmente habilitada; reter retorno por terminal.
- Validar: transação e cálculo com a regra específica de cada POS; alteração em A não altera B.
- Limite: POS autônomo, não credenciado ou sem API não é controlado remotamente por esta aplicação.
Split de troca/resgate de créditos
Distribuição interna da troca/crédito no ledger cashless
- Origem: evento de carga, conversão ou resgate de créditos, selecionado pelo contratante como base da regra.
- Configurar: tipo de evento que dispara split, base, participantes, percentuais/valores, taxas, arredondamento, estorno e saldo não consumido.
- Executar: registrar alocações vinculadas ao movimento de ledger e à versão da regra; idempotência e histórico auditável.
- Validar: reprocesso/estorno, centavos/resíduos e conciliação com créditos e consumo.
- Limite: cálculo/alocação em ledger não é transferência bancária. Repasse monetário requer PSP/transferência autorizada e item expresso.
Decisão que precisa constar da matriz de regras: para cashless, o split dispara na carga paga, na conversão/troca de créditos ou após consumo conciliado? Indicar se é apenas rateio interno ou se exige saída bancária. Não reaproveitar a regra de ticketing/POS sem aprovação.
Campos obrigatórios em cada versão de SplitRule
contexto (ticketing / POS / troca interna)evento + vigênciabase bruta/líquida/ledgerrecebedores/beneficiáriospercentual ou valortaxas e chargebacksarredondamento/resíduocancelamento/estornoaprovador e dataestado PSP separado da liquidação
ARQUITETURA LÓGICA · BASE PARA O DESENHO DO BANCO
Relacionamentos que ligam evento, venda, ledger e divisão
Modelo lógico inicial; nomes físicos/tipos/índices serão fixados na especificação técnica E1. Relações, chaves de origem e auditoria aqui descritas são obrigatórias para rastreabilidade.
STATUS: MODELO LÓGICO PROPOSTO — NÃO É DUMP DE BANCO IMPLEMENTADOChaves e relações abaixo são o contrato de dados proposto. Tipos são conceituais compatíveis com SQL relacional; nomes físicos, índices finais, retenção e particionamento devem ser aprovados no desenho E1. IDs externos nunca substituem a PK interna.
Diagrama entidade–relacionamento · recortes navegáveis por domínio
Cada caixa é uma entidade/tabela lógica; as ligações mostram cardinalidade. Use os recortes para ler cada fluxo sem cruzar os três contextos financeiros.
PK chave primária da entidadeFK referência à entidade relacionada relação; rótulo 1:N / N:M indica cardinalidadeSeta lógica: entidade-pai → entidade-filha
01 · E1 TICKETERIAPedido, PSP, ingresso, leitura e alocação da regra de split.
02 · E2 CASHLESSCarteira, cartão, recarga, lançamentos, consumo, troca e rateio interno.
03 · E3 POS EXTERNOInventário terminal→PDV, venda, recebedores e split individual por POS.
04 · E4 CONTROLES TRANSVERSAISOrganização, permissões, conexões de provedor, auditoria e conciliação.
01 · VENDA DE INGRESSO
Event
1:NTicketCategory → TicketLot
1:NOrder → OrderItem
1:NTicket → AccessScan
02 · PAGAMENTO / PSP
Buyer
1:NOrder ou Recharge
1:NPaymentAttempt → ProviderEvent
ref.SplitAllocation
03 · POS EXTERNO
Event → ServicePoint
1:NTerminalAssignment
N:1ExternalTerminal
1:NExternalSale → PaymentAttempt
04 · CASHLESS PRÓPRIO
Event / Buyer → Wallet
1:NCardAssignment → CashlessCard
1:NRecharge / CashlessSale
1:NLedgerEntry → SplitAllocation
05 · CONTROLE / CONCILIAÇÃO
User + Role → UserRole
1:NAuditEvent
agrupaReconciliationRun
1:NReconciliationItem
Relações verificáveis · 42 relações FK, cardinalidade e exclusão
O vínculo mostra quem possui a FK e qual regra preserva histórico. Cascade-delete não é permitido em pedidos, pagamentos, tickets, POS, allocations, ledger, auditoria ou conciliação.
| ID | Relação / cardinalidade | FK e unicidade | Integridade / política |
|---|---|---|---|
| R01 | Organization 1:N Event | Event.OrganizationID → Organization.ID | FK obrigatória; organização referenciada não se apaga fisicamente. |
| R02 | Venue 1:N Event (Venue pode ser 0:1) | Event.VenueID → Venue.ID | Local pode ser preenchido posteriormente; manter snapshot aprovado do evento. |
| R03 | Event 1:N EventSector | EventSector.EventID; UNIQUE(EventID, code) | Setor referenciado por ingressos/pontos fica inativo, não deletado. |
| R04 | Event 1:N ServicePoint | ServicePoint.EventID; UNIQUE(EventID, code) | PDV, quiosque, estacionamento e portão usam um vocabulário de tipo aprovado. |
| R05 | Event 1:N TicketCategory | TicketCategory.EventID | Categoria pertence ao mesmo evento dos lotes e pedidos relacionados. |
| R06 | TicketCategory 1:N TicketLot | TicketLot.CategoryID; EventID deve coincidir | CHECK preço≥0, estoque≥0 e início<fim; preço histórico vira snapshot no pedido. |
| R07 | Buyer 1:N Order | Order.BuyerID → Buyer.ID (nullable somente se fluxo anônimo aprovado) | PII tem acesso/retenção limitada; exclusão de perfil não remove dados financeiros obrigatórios. |
| R08 | Event 1:N Order | Order.EventID; INDEX(EventID, CreatedAt, State) | Filtro operacional e relatório segregados por evento. |
| R09 | Order 1:N OrderItem | OrderItem.OrderID; OrderItem.LotID | quantity>0; excluir em cascata proibido após tentativa de pagamento. |
| R10 | Order 1:N PaymentAttempt (0:N tentativas) | PaymentAttempt.OrderID opcional | Retry cria nova tentativa correlacionada; pedido mantém estado de negócio próprio. |
| R11 | Recharge 1:N PaymentAttempt | PaymentAttempt.RechargeID opcional | Uma tentativa tem uma única origem: Order XOR Recharge XOR ExternalSale. |
| R12 | ExternalSale 1:N PaymentAttempt | PaymentAttempt.ExternalSaleID opcional | Venda externa não se relaciona diretamente por número de POS em vez de FK. |
| R13 | PaymentAttempt 1:N ProviderEvent | ProviderEvent.PaymentID; UNIQUE(provider, externalEventID) | Evento duplicado é guardado/identificado, não reaplica crédito, ticket ou split. |
| R14 | OrderItem 1:N Ticket | Ticket.OrderItemID; UNIQUE(TicketCode) | Ticket só é emitido após confirmação autoritativa; pedido mantém snapshot. |
| R15 | Ticket 1:N AccessScan | AccessScan.TicketID, EventID, UserID | Leituras append-only; concorrência decide autorização sem duplicar entrada. |
| R16 | Event 1:N Wallet | Wallet.EventID; UNIQUE(EventID, walletReference) | Carteira e saldo sempre escopados ao evento. |
| R17 | Buyer 0:1:N Wallet | Wallet.BuyerID opcional | Identificação nominal opcional conforme regra/privacidade do cashless. |
| R18 | Wallet N:M CashlessCard via CardAssignment | CardAssignment.WalletID + CardID, validFrom/To | Histórico temporal; no máximo vínculo ativo único por cartão. |
| R19 | Wallet 1:N Recharge | Recharge.WalletID; UNIQUE(idempotencyKey) | Recarga é solicitação; não representa crédito até confirmação. |
| R20 | Wallet 1:N LedgerEntry | LedgerEntry.WalletID; INDEX(WalletID, createdAt) | Ledger append-only; saldo reconstruível por créditos/débitos/ajustes. |
| R21 | CashlessSale 1:N CashlessSaleItem | Item.SaleID; Item.ProductID | Itens e preço aplicado guardados como snapshot. |
| R22 | Wallet 1:N CashlessSale | CashlessSale.WalletID | Débito e confirmação de venda fazem parte de uma operação atômica. |
| R23 | CreditExchange 1:N? LedgerEntry | Exchange sourceEntryID/resultEntryID | Uma troca aponta entradas origem/destino; fator e versão não se sobrescrevem. |
| R24 | Event 1:N ExternalTerminal via TerminalAssignment | TerminalAssignment.EventID + TerminalID | Serial único por provedor; quantidade confere com inventário assinado. |
| R25 | ExternalTerminal 1:N TerminalAssignment | TerminalAssignment.TerminalID | Atribuição possui vigência; no máximo uma ativa conforme regra aprovada. |
| R26 | ServicePoint 1:N TerminalAssignment | TerminalAssignment.ServicePointID | POS ID, serial físico, estabelecimento e PDV são campos/chaves distintos. |
| R27 | TerminalAssignment 1:N ExternalSale | ExternalSale.AssignmentID | A venda resolve a atribuição/vigência do terminal usada na operação. |
| R28 | SplitRule 1:N SplitRuleRecipient | SplitRuleRecipient.RuleID | Regra publicada imutável; alteração cria nova versão com aprovador. |
| R29 | Beneficiary 1:N SplitRuleRecipient | SplitRuleRecipient.BeneficiaryID | Cadastro local separado da aprovação/estado da conta recebedora no PSP. |
| R30 | SplitRule 1:N SplitAllocation | SplitAllocation.RuleID + ruleVersion | Snapshot de base, valor, moeda, favorecido e estado externo por alocação. |
| R31 | PaymentAttempt 0:N SplitAllocation | Allocation.PaymentID opcional | Origem usada para split PSP ticketing/POS; calculado não é liquidado. |
| R32 | LedgerEntry 0:N SplitAllocation | Allocation.LedgerEntryID opcional | Origem usada para distribuição interna; não implica transferência bancária. |
| R33 | User N:M Role via UserRole | UserRole.UserID + RoleID; EventID/PDV opcionais | Concessão/revogação datada e atribuída a um concedente autorizado. |
| R34 | ReconciliationRun 1:N ReconciliationItem | Item.RunID + referência de origem opcional | Execução reprodutível; divergência gera registro/ação, não altera fonte. |
| R35 | Entidade financeira 1:N AuditEvent | entityType + entityID; FK concreta onde aplicável | Append-only; ator, ação, timestamp, resultado e diff sanitizado. |
| R36 | Organization 1:N Venue | Venue.OrganizationID → Organization.OrganizationID | Organização titular; endereço histórico não é removido. |
| R37 | Organization 1:N User | User.OrganizationID → Organization.OrganizationID | Usuários e eventos isolados por tenant/organização. |
| R38 | Event 1:N Product | Product.EventID → Event.EventID | SKU único por evento; produto usado em venda não é apagado. |
| R39 | Product N:M ServicePoint via ServicePointProduct | Mapping.ProductID + ServicePointID | Oferta/preço/disponibilidade definidos por ponto e período. |
| R40 | CreditExchangeRule 1:N CreditExchange | Exchange.RuleID → CreditExchangeRule.RuleID | Troca referencia regra versionada e aprovada, não regra atual mutável. |
| R41 | ProviderConnection 1:N PaymentAttempt / Terminal | ProviderConnectionID referenciado por integração | Sandbox/produção segregados; guardar secretRef, nunca o segredo. |
| R42 | User 1:N DeviceRegistration / AccessScan | DeviceRegistration.UserID; AccessScan.deviceRef | Ator/dispositivo rastreáveis; somente identificadores necessários. |
Dicionário de 40 entidades · PK, FK, atributos e integridade
| Domínio / entidade | PK | FK / cardinalidade | Atributos conceituais mínimos | Integridade / observação |
|---|---|---|---|---|
| Admin · Organization | OrganizationID UUID | — | legalName, taxIdRef, status, createdAt | Tenant/organização; identificador fiscal protegido. |
| Comercial · Event | EventID UUID | OrganizationID, VenueID | name, timezone, startsAt, endsAt, capacity, status, createdAt | Fim > início; status controlado; não misturar ambientes. |
| Comercial · Venue | VenueID UUID | OrganizationID | name, address, city, state, country | Endereço é dado fornecido pelo contratante. |
| Comercial · EventSector | SectorID UUID | EventID | code, name, capacity, status | UNIQUE(EventID, code). |
| Comercial · ServicePoint | ServicePointID UUID | EventID, SectorID NULL | code, name, kind, location, status | UNIQUE(EventID, code); kind classifica bar/quiosque/estacionamento/portão. |
| Ticketing · TicketCategory | CategoryID UUID | EventID | code, name, description, status | UNIQUE(EventID, code). |
| Ticketing · TicketLot | LotID UUID | CategoryID, EventID | name, price DECIMAL, currency CHAR(3), stock, limitPerOrder, saleStart/End, status | price ≥ 0; stock ≥ 0; início < fim; índice EventID/status/sale window. |
| Cashless · Product | ProductID UUID | EventID, CategoryID NULL | sku, name, creditPrice, status, validFrom/To | UNIQUE(EventID, SKU); preço na venda é snapshot. |
| Cashless · ServicePointProduct | MappingID UUID | ServicePointID, ProductID | localPrice, availability, validFrom/To, status | Vínculo de oferta por PDV e período; UNIQUE composta aprovada. |
| Identidade · Buyer | BuyerID UUID | — | name, email normalized, phone optional, privacyNoticeVersion, createdAt | Dados minimizados; política de retenção aprovada; PII com acesso restrito. |
| Ticketing · Order | OrderID UUID | EventID, BuyerID | publicReference, state, subtotal, fees, total, currency, idempotencyKey, createdAt | UNIQUE(publicReference); idempotency key única no escopo definido. |
| Ticketing · OrderItem | OrderItemID UUID | OrderID, LotID | quantity, unitPrice, lineTotal, category snapshot | quantity > 0; preço histórico é snapshot, não depende do preço atual. |
| Pagamentos · PaymentAttempt | PaymentID UUID | ProviderConnectionID, OrderID/RechargeID/ExternalSaleID XOR | provider, externalPaymentID, method, amount, currency, paymentState, authorizedAt, capturedAt | Exatamente uma origem de negócio; UNIQUE(provider, externalPaymentID) quando existir. |
| Pagamentos · ProviderEvent | ProviderEventID UUID | PaymentID NULL | provider, externalEventID, eventType, receivedAt, signatureValid, sanitizedPayloadRef, processedAt | UNIQUE(provider, externalEventID); segredo/payload sensível não é gravado sem política. |
| Integração · ProviderConnection | ProviderConnectionID UUID | OrganizationID, EventID NULL | provider, integrationType, environment, apiVersion, status, secretRef | Armazena referência ao cofre, nunca segredo; sandbox/produção segregados. |
| Ticketing · Ticket | TicketID UUID | OrderItemID, BuyerID NULL | publicCode, status, issuedAt, cancelledAt | UNIQUE(publicCode); emitir somente após pagamento confirmado. |
| Acesso · AccessScan | ScanID UUID | TicketID, EventID, UserID, ServicePointID NULL | scannedAt, result, deviceRef, offlineFlag | Append-only; decisão de repetição usa transação/estado do ticket. |
| Operação · DeviceRegistration | DeviceID UUID | ServicePointID, UserID NULL | deviceRef, model, appVersion, status, lastSeenAt | Dispositivo autorizado por ponto; identificador mínimo e aprovado. |
| Split · Beneficiary | BeneficiaryID UUID | OrganizationID NULL | legalName, taxIdRef, providerRecipientID, providerStatus | Tax ID protegido; guardar referência PSP, não credencial bancária. |
| Split · SplitRule | SplitRuleID UUID | EventID, ServicePointID NULL, TerminalID NULL | context, version, base, effectiveFrom/To, status, approvedBy, approvedAt | Versão publicada imutável; context = TICKETING / POS / INTERNAL_EXCHANGE. |
| Split · SplitRuleRecipient | RuleRecipientID UUID | SplitRuleID, BeneficiaryID | shareType, shareValue, feeResponsibility, priority | Valor ≥ 0; soma/base valida conforme modelo PSP e regra assinada. |
| Split · SplitAllocation | AllocationID UUID | SplitRuleID, BeneficiaryID, PaymentID NULL, LedgerEntryID NULL, ExternalSaleID NULL | baseAmount, allocatedAmount, currency, providerState, settlementState | Origem financeira definida sem ambiguidade; alocação calculada ≠ liquidada. |
| POS · ExternalTerminal | TerminalID UUID | ProviderConnectionID | serial, model, modality, credentialStatus, status | UNIQUE(provider, serial); número total confrontado com inventário do cliente. |
| POS · TerminalAssignment | AssignmentID UUID | TerminalID, ServicePointID | validFrom/To, assignedBy, status | Histórico preservado; no máximo uma atribuição ativa por terminal conforme regra. |
| POS · ExternalSale | ExternalSaleID UUID | AssignmentID, EventID | saleReference, amount, currency, state, occurredAt | Uma venda correlaciona com terminal/PDV e referência externa. |
| Cashless · Wallet | WalletID UUID | EventID, BuyerID NULL | walletReference, status, createdAt, expiresAt NULL | UNIQUE(EventID, walletReference); carteira pode ter titular opcional. |
| Cashless · CashlessCard | CardID UUID | — | cardUID, modelRef, status, batchRef | UNIQUE(cardUID); UID físico separado do saldo e protegido. |
| Cashless · CardAssignment | CardAssignmentID UUID | CardID, WalletID, UserID | assignedAt, endedAt, status, reason | Histórico de associação; regra de um vínculo ativo por cartão validada transacionalmente. |
| Cashless · Recharge | RechargeID UUID | WalletID | amount, currency, state, idempotencyKey, requestedAt, confirmedAt | UNIQUE(idempotencyKey); crédito só decorre de confirmação verificável. |
| Cashless · LedgerEntry | LedgerEntryID UUID | WalletID, UserID NULL, ServicePointID NULL, PaymentID NULL, sourceEntryID NULL | entryType, signedAmount, currency, sourceType/sourceID, createdAt, reason | Append-only; UNIQUE(sourceType, sourceID, entryType) conforme idempotência; valores DECIMAL. |
| Cashless · CashlessSale | CashlessSaleID UUID | WalletID, ServicePointID, UserID | state, totalCredits, idempotencyKey, occurredAt | UNIQUE(idempotencyKey); débito e venda confirmam atomicamente. |
| Cashless · CashlessSaleItem | CashlessSaleItemID UUID | CashlessSaleID, ProductID | quantity, unitCreditPrice, lineTotal snapshot | quantity > 0; preço histórico retido para auditoria. |
| Cashless · CreditExchangeRule | ExchangeRuleID UUID | EventID | version, sourceUnit, targetUnit, factor, rounding, limits, approvedBy | Versão publicada imutável; fator e arredondamento aprovados pelo cliente. |
| Cashless · CreditExchange | ExchangeID UUID | WalletID, ExchangeRuleID, sourceEntryID, resultEntryID | sourceUnits, targetUnits, rounding, state, idempotencyKey | Origem/destino referenciam lançamentos; troca não implica transferência bancária. |
| Admin · User | UserID UUID | OrganizationID | login, displayName, status, authRef, createdAt | UNIQUE(login) no escopo; senha/segredo pertence ao provedor de identidade. |
| Admin · Role | RoleID UUID | — | code, name, permissionSetVersion | Perfis aprovados; menor privilégio. |
| Admin · UserRole | UserRoleID UUID | UserID, RoleID, EventID NULL, ServicePointID NULL | validFrom/To, grantedBy, status | Escopo evento/ponto e concessão/revogação auditáveis. |
| Auditoria · AuditEvent | AuditEventID UUID | UserID NULL | entityType, entityID, action, timestamp, outcome, beforeAfterSanitized | Append-only; sem senha, token, PAN/CVV ou payload sigiloso. |
| Conciliação · ReconciliationRun | ReconciliationRunID UUID | EventID, UserID | source, periodStart/End, startedAt, completedAt, status | Execuções reproduzíveis; não altera silenciosamente lançamentos originais. |
| Conciliação · ReconciliationItem | ReconciliationItemID UUID | ReconciliationRunID, PaymentID NULL, LedgerEntryID NULL, ExternalSaleID NULL | expectedAmount, observedAmount, currency, matchState, differenceReason | Origem única por item; divergência mantém evidência e responsável. |
Regra de consistência: nenhuma tabela de resumo substitui o ledger/ID do provedor. Valores calculados, autorizados, capturados, liquidados e transferidos são campos/estados diferentes; nada é apagado para “corrigir saldo”.
FATOS FINANCEIROS · GRÃO, MEDIDAS E LINHAGEM
Cada linha de fato representa um acontecimento, nunca um total editável
Relatórios partem de eventos operacionais identificados. A camada de fatos não substitui as tabelas transacionais, não soma grandezas incompatíveis e não confunde valor calculado com dinheiro efetivamente liquidado.
GRAIN / GRÃOGrão define o que exatamente uma linha significa. Uma recarga, um débito de consumo, um pedido de ingresso e uma liquidação PSP são fatos diferentes, com chaves, estados e datas distintos.
- Chave da origem
- OrderItemID + OrderID; EventID, BuyerID quando permitido, LotID e TicketID.
- Medidas aditivas
- Quantity, GrossAmount, DiscountAmount e FeeAmount, sempre com moeda e snapshot.
- Estados separados
- Pedido, pagamento, emissão e validação do ingresso são estados distintos; cancelamento/reembolso é outro evento referenciado.
- Não agregar como
- Liquidação PSP ou dinheiro na conta. Uma compra com 3 ingressos mantém quantidade 3 e uma referência a item conforme o grão.
- Chave da origem
- PaymentID interno e Provider + ExternalPaymentID quando atribuídos.
- Dimensões
- EventID, SourceType (order/recharge/external sale), método, provedor, recebedor e datas.
- Medidas/estados
- Amount, Fee, NetCalculated, AuthorizationState, CaptureState e Settlement/TransferState em colunas independentes.
- Não agregar como
- Venda concluída só por autorização; retry não conta como segundo pedido e transferência não é captura.
- Chave da origem
- LedgerEntryID; WalletID, EventID, CardAssignmentID opcional, ServicePointID, UserID e SourceReference.
- Medidas
- SignedCreditAmount/Units e Currency/UnitType. Um lançamento é crédito, débito, estorno ou ajuste — não dois ao mesmo tempo.
- Regra de saldo
- Saldo no instante = soma de lançamentos válidos da carteira; saldo cacheado é derivado e reconstruível.
- Não agregar como
- Receita PSP: crédito de carteira e consumo de crédito são fatos internos diferentes do dinheiro recebido.
- Chave da origem
- ExchangeID + ExchangeRuleVersionID; referência à entrada de origem e entradas geradas.
- Dimensões
- WalletID, EventID, unidades de origem/destino, ponto/PDV e estado.
- Medidas
- SourceUnits, TargetUnits, FactorSnapshot, RoundingDifference e InternalSplitAllocated.
- Não agregar como
- Transferência bancária ou consumo em dinheiro; o destino depende da regra aprovada pelo contratante.
- Chave da origem
- ExternalSaleID + TerminalAssignmentID vigente + ProviderTransactionID.
- Dimensões
- EventID, localização, ServicePointID, TerminalID/serial, OperatorID, Beneficiary set.
- Medidas/estados
- GrossAmount, Fee, SplitCalculated, ProviderAllocated e SettlementReported em medidas independentes.
- Regra
- Uma linha do POS corresponde ao fato de venda; retries e retornos PSP ficam em PaymentAttempt/ProviderEvent ligados, não geram venda duplicada.
- Chave da origem
- AllocationID; RuleVersionID + BeneficiaryID + fato financeiro que disparou a regra.
- Medidas
- BaseAmount, Share/Percent Snapshot, CalculatedAmount, ProviderAcceptedAmount, SettledAmount e TransferredAmount.
- Regra
- O grão permite somar parcelas por transação sem duplicar o total da venda; guardar currency e rounding adjustment.
- Não agregar como
- Valor repassado quando somente calculado/aceito no pedido.
- Chave da origem
- SettlementItemID ou Provider + ExternalSettlementID; relaciona PaymentID/AllocationID quando o PSP disponibilizar.
- Medidas
- GrossSettled, FeeSettled, NetSettled, TransferAmount, SettlementDate e TransferDate.
- Dimensões
- Provedor, meio, recebedor, evento, moeda e estado da liquidação/transferência.
- Limite
- Sem extrato/retorno bancário, “settled/transferred” não é inferido nem estimado pelo dashboard.
- Chave da origem
- ReconciliationRunID + sourceRecordID; origem local e referência PSP/Stone.
- Medidas/resultado
- ExpectedAmount, ObservedAmount, DifferenceAmount, MatchStatus, DifferenceReason e resolução.
- Regra
- Guardar snapshot do período, arquivo/origem e operador; reteste gera nova execução ou resolução ligada.
- Aceite
- Divergência não é sobrescrita; acompanha responsável, prazo e decisão.
Dimensões e chaves de relatório
Event / EventDate / TimeZoneOrganization / BeneficiaryBuyer (PII restrita)Category / Lot / ProductServicePoint / SectorExternalTerminal / assignmentPaymentProvider / methodCurrency / UnitTypeRuleVersion / split contextState / source system
Consistência de totalizações: não juntar numa única soma bruto de venda, recarga, crédito de carteira, consumo, parcela calculada, liquidação e transferência. Cada visualização informa qual fato/grão usa, quais estados estão incluídos e a moeda/unidade apresentada.
ENTRADAS, DECISÕES E DEPENDÊNCIAS
Aba exclusiva: o que o contratante precisa fornecer
O checklist preenchível da apresentação salva localmente. Esta matriz organiza o que cobrar, prazo, evidência e o que fica bloqueado se faltar.
| Prazo | Informação/material do contratante | Evidência solicitada | Impacto se não recebido/validado |
|---|---|---|---|
| 21/10 | Contrato assinado; responsável decisor, operacional e técnico; contatos de cobrança; kickoff/local e agenda de reuniões. | Ata M0 com nomes, donos, prazos e canal seguro. | Bloqueia baseline/aprovações e início após assinatura. |
| 23/10 | Nome/data/local/capacidade do evento, setores, lotes, produtos, preços, janela, taxas, políticas de cancelamento/reembolso, domínio comprado? titular/registrador/DNS; todos os beneficiários e regras iniciais dos três splits. | Checklist assinado/aprovado e matriz de regra com versão. | Bloqueia configuração comercial, domínio/checkout e memória de cálculo. |
| 26/10 | Se já possui conta Stone; titular/CNPJ; status Connect/API, gerente/contato, PSP de ticketing e cashless, credenciais sandbox, documentação, recebedores e acesso de produção quando disponível. | Conta/teste autenticado, documento de habilitação ou bloqueio formal. Segredos por cofre/canal seguro, nunca por e-mail. | Bloqueia homologação do PSP/Stone e split externo; não declarar integrado. |
| 30/10 | Marca/modelo/protocolo/SDK/API de cartão e leitor; ficha técnica, interface/conexão, fornecedor, serial/amostra; quantidade para teste, operação e reserva. | Datasheet, inventário e confirmação de entrega das amostras. | Não se escolhe nem se garante tecnologia física; compra incompatível é risco do cliente. |
| Até 13/11 | Cartões e leitores de teste físicos, usuários operadores e dispositivos para validação. | Termo de recebimento, leitura/associação na sessão presencial de 16/11. | Homologação física E2 bloqueada; sem equivalência presumida. |
| 20/11 | Número EXATO de POS; fabricante/modelo/serial/ID, PDV/local, conta Stone, beneficiário, estado de credenciamento e disponibilidade de cada máquina. | Inventário integral assinado; amostra/sandbox dos modelos. | POS sem dados/credenciamento não entra no teste nem no aceite E3. |
| 23/11–27/11 | Regra final, beneficiários/CNPJ e percentuais/valores por terminal; matriz independente das regras de ticketing e cashless; base, taxas, estorno e responsabilidade. | Planilha/matriz aprovada por decisor, total/base verificados. | Configuração/split de terminal não pode ser inferido pela MS. |
| Antes de teste E4 | Duração do pico esperado para a meta fixa de 10 TPS, ambiente, usuários de teste, dados representativos e janela de carga autorizada. | Plano de teste aprovado e limites de taxa do PSP/Stone confirmados. | Meta 10 TPS permanece requisito; teste externo pode ser bloqueado por rate limit/ambiente do provedor. |
| 07–09/12 | Validadores UAT, decisão sobre ressalvas, usuários de produção, contatos de escalonamento, local/rede/energia e responsáveis do evento. | UAT, runbook, ata de go/no-go e termo de aceite/rejeição fundamentada. | Não autoriza go-live sem decisão e evidências formalizadas. |
Não enviar: senhas, token, chave privada, PAN/CVV ou dados bancários completos em e-mail, formulário ou planilha. Fornecer apenas status/IDs não secretos; segredo por canal seguro acordado.
CADÊNCIA E EVIDÊNCIAS
Entregáveis demonstráveis toda semana
Reunião online semanal às quartas; exceções presenciais para hardware/POS. Cada subentrega também tem registro por e-mail ou acesso compartilhado com estado, evidência, dono e próxima data.
| Janela | Ritual | Incremento apresentado/entregue | Evidência e entrada de terceiros |
|---|---|---|---|
| 21/10 | Presencial · kickoff | Baseline, responsabilidades, subabas do escopo, checklist e risco/dependência. | Ata M0; contrato assinado; local e hora confirmados. |
| Até 23/10 | Assíncrono + revisão 28/10 | E1.2: estrutura do evento, dados, setores, catálogo e lotes; aprovar três matrizes de split. | Dados comerciais, domínio e políticas aprovados pelo contratante. |
| 28/10 | Online · gate E1 | E1.1: DEV/HML/PROD, login/perfis, trilha inicial; demonstração do cadastro de evento. | Checklist do gate; acesso, conta cloud e dono de domínio. |
| 04/11 | Online | E1.2–E1.3: catálogo final, pedido, estados de checkout, integração PSP em sandbox. | Casos de estoque/lote; PSP, credenciais teste e webhook. |
| 11/11 + marco 19/11 | Online + aceite E1 | E1.4–E1.6: ingresso/validação, comprador/CRM, dashboard, split ticketeria; UAT. | Relatório de casos, QR/código, split sandbox e termo E1. |
| 16/11 | Presencial · hardware | E2.1–E2.2: testar amostra de cartões/leitores e fluxo de cadastro/associação. | Fornecedor, datasheet e amostras entregues até 13/11. |
| 18/11 | Online | E2.3–E2.4: PSP de carga, estados da recarga, crédito idempotente e primeiras consultas do ledger. | PSP de carga aprovado; testes de aprovado/recusado/repetido. |
| 20/11 + 25/11 | Presencial POS + online semanal | 20/11: contar/identificar POS. 25/11: E2.5–E2.6 consumo/troca/conciliação e revisar regras/matriz E3. | Inventário terminal a terminal e regras de split aprovadas até 27/11. |
| 02/12 + marco 04/12 | Online + aceite E3 | E3.3–E3.5: configurar/testar split individual, estado e conciliar cada POS. | Relatório individual de 100% dos POS do escopo; exceções assinadas. |
| 09/12 | Online · UAT/go-no-go E4 | Integração E1–E3, relatório 10 TPS, runbook, treinamento e prontidão. | Testes, blockers, termo E4; folga 10–14/12 reservada para estabilização. |
Formato de acompanhamento: depois de cada reunião, ata curta por e-mail com entregável demonstrado, evidência/link, informação pendente, responsável, prazo e bloqueio. O contratante pode consultar o ambiente/quadro compartilhado; status não substitui aceite formal da entrega-pai.
CONTROLE DE OBJETO E MUDANÇA
Lista fechada de funções e critérios de aceite
Este detalhamento reduz interpretações abertas. O contrato deve incorporar esta matriz ou referenciar sua versão aprovada como anexo funcional.
Incluído somente quando listado
- Abas e ações funcionais especificadas em E1–E4.
- Cadastros/campos descritos ou acordados na matriz do contratante.
- Integrações nominadas: PSP ticketing, PSP de recarga a selecionar e Stone Connect/API elegível para POS.
- Relatórios e filtros enumerados em cada módulo.
- Regras dos três contextos de split aprovadas pelo contratante, sujeitas a capacidade/habilitação do provedor.
- Testes, evidências, treinamento e documentação indicados como entregas.
Fora da base sem aditivo
- Abas, campos, regras, papéis, relatórios ou exports não enumerados.
- Outras ticketerias/PSPs, outros adquirentes, POS ou modelos de cartões fora da matriz homologada.
- Nox ou outra plataforma cashless pronta; carteira interoperável de terceiros.
- Assento marcado, app nativo, offline, catraca, cancela, ERP/estoque/fiscal, programa externo de fidelidade ou marketplace.
- Automação de estorno/transferência/repasse que o PSP não habilite; pagamento bancário do split interno.
- Hardware, cloud, domínio, SMS/e-mail, taxas, licença, serviço presencial/plantão e suporte/manutenção contínuos.
Qualquer mudança segue este rito
- Pedido escrito com cenário, usuário e resultado esperado.
- Classificação: defeito contra critério aprovado, dependência externa ou funcionalidade nova.
- Análise de impacto em módulos, dados, API, segurança, prazo, custo, teste e aceite.
- Aprovação formal de representantes de ambas as partes antes de desenvolver.
- Nova versão deste caderno/contrato, cronograma e critério de aceite anexados.
Suporte/manutenção: não há valor mensal ou faixa estimada neste escopo. Após conclusão e aceite do desenvolvimento, necessidade, janela, canais, SLA e preço serão avaliados e negociados separadamente.