Como registar uma venda

O que está a criar quando regista uma venda

Uma venda no Skyline Nexus é uma linha na tabela de transações com o tipo sell, mais um conjunto de linhas de venda, mais zero ou mais registos de pagamento. Estas três coisas estão separadas de propósito. A fatura é o crédito sobre o cliente. As linhas são o que saiu da prateleira. Os pagamentos são o dinheiro que entrou. A maior parte da confusão que as pessoas têm com vendas num ERP vem de tratar estas três coisas como um único acontecimento, porque ao balcão de uma loja acontecem normalmente no mesmo segundo.

Para a contabilidade não são o mesmo acontecimento. A fatura gera rendimento e uma conta a receber. As linhas dão saída ao stock e geram o custo das vendas. O pagamento liquida a conta a receber e movimenta a tesouraria. Se vender a crédito, o pagamento acontece semanas depois e a conta a receber fica no balanço entretanto. Se receber um adiantamento, o dinheiro chega antes de a fatura existir. O sistema modela todos estes casos porque todos acontecem em empresas reais.

Por isso, a pergunta prática quando regista uma venda não é só que botões carregar. É: qual destas três coisas estou a criar agora, e qual estou deliberadamente a não criar ainda? A resposta é decidida quase por inteiro por um único campo do formulário, o campo «Estado», tratado mais abaixo.

Três portas para o mesmo documento

O menu lateral tem um menu suspenso chamado «Venda». Dentro dele encontra várias entradas que acabam todas por gravar o mesmo tipo de documento, diferindo apenas na quantidade do formulário que lhe mostram e na rapidez com que se preenchem.

Os documentos finalizados aparecem em «Todas as vendas» (/sells), seja qual for a porta usada. Os rascunhos e as cotações têm as suas próprias listas, «Lista de rascunhos» (/sells/drafts) e «Lista de orçamentos» (/sells/quotations), porque ainda não são faturas reais e não devem encher a lista de vendas. Os talões do ponto de venda aparecem também à parte, em «Lista de vendas POS» (/pos).

Um pormenor de implementação que vale a pena conhecer, porque explica certos comportamentos: o formulário «Adicionar venda» submete para o mesmo controlador que o ecrã PDV. São duas interfaces sobre uma única rotina de gravação. É por isso que as regras de imposto, as regras de stock e o lançamento contabilístico são idênticos seja qual for o ecrã de partida, e é por isso que não deve esperar que a contabilidade trate um talão do PDV e uma fatura de «Adicionar venda» de forma diferente.

• «POS» (/pos/create) é o ecrã de balcão pensado para ecrã tátil. Um cliente, uma grelha de produtos, um painel de pagamento, e fica feito em poucos segundos. É a porta certa para o retalho, a restauração e qualquer venda ao balcão.
• «Adicionar venda» (/sells/create) é o formulário de fatura completo. Todos os campos estão visíveis: esquema de faturação, moeda, prazo de pagamento, envio, campos personalizados, várias linhas de pagamento. É a porta certa para uma fatura B2B, uma venda com entrega ou qualquer venda com condições de crédito.
• «Venda direta» (/sells/direct/create) é uma versão abreviada de «Adicionar venda» para faturas simples.
• «Adicionar rascunho» (/sells/create?status=draft) e «Adicionar orçamento» (/sells/create?status=quotation) abrem outra vez o mesmo formulário, com o estado já definido, para que não seja possível finalizar por engano.
• «Adicionar encomenda de cliente» (/sells/create?sale_type=sales_order) regista uma encomenda de cliente que será faturada mais tarde. Só aparece quando as encomendas de clientes estão ativadas nas definições do PDV.

Preencher o ecrã «Adicionar venda»

O primeiro cartão é «Detalhes de vendas». «Selecionar localização» é obrigatório e não é cosmético: decide de que stock a venda sai, que sequência de numeração de faturas é usada, que contas de pagamento são propostas e, se emitir faturas eletrónicas, se a venda é sequer comunicada, porque a faturação eletrónica é ativada por local. «Esquema da fatura» controla o número que a fatura recebe. «Data de venda» é a data contabilística do documento e, por omissão, é o momento atual. «Moeda da fatura» e «Taxa de câmbio para SAR» só aparecem quando a venda em moeda estrangeira está configurada.

O campo «N.º da fatura» é deliberadamente difícil de alcançar. Só aparece para utilizadores com permissão para editar números de fatura, e só enquanto o documento é um rascunho, com o texto de ajuda «Mantenha em branco para gerar automaticamente». É o desenho correto. Um número de fatura que um operador de caixa pode reescrever não é uma sequência, e uma sequência quebrada é a primeira coisa que um inspetor tributário nota.

O cartão do cliente recebe o contacto («Cliente») e o «Prazo de pagamento», introduzido como um número mais uma unidade, «Meses» ou «dias». Não há um campo separado de data de vencimento neste ecrã: o vencimento é derivado do prazo de pagamento e, se o deixar em branco, é usado o prazo predefinido do próprio cliente. É por isso que vale a pena gastar cinco minutos a definir os prazos de pagamento na ficha do cliente em vez de em cada fatura.

O estado decide quase tudo

O campo «Estado» em «Adicionar venda» oferece «Final», «Rascunho», «Orçamento» e «Proforma». É o campo com mais consequências de todo o formulário, porque quase todos os comportamentos a jusante dependem dele.

Há uma exceção deliberada à regra do rascunho, e convém conhecê-la antes que o surpreenda. Uma definição da empresa, nas definições do PDV, chamada «Deduzir stock nas faturas em rascunho», faz com que os simples rascunhos reduzam o stock no momento da gravação e contem nos relatórios de vendas, de lucro, de custo das vendas e de fluxos de caixa exatamente como uma venda a dinheiro finalizada. Está desligada por omissão, e o texto de ajuda do produto di-lo claramente. Ligue-a apenas se usar mesmo os rascunhos como documentos de separação de mercadoria, e tenha presente que, a partir daí, os rascunhos passam a ter efeito financeiro real.

A regra prática: se a mercadoria saiu e o cliente lhe deve, o estado é «Final». Em qualquer outro caso está a registar uma intenção, não uma transação. Não use o rascunho como forma de evitar um erro que receia, porque um rascunho que nunca é finalizado é uma venda que nunca aparece em lado nenhum.

• «Final» é uma fatura real. Reduz o stock, aceita pagamentos, pode ser lançada no razão geral e, onde a faturação eletrónica está ativa, é comunicada à autoridade tributária.
• «Rascunho» é um trabalho em curso. Não é lançado na contabilidade e não aceita pagamentos: a rotina de gravação recusa-se a criar registos de pagamento para uma venda cujo estado seja rascunho, cotação ou proforma. Por omissão, também não mexe no stock.
• «Orçamento» é uma proposta. Nada se movimenta. Nem stock, nem contabilidade, nem pagamento.
• «Proforma» é um documento prévio à fatura. Tal como a cotação, não movimenta nada.

Como é calculado o imposto numa venda

O imposto pode entrar numa venda a dois níveis, e a diferença importa. O imposto de linha é uma taxa associada a uma linha de produto individual. O imposto do documento é uma taxa única aplicada ao documento no seu todo, escolhida no campo «Imposto da encomenda», por baixo da grelha de produtos. A maioria das empresas usa um ou outro. Usar os dois no mesmo documento é onde as pessoas se metem em sarilhos noutros sistemas, e o Skyline Nexus foi construído para impedir precisamente esse erro.

O imposto do documento incide sobre uma base que exclui as linhas que já têm o seu próprio imposto de linha. Uma linha cuja taxa seja igual à taxa do cabeçalho não contribui nada para a base do imposto do cabeçalho. Em termos simples: o sistema não cobra IVA sobre IVA, e não cobra duas vezes uma linha que já está tributada à taxa do documento. Trata-se de uma regra de cálculo na rotina de totais da fatura, e não de uma opção que tenha de se lembrar de assinalar.

O facto de um preço ser indicado com ou sem imposto é uma propriedade do produto, e não da fatura. No formulário do produto existe um campo chamado «Tipo de imposto sobre o preço de venda», com as opções «Incluído» e «não incluído». A linha guarda então os dois valores, o preço unitário sem imposto e o preço unitário com imposto, para que a fatura possa mostrar qualquer um deles sem recalcular. O seletor de imposto por linha no formulário de venda só aparece se o imposto em linha estiver ativado para a empresa; se estiver desligado, o imposto vem do produto e do campo de imposto do documento.

O arredondamento é uma definição da empresa e não uma decisão fatura a fatura. Por omissão, soma-se com a precisão total e arredonda-se a fatura uma única vez no fim, em vez de arredondar cada linha e somar os valores arredondados. Os dois métodos diferem em poucas unidades da subunidade monetária numa fatura longa, o que é irrelevante para um cliente e muito relevante para uma declaração de IVA que tem de bater certo com a contabilidade.

O pagamento é um registo separado da fatura

O cartão «Adicionar pagamento», no fundo do formulário, é opcional. Cada linha de pagamento pede «Valor», «Pago em», «Método de pagamento» e «Conta de pagamento», mais uma «Nota de pagamento» opcional. «Adicionar linha de pagamento» permite repartir uma fatura por vários meios de pagamento, que é o que se quer quando um cliente paga parte em numerário e parte com cartão. Por baixo das linhas aparecem «Total a pagar», «Pagamento total», «Troco» e «Saldo».

Se a venda for a crédito, assinale «Venda a crédito — valor total em dívida». Isso põe o valor do pagamento a zero, esconde as linhas de pagamento e diz à rotina de gravação para não criar registo de pagamento nenhum. A fatura é emitida, a conta a receber fica em aberto e o dinheiro é cobrado mais tarde. É esta a forma correta de registar uma venda a crédito; introduzir uma linha de pagamento de valor zero não é.

O estado de pagamento do documento é derivado, não introduzido. É pago quando o total recebido é pelo menos igual ao total da fatura, parcial quando foi recebido algo mas não tudo, e em dívida quando nada foi recebido. Esta derivação corre de novo sempre que um pagamento é adicionado, editado ou eliminado, e é por isso que deve cobrar os pagamentos posteriores através de «Adicionar pagamento» na lista de vendas (/payments/add_payment/{id}) e não editando a fatura. Editar a fatura para os números baterem certo é o instinto errado, e esse tema é tratado no guia sobre anular e corrigir transações.

O que a venda faz ao stock

Quando uma venda é gravada como «Final», cada linha reduz a quantidade disponível dessa variação de produto nesse local da empresa. Os produtos sem controlo de stock são ignorados: a rotina de baixa não faz nada para um produto com a gestão de stock desligada, e é assim que se vendem serviços e mão de obra pelo mesmo ecrã sem gerar stock negativo.

Corre depois um segundo passo que raramente se vê e que convém conhecer. Cada quantidade vendida é imputada às linhas de compra concretas de onde veio, e essa imputação fica guardada. É esse mapeamento que torna o custo das vendas real e não estimado: o sistema sabe que compra, a que custo, abasteceu que venda. É também isso que faz cumprir as regras de lote e de validade, e que permite ao software recusar uma venda acima do stock quando essa venda não é permitida.

Como essa imputação é construída no momento da venda, uma venda registada com semanas de atraso contra stock que entretanto se movimentou será imputada de forma diferente da que teria sido na altura. Não é um erro, é aritmética, e é o argumento prático mais forte para registar as vendas no próprio dia em que acontecem.

O que é lançado no razão geral

Uma venda final dispara um evento interno, e o módulo de contabilidade está à escuta. Se tudo estiver configurado, esse processo cria um lançamento contabilístico. O lançamento debita a conta de controlo de clientes pelo total da fatura, credita rendimentos pelo valor líquido e credita IVA liquidado pelo imposto. Os rendimentos são repartidos por categoria de produto quando as categorias têm as suas próprias contas de rendimento, pelo que uma empresa que vende mercadorias e serviços os vê separados na demonstração de resultados sem qualquer análise manual.

Há três condições que têm de se verificar todas, caso contrário nada é lançado, e vale a pena confirmar as três antes de concluir que a contabilidade está avariada. Primeiro, a venda tem de estar em «Final». Rascunhos, cotações e proformas são ignorados por desenho. Segundo, a empresa tem de ter «Contabilizar automaticamente transações de venda» ligado nas definições de contabilidade, em /accounting/settings. Terceiro, as contas têm de estar mapeadas: uma conta de clientes, uma conta de rendimentos e uma conta de IVA liquidado, configuradas em /accounting/settings/mapping. Um mapeamento em falta não corrompe nada; simplesmente recusa o lançamento.

Há um quarto filtro que apanha as pessoas no fecho do mês: o período fiscal que abrange a data da venda tem de estar aberto. Se o período tiver sido fechado ou bloqueado, o lançamento é rejeitado em vez de ser silenciosamente registado num mês já fechado. É o comportamento correto e é a razão de ser do fecho de um período, mas significa que uma venda datada num mês bloqueado precisa que o período seja reaberto ou que a data seja corrigida antes de chegar à contabilidade.

Faturação eletrónica, onde se aplica

Na Arábia Saudita, o módulo de faturação eletrónica gera e comunica a fatura automaticamente quando uma venda é gravada como «Final». É ativado por local da empresa e não para a empresa inteira, pelo que uma sociedade pode ter um local sob o regime de faturação eletrónica e outro ainda não inscrito. A configuração está em /zatca/configuration.

A comunicação é idempotente: o sistema regista o que já foi comunicado e não comunica a mesma fatura duas vezes. Se uma comunicação falhar, a venda fica gravada na mesma. É uma escolha deliberada, porque perder uma venda por o serviço da autoridade tributária estar inacessível seria muito pior do que comunicá-la uns minutos mais tarde. Uma comunicação falhada pode ser reenviada a partir da própria venda.

Depois de comunicada, a fatura fica bloqueada para edição. A mensagem do sistema é explícita: a fatura já foi comunicada e já não pode ser editada, e para a corrigir tem de emitir uma nota de crédito ou uma nota de débito. Não é o software a criar dificuldades. Uma fatura comunicada é um documento que a autoridade tributária já tem, e a única forma legal de a alterar é com outro documento.

Depois de gravar

A venda aparece em «Todas as vendas» com o número da fatura, o cliente, o total, o estado de pagamento e, quando aplicável, o estado da fatura eletrónica. No menu da linha pode visualizá-la, imprimi-la, adicionar um pagamento, ver os pagamentos ou iniciar uma devolução. A vista de detalhe, em /sells/show/{id}, mostra as linhas, a discriminação do imposto e o histórico de pagamentos num só sítio, e é o ecrã a abrir quando alguém lhe pergunta o que se passou com uma determinada fatura.

O saldo do cliente é recalculado depois da venda, pelo que a conta a receber fica imediatamente visível na conta-corrente do cliente e na antiguidade de saldos de clientes. Se o lançamento contabilístico estiver ativo e configurado, os mesmos valores aparecem também no balancete e no balanço através do módulo de contabilidade. Se os dois não coincidirem, a causa habitual é uma das três condições de lançamento acima e não um erro aritmético.

Uma lista de verificação curta

• O local está correto? Decide o stock, a numeração, as contas de pagamento e a faturação eletrónica.
• O estado é «Final»? Qualquer outro ainda não é uma venda.
• A data da venda é a data em que a venda aconteceu de facto, e não a data em que a está a introduzir?
• Se o cliente não pagou, está assinalado «Venda a crédito — valor total em dívida», em vez de uma linha de pagamento a zero?
• Se é uma venda a crédito, o prazo de pagamento está definido para que a fatura envelheça corretamente?
• Os valores de imposto parecem corretos na faixa de totais antes de gravar, e não depois?