Um programa de faturamento para ag\u00eancias de viagens n\u00e3o pode funcionar com a mesma l\u00f3gica que usa um com\u00e9rcio tradicional. A\u00ed est\u00e1 o primeiro mal-entendido que costuma levar uma ag\u00eancia a escolher mal: pensa que precisa de um sistema que emita comprovantes, quando na realidade precisa de um que entenda como se gera o dinheiro nesta ind\u00fastria. <\/p>\n\n
Em um com\u00e9rcio comum, a venda e a fatura ocorrem quase ao mesmo tempo. Em uma ag\u00eancia de viagens, entre esses dois momentos podem passar semanas ou meses. Um cliente confirma um pacote em janeiro para viajar em julho. Paga um sinal, depois uma segunda parcela, e s\u00f3 no final se emite a fatura completa. Enquanto isso, a ag\u00eancia tamb\u00e9m paga a um ou mais fornecedores, em datas que n\u00e3o coincidem com os recebimentos do cliente. Um programa pensado para varejo n\u00e3o contempla essa defasagem porque n\u00e3o foi projetado para conviver com ela. <\/p>\n\n
Este artigo revisa quais caracter\u00edsticas fazem com que um programa de faturamento funcione de verdade em uma ag\u00eancia de viagens, seguindo a l\u00f3gica de como se gera realmente uma fatura neste setor.<\/p>\n\n
A raiz do problema n\u00e3o \u00e9 cont\u00e1bil. \u00c9 operacional. Um software gen\u00e9rico fatura a partir de uma venda pontual: produto, pre\u00e7o, cliente, pronto. Um programa de faturamento pensado para turismo tem que partir de outra unidade: a reserva. Tudo o que ocorre depois (recebimentos parciais, pagamentos a fornecedores, comiss\u00f5es, ajustes) se desprende dessa reserva e deve poder ser rastreado at\u00e9 ela. <\/p>\n\n
O que acontece quando essa conex\u00e3o n\u00e3o existe? A equipe administrativa termina reconstruindo manualmente uma hist\u00f3ria que o sistema deveria ter registrado sozinho. E essa reconstru\u00e7\u00e3o manual \u00e9, na maioria dos casos, a origem real dos erros de faturamento que se atribuem “ao sistema”. <\/p>\n\n
Um software cont\u00e1bil que sim entende esta l\u00f3gica do turismo<\/a> parte dessa premissa distinta desde o design, n\u00e3o como um ajuste posterior.<\/p>\n\n Um pacote para o Peru pode incluir voos com uma companhia a\u00e9rea, hospedagem com um fornecedor local, traslados com outro e uma excurs\u00e3o com um quarto. Cada um fatura diferente, cobra em momentos distintos e em alguns casos aplica uma comiss\u00e3o diferente sobre o mesmo servi\u00e7o. <\/p>\n\n Se o programa de faturamento n\u00e3o pode desagregar esta informa\u00e7\u00e3o por fornecedor dentro de uma mesma reserva, algu\u00e9m da equipe termina levando esses n\u00fameros em uma planilha paralela. E uma planilha paralela \u00e9, quase sempre, o primeiro sintoma de que o sistema principal ficou aqu\u00e9m. <\/p>\n\n Isto se torna mais evidente em ag\u00eancias receptivas e em operadores atacadistas, onde uma s\u00f3 venda pode envolver meia d\u00fazia de fornecedores distintos, cada um com seu pr\u00f3prio esquema de pagamento. A caracter\u00edstica-chave aqui n\u00e3o \u00e9 quantos fornecedores o sistema suporta em abstrato. \u00c9 se pode mostrar, reserva por reserva, quem cobrou o qu\u00ea, quanto se deve a cada fornecedor e quanto disso j\u00e1 foi faturado ao cliente final. Sem essa rastreabilidade por fornecedor, a margem real de cada venda fica escondida at\u00e9 que algu\u00e9m a calcule manualmente no fechamento do m\u00eas. <\/p>\n\nO que exige de um programa de faturamento uma reserva com v\u00e1rios fornecedores<\/strong><\/h2>\n\n