Exportar lançamentos para o contador

Em Configurações da empresa ▸ Contabilidade: (1) o SISTEMA do seu escritório — Domínio, Alterdata ou Questor; (2) o CÓDIGO da sua empresa lá dentro, que o contador informa; (3) o CÓDIGO DO HISTÓRICO padrão, que os três layouts exigem além do texto. Sem o sistema escolhido a geração recusa e diz o que falta — de propósito: escolher um layout por você produziria um arquivo plausível e errado, que só o contador descobriria.

Os três layouts esperam o código da conta NO PLANO DO ESCRITÓRIO (um número reduzido), não o código hierárquico do Tenka (1.1.01). Esse número mora no campo "código externo" do plano de contas. Conta sem ele sai com o código do Tenka e o importador vai RECUSAR aquela linha — a tela lista quais são, nominalmente. Recusa visível é melhor que um número parecido importado numa conta alheia.

Centro de custo (registro 6110 do Domínio, colunas H e I do Alterdata) sai VAZIO, porque não existe de-para entre o centro de custo do Tenka e o código do centro no sistema do escritório — mandar o número do Tenka rateia para o centro que por acaso tenha aquele valor lá. Pelo mesmo motivo, o campo de "lançamento automático" do Alterdata sai vazio: ele aponta para um modelo cadastrado dentro do Alterdata, e o modelo manda nas contas.

A configuração é POR EMPRESA, e esse é o caso comum: num grupo multi-CNPJ cada empresa costuma estar num escritório contábil diferente, e o layout segue o escritório, não o grupo. Quem tem um escritório só para o grupo inteiro preenche no TENANT: o valor do tenant vale para todas as empresas que não sobrescreverem.

Todo lançamento automático do Tenka nasce com competência no dia 1 do mês. Para o balancete tanto faz; para o Domínio e o Alterdata não, porque eles pedem a DATA DO LANÇAMENTO. Então a data é reconstruída: recebimento e pagamento usam a data da BAIXA do título, faturamento usa o VENCIMENTO. Quando não há título atrás — folha, impostos, depreciação —, a data vira o ÚLTIMO DIA DO MÊS, que é a data contábil correta de uma provisão de fechamento. A tela conta quantas linhas estão nessa condição, e a contagem vai gravada junto com o arquivo. Aproximação declarada é aproximação; aproximação calada é erro.

A folha do mês é um lançamento só com três partidas: débito em Despesas com Pessoal, crédito em Salários a Pagar e crédito em Impostos a Recolher. Os três layouts só aceitam linha de PAR (uma conta a débito, uma a crédito). O Tenka desdobra esse lançamento em duas linhas cuja soma é idêntica à do lançamento original — é o mesmo que o contador faria à mão. O que ele NÃO faz é mandar só a primeira dupla: isso perderia dinheiro sem erro nenhum.

Se em algum lançamento a soma dos débitos não for igual à dos créditos, ele fica FORA do arquivo e aparece na lista de recusados, com o número e a diferença. Dois motivos: o Questor recusa o arquivo INTEIRO quando encontra diferença entre débito e crédito, e o Domínio aceitaria o lote torto sem reclamar — das duas, a segunda é pior. Diferença é defeito da contabilização, e o lugar de consertá-la é em Contabilidade ▸ Contabilizar.

Porque os três importadores são Windows legado e leem em CP1252. Um arquivo UTF-8 não dá erro: ele importa e grava "PROVISÃO" com os acentos trocados no razão do cliente — defeito que só aparece semanas depois, num relatório impresso. O parâmetro de codificação existe para o caso de o seu escritório confirmar que lê UTF-8; em branco, sai no padrão do layout. E o arquivo é baixado SEMPRE na codificação com que foi selado, mesmo que o parâmetro mude depois: senão o hash deixaria de bater.

Não. A gravação é idempotente por empresa + layout + período: regerar substitui o arquivo daquele mês naquele layout, em vez de empilhar cópias. E como as linhas saem sempre na mesma ordem, regerar o mesmo período produz o MESMO arquivo — é isso que faz o hash SHA-256 servir para conferir com o contador que o que ele recebeu é o que você mandou.