ERP de cada empresa: títulos, parcelas, baixas e movimento bancário
Tipo de operação, rateio e grão certo para cada relatório
A pagar, a receber, pagas e recebidas por empresa e mês
Fechamento, dashboard do grupo e agente de IA
O que resolve
- Uma visão única de contas a pagar e a receber de todas as empresas, sem abrir o ERP empresa por empresa.
- Os números batem com os relatórios oficiais do ERP, linha a linha.
- O custo pago por centro de custo para de inflar com substituições e cancelamentos de título.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- O ERP conectado na Nekt, com todas as empresas do grupo
- Os relatórios oficiais do ERP de um período fechado, em planilha, para a validação
- A lista de empresas, SPEs e centros de custo com o empreendimento de cada um
O que você recebe
- Quatro tabelas: a pagar, a receber, pagas e recebidas, com os nomes de coluna do relatório
- Uma validação automática contra o relatório oficial, que bloqueia o uso se divergir
- Dashboard do grupo por empresa, centro de custo e mês
- Um agente de IA que responde sobre o financeiro sem misturar grãos
Onde ativar
As quatro tabelas exportadas para a planilha do financeiro, já validadas contra o ERP.
Responde saldo, pago e recebido por empresa e centro de custo, com o grão certo.
Avisa o financeiro quando uma empresa sai de OK, antes de o painel ser usado.
As regras são conhecidas, mas cada coluna precisa ser conferida contra o relatório oficial. Conte com uma rodada de validação por relatório. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
Cada SPE ou CNPJ é uma empresa separada no ERP, e o grupo quer uma visão só que bata com o relatório oficial. Os títulos vêm com arrays aninhados de baixas, categorias e obras, e com tipos de operação que não são dinheiro. Somar sem filtrar o tipo de operação infla o pago em 30% a 50%, e juntar parcelas com baixas sem agregar duplica linhas.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Toda tabela carrega o id da empresa (companyId no Sienge, a fonte de origem no Omie, o realm no QuickBooks). A administradora do grupo é uma empresa como as outras. Consolide só quando a pergunta for do grupo, e mostre a abertura por empresa ao lado.
A pagar e a receber têm grão de parcela de título (billId + installmentId), em aberto ou quitada. Pagas e recebidas têm grão de baixa: uma parcela pode ter várias baixas. Para saber quanto foi pago de um título, agregue as baixas por parcela antes de cruzar.
No array payments do Sienge, conte apenas operationTypeName 'Pagamento' e 'Adiantamento'. 'Substituição' e 'Cancelamento' são movimentações de título, não custo, e inflam a soma em 30% a 50%. Com essa regra, o warehouse bateu com o BI anterior com desvio abaixo de 0,5%.
No array receipts, receita recebida é operationTypeName 'Recebimento', pelo valor líquido (netAmount). Reparcelamento, distrato e substituição são reclassificações da carteira e ficam fora. Juros, correção monetária, multa e desconto ficam em colunas próprias.
No Sienge, 'Valor no vencimento' do a pagar é correctedBalanceAmount (saldo já corrigido pelo indexador). 'Desconto' do relatório é taxAmount, que são as retenções de ISS, INSS e IR. 'Valor original' do a receber é balanceAmount (saldo não corrigido), e não o originalAmount do título.
Desaninhe paymentsCategories e multiplique por financialCategoryRate / 100 (nulo vale 100). Para obra, desaninhe buildingsCosts e aplique o rate da obra. No Omie, desaninhe departamentos e use n_distr_percentual. Sem aplicar o percentual, cada categoria recebe o valor inteiro.
Uma baixa com juros gera duas ou mais linhas em sienge_bank_movement (principal e acréscimos). O grão de pagas e recebidas é a baixa. Movimentos bancários avulsos (tarifas, aportes entre empresas, retiradas de sócio, rendimentos) entram com uma coluna de origem, porque são caixa, mas ficam fora da comparação com o relatório de títulos.
Comprometido em aberto = (balanceAmount - taxAmount - discountAmount) x rate / 100, datado pelo vencimento. Notas de serviço em aberto com retenção de imposto inflavam o saldo quando o imposto não saía.
No Omie, cada empresa é uma conexão. Trate cada uma com a mesma transformação e una com uma coluna de origem. Datas do Omie chegam como texto dd/mm/aaaa e precisam de conversão explícita. Em QuickBooks, exclua Transfer e Journal Entry do fluxo de caixa e nunca some a visão de caixa puro com a categorizada: o pagamento da fatura do cartão é o mesmo dinheiro.
Compare cada tabela com o relatório oficial por empresa e mês, com tolerância de 0,01. Classifique em OK, OK explicado (diferença conhecida e nomeada, item a item) ou Diferença. Qualquer Diferença bloqueia o painel e o export até ser explicada.
Relatório do ERP para campo
Mapa validado contra os relatórios oficiais do Sienge.
Definições
Armadilhas que já aconteceram
A soma de todo o array de pagamentos incluía substituições e cancelamentos de título.
Filtre Pagamento e Adiantamento antes de somar.
Cruzar a tabela de parcelas com a de baixas multiplicou o saldo de títulos pagos em várias vezes.
Agregue as baixas por parcela antes do join.
A coluna Desconto do relatório não batia com discountAmount porque, no relatório, desconto são as retenções.
Use taxAmount e valide coluna a coluna.
Títulos anteriores a um certo ano não vinham no endpoint padrão de contas a pagar.
Complete com o endpoint por título e confira o total de um ano antigo.
A carga histórica do ERP parou no meio porque a API tem cota diária pequena.
Faça o histórico em blocos de 12 meses com uma tabela de estado da carga.
Uma SPE nova foi cadastrada no ERP e ficou fora da visão do grupo por semanas.
Compare a lista de empresas do ERP com a da tabela a cada carga e alerte quando surgir uma nova.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Para um período fechado, o contas a pagar por vencimento bate com o relatório oficial do ERP em número de linhas e em valor, por empresa (diferença abaixo de 0,01).
- O contas pagas do período bate linha a linha com o relatório de contas pagas por data.
- O contas a receber bate com o relatório oficial em saldo total e número de parcelas.
- A soma por empresa é igual ao consolidado do grupo.
- Nenhum valor pago tem tipo de operação diferente de Pagamento ou Adiantamento.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Financeiro multiempresa (ERP) - Toda análise é por empresa (companyId). Consolide só quando a pergunta for do grupo e mostre a abertura por empresa. - Grãos: a pagar e a receber = parcela de título (billId + installmentId). Pagas e recebidas = baixa. Nunca junte os dois sem agregar as baixas por parcela. - Valor pago = payments.grossAmount x financialCategoryRate / 100, só com operationTypeName 'Pagamento' ou 'Adiantamento'. Substituição e Cancelamento não são custo. - Receita recebida = receipts.netAmount com operationTypeName 'Recebimento'. Reparcelamento, distrato e substituição ficam fora. - financialCategoryRate nulo vale 100. Rateio por obra usa buildingsCosts.rate. - Relatório a pagar: Valor no vencimento = correctedBalanceAmount; Desconto = taxAmount (retenções). Relatório a receber: Valor original = balanceAmount. - Movimentos bancários avulsos (tarifas, aportes, retiradas, rendimentos) são caixa, mas não aparecem no relatório de títulos: vêm marcados pela origem. - Só use as tabelas quando a validação contra o relatório oficial estiver OK ou OK explicado. Exceções por cliente: - <cliente>: empresa <id> é a administradora; SPEs <ids> correspondem a <empreendimentos>. - <cliente>: centro de custo da administração central = <id>. - <cliente>: diferenças conhecidas e aceitas na validação: <lista nomeada>.
Construa no meu workspace Nekt o caso "Contas a pagar e a receber por empresa e SPE" seguindo as regras em https://academy.nekt.com/industrias/imobiliario/financeiro-erp-por-spe.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Custo pago do centro de custo da administração dividido pela receita recebida de todas as obras, com e sem distribuição de lucros.
Omie: uma conexão por empresa, departamentos por n_distr_percentual. Conta Azul: desaninhe o rateio por categoria e depois por centro de custo da parcela.
P&L por empresa e mês validado contra o relatório nativo, saldos entre empresas do grupo e semáforo de liberação por empresa.