Como os módulos de um ERP se integram realmente

A palavra integrado esconde três coisas diferentes

Quase todas as brochuras de ERP usam a palavra integrado. Por trás dela escondem-se pelo menos três arranjos que se comportam de forma muito diferente quando algo corre mal no fecho do mês. O primeiro é a transferência por ficheiro ou em lote agendado: um sistema exporta, outro importa, geralmente durante a noite. O segundo é a sincronização por API ou middleware, em que duas bases de dados separadas se mantêm alinhadas trocando mensagens. O terceiro são dados verdadeiramente partilhados, em que os módulos não são sistemas separados, mas vistas diferentes sobre um único conjunto de tabelas, um único razão geral e um único conjunto de registos-mestre.

Nenhum destes é universalmente correto. A transferência em lote é barata, fácil de compreender e sobrevive a uma falha de qualquer dos lados, porque o ficheiro simplesmente fica à espera. Mas está sempre desatualizada por conceção, e uma tarefa falhada pode passar despercebida até alguém questionar um relatório. A sincronização por API proporciona um comportamento quase em tempo real e permite manter sistemas que há boas razões para manter, mas passa a ser dono de um sistema distribuído: novas tentativas, ordenação, falhas parciais e duas cópias da verdade que podem discordar. Os dados partilhados eliminam a categoria de problemas em que duas bases de dados divergem, porque só existe uma, mas obrigam os módulos a acordar num único plano de contas, numa única definição de artigo e num único ritmo de atualizações, o que é uma restrição e não um benefício gratuito.

A questão prática não é qual o melhor nível, mas qual o nível que cada fluxo merece. Transferir um extrato bancário durante a noite não tem problema. Transferir durante a noite os níveis de stock que estão por trás de um ponto de venda em funcionamento tem. O Skyline Nexus situa-se no terceiro nível para os seus próprios módulos: contabilidade, ponto de venda e inventário, CRM, manutenção, recursos humanos, frota e ativos escrevem num único razão e num único conjunto de dados-mestre, e integram-se para o exterior por API quando o cliente já tem um sistema que vale a pena manter.

É nos dados-mestre que a divergência começa

As falhas de integração costumam ser atribuídas às interfaces, mas a primeira fissura é normalmente um registo-mestre que existe em duplicado com conteúdo ligeiramente diferente. Quando dois sistemas guardam cada um a sua lista de clientes, as listas divergem em poucas semanas, e todos os números a jusante herdam essa divergência.

• Cliente: uma única identidade para vendas, faturação, recebimentos e controlo de crédito, caso contrário a antiguidade de saldos não coincidirá com o relatório de vendas.
• Fornecedor: partilhado entre compras, contas a pagar e pagamentos, incluindo os dados bancários, que são alvo de fraude quando duplicados.
• Artigo: um código, uma unidade de medida, um método de custeio. Duas fichas de artigos significam duas valorizações de stock.
• Plano de contas: uma estrutura única. Se um módulo mantém a sua própria lista de contas e a mapeia para a sua, o mapeamento é mais uma coisa a manter e a errar.
• Códigos de imposto: uma única definição de taxa, tratamento e datas de vigência, usada tanto pela transação como pela declaração.
• Filial e localização: partilhadas, porque tanto o stock como a contabilidade são dimensionados por elas.
• Colaborador: um único registo por trás de processamento salarial, assiduidade, ordens de trabalho de manutenção e atribuição de viaturas.
• Ativo: um único registo por trás da depreciação, do histórico de manutenção e da alienação.

Razões auxiliares e a conta de controlo

O razão geral guarda saldos resumidos. O detalhe está nos razões auxiliares, e cada razão auxiliar está ligado a uma conta de controlo no razão geral. As contas a receber guardam uma linha por fatura e recebimento de cada cliente, cuja soma é a conta de controlo de clientes. As contas a pagar fazem o mesmo para as faturas de fornecedores. Os movimentos de inventário são lançados numa conta de controlo de existências, sendo o custo das mercadorias vendidas reconhecido à medida que os bens saem. O processamento salarial lança a remuneração bruta, os encargos da entidade patronal, os descontos e os passivos líquidos. Os ativos fixos lançam aquisições, depreciações e alienações contra o custo do ativo e a depreciação acumulada. O ponto de venda lança as vendas, o imposto cobrado, os meios de pagamento e, quando se usa inventário permanente, o lado do custo de cada venda.

A regra que torna isto fiável é simples: o razão auxiliar tem de conciliar sempre com a sua conta de controlo, até à unidade monetária. Se a antiguidade de saldos de clientes indica um valor e a conta de controlo de clientes indica outro, um deles está errado e não é possível saber qual sem investigar. É por isso que os lançamentos manuais diretos em contas de controlo são normalmente bloqueados. Um lançamento manual em clientes cria um saldo que nenhum cliente deve, e que não aparecerá em nenhum extrato que envie.

A conciliação deve ser um relatório que se executa a pedido, não uma folha de cálculo que alguém mantém. Quando os módulos partilham um único razão, a conciliação é quase tautológica. Quando não partilham, é o controlo mais importante que pode automatizar.

Regras de lançamento e a pista de auditoria

Cada linha do razão deve ser rastreável até um documento de origem: um número de fatura, uma receção de mercadorias, um processamento salarial, um plano de depreciação, uma transação de ponto de venda. Se existe uma linha sem origem, alguém contornou o processo. O identificador do documento deve acompanhar a linha do razão, e não ficar numa tabela de correspondências à parte.

Os lançamentos efetuados não devem ser editáveis em silêncio. As correções fazem-se por lançamentos de estorno ou notas de crédito, que deixam visíveis tanto o original como a correção, cada um com a sua data e o seu utilizador. O fecho do período deve bloquear o período, em vez de depender de as pessoas se lembrarem de não lançar com datas retroativas. O teste é saber se consegue pegar em qualquer saldo, abri-lo e descer até aos documentos que o produziram sem sair do sistema.

Onde as integrações realmente falham

Os modos de falha são bem conhecidos e são quase sempre os mesmos.

• Momento e corte: uma venda lançada pouco antes da meia-noite do último dia do período chega ao outro sistema depois do corte, e os dois períodos nunca coincidem.
• Tarefas falhadas que ninguém vigia: uma transferência agendada deixa de correr e a ausência de dados parece apenas uma semana calma.
• Escritas parciais: o cabeçalho da fatura é criado, as linhas falham, e um dos lados passa a ter um documento que o outro não reconhece.
• Chaves duplicadas: uma mensagem reenviada cria uma segunda cópia da mesma fatura, ou uma numeração colide entre filiais.
• Deriva cambial e de arredondamento: dois sistemas que arredondam em pontos diferentes, ou que usam taxas diferentes para o mesmo dia, produzem pequenas diferenças que se acumulam.
• Imposto calculado duas vezes: o sistema transacional e o sistema contabilístico calculam cada um o imposto, com regras ligeiramente diferentes quanto a descontos, preços com imposto incluído ou arredondamento por linha versus por documento. A fatura entregue ao cliente e o valor da declaração deixam então de coincidir.

Idempotência e prova de que os dois lados coincidem

Tudo o que pode ser repetido será repetido, pelo que cada operação de lançamento precisa de uma chave estável derivada do documento de origem. Enviar a mesma fatura duas vezes tem de resultar num único lançamento, não em dois. O lado recetor deve registar as chaves que já processou e devolver o resultado anterior em vez de criar um novo. Sem isto, o comportamento normal da rede transforma-se em rédito duplicado.

A par disso, precisa da conciliação como funcionalidade de primeira linha: contagens e totais por período e por tipo de documento, comparados dos dois lados, com as diferenças listadas e não resumidas. Um visto verde que apenas diz que a última tarefa correu bem não é prova de concordância. O relatório útil é o que identifica os sete documentos que existem de um lado e não do outro.

Filiais e moedas

Operar com várias filiais significa que cada transação transporta a sua localização como dimensão desde o momento em que é criada, e não atribuída mais tarde pela lógica de um relatório. Stock, rédito, custos e pessoal pertencem todos a uma filial, e as transferências entre filiais precisam de ter ambos os lados lançados, caso contrário os valores de stock das duas filiais não somarão o valor da empresa. A numeração dos documentos tem de ser única entre filiais e, ao mesmo tempo, significativa dentro de cada uma.

A multimoeda exige que a moeda da transação, a taxa usada e o montante na moeda base fiquem todos guardados na linha. Guardar apenas o valor convertido descarta a evidência. A atualização cambial dos saldos em aberto e o ganho ou perda realizado na liquidação passam então a ter onde ser lançados, e a diferença de câmbio deixa de ser um mistério de arredondamento.

Nota regional: a validação prévia altera o calendário

Quando se aplica um regime de faturação eletrónica, o momento da integração deixa de ser uma preferência de conceção. Várias autoridades tributárias exigem hoje que as faturas sejam validadas ou comunicadas à autoridade antes de chegarem ao comprador ou no momento em que chegam. O regime da ZATCA na Arábia Saudita é um exemplo em vigor: as faturas são geradas com uma estrutura definida, elementos criptográficos e identificadores, e a autoridade intervém no ciclo de vida do documento em vez de receber um resumo depois. Isso faz da criação da fatura um problema de integração em tempo real. Um lote noturno não consegue produzir um documento que o cliente está à espera de receber ao balcão.

O panorama é diferente noutros lugares, e vale a pena ser preciso. Os Estados Unidos não têm qualquer obrigação federal de faturação eletrónica, e o imposto sobre vendas é administrado ao nível estadual, com regras e taxas que variam por estado e muitas vezes por jurisdição local. O Canadá aplica o GST e o HST a nível federal com variações provinciais, incluindo impostos provinciais sobre vendas em algumas províncias. Os restantes mercados da região MENA estão em fases diferentes. A lição de conceção é manter a determinação do imposto e a emissão de documentos num único local, para que um mercado que passe da comunicação para a validação prévia altere a configuração e não a arquitetura. O Skyline Nexus trata a validação ZATCA a partir da mesma transação que escreve o lançamento no razão, pelo que a fatura que o cliente recebe e o valor da declaração provêm de um único cálculo.