eBook: Os desafios da NFS-e Atualizar indice conforme online Inserir capa correta Inserir FAQ ao final
1
eBook: Os desafios da NFS-e
Prefácio De todos os documentos fiscais eletrônicos, o que tem o cenário mais complexo de se lidar, mais imprevisível e que, por consequência, tem o maior custo de manutenção, sem dúvidas, é da nota fiscal de serviços eletrônica a NFS-e. Neste eBook você saberá exatamente porque é assim e também serão apresentadas algumas dicas de como sobreviver neste cenário. O problema central da NFS-e parte da falta de padronização das interfaces de comunicação dos webservices das prefeituras. Ao contrário da NF-e, CT-e e NFC-e por exemplo, não existe um padrão nacional adotado por todas as prefeituras que podem, a seu critério, adotar o padrão que bem entender. Apesar de existir uma iniciativa da ABRASF em padronizar este setor, na prática não é bem isso que acontece, cada fabricante acabou por interpretar o padrão de forma bastante particular, muitas vezes customizando-o conforme os interesses do município. Neste sentido, um ponto que a muitos passa desapercebido, é que grande parte dos municípios instituem um modelo de RPS/NFS-e impresso, via decreto, que tem que ser seguido sobre pena de multa. Isto quer dizer que você terá um modelo diferente de impressão da nota para cada municipio. Além desta falta de padrões, outro ponto que causa diversos transtornos aos desenvolvedores de software é o fato de que as prefeituras mudam de fabricante, e padrão, sem avisar aos contribuintes em tempo hábil, quando avisam. Isto implica que, em algumas ocasiões, pode ocorrer de sua integração anoitecer funcionando e amanhecer quebrada. Simples assim. Este livro não tem a pretensão de esgotar o assunto da NFS-e, que é vasto. Mas o fato é que, se você pretende ou precisa construrir soluções de software que naveguem bem neste cenário caótico da NFS-e, é muito recomendado que você leia este eBook, pra ter uma noção de onde está pisando, quais os principais desafios e saber que existem caminhos menos complicados e seguros e outros nem tanto. Boa Leitura! Rodrigo Palhano Diretor Técnico, Tecnospeed
2
eBook: Os desafios da NFS-e
O que você encontra neste ebook? 1
Pluralidade de modelos da NFS-e .................................................... 04
2
O que é e como funciona o Padrão ABRASF ................................ 05
3
Geração da NFS-e .................................................................................... 06
4
O RPS ............................................................................................................ 07
5
Modelo de fluxo ....................................................................................... 09
6
Obrigações acessórias .......................................................................... 10
7
Nota Fiscal Conjulgada ......................................................................... 10
8
Não observância do layout de impressão .................................... 13
9
NFS-e: Uma visão de desenvolvedor para desenvolvedor .... 13
10 Um Padrão Único para resolver todos os problemas ............... 16
{
Nosso Blog: tecnospeed.com.br/blog Fan Page: facebook.com/tecnospeed Twitter: twitter.com/tecnospeed TecnoTV: youtube.com/tecnospeedti
} 3
eBook: Os desafios da NFS-e
A NFS-e é um documento de natureza eletrônica gerada pelo contribuinte em seu estabelecimento, para declarar ao fisco que houve uma prestação de um serviço e consequentemente o recolhimento do ISSQN (Imposto Sobre Serviços de Qualquer Natureza). Esse documento é armazenado eletronicamente pela prefeitura ou entidade conveniada, que é responsável por desenvolver e manter um ambiente digital que seja capaz de receber, processar e gerar a NFS-e no prazo estipulado pela legislação municipal. A Nota Fiscal de Serviços Eletrônica possui algumas particularidades, principalmente se comparado com a NF-e modelo 55. Por isso, o desenvolvedor precisa estar constantemente em alerta, sempre preparado para atender seus clientes com qualidade e entregar maior valor com seu software. Este ebook tem o objetivo de reduzir o esforço do desenvolvedor de software, sendo uma poderosa ferramenta capaz de contextualizar o profissional acerca das peculiaridades da NFS-e e prepará-lo para lidar com seu software. Desta forma, é possível estar bem preparado para os desafios que o trabalho com esse modelo de documento e não ser pego de surpresa por dificuldades que aumentem seu esforço.
Pluralidade de modelos da NFS-e O principal fator que gera dificuldades ao desenvolvedor de software é a pluralidade de modelos encontrada no ambiente nacional, exigindo que o sistema da empresa esteja adaptado para cada um deles. Isso acontece porque a legislação brasileira permite autonomia para estados e municípios criarem suas próprias leis, de acordo com os interesses que estão envolvidos naquele determinado assunto. Isso é bem explicado pelo site JusBrasil.com.br que faz referência à Constituição Brasileira:
“(...) na qual se estabelece campos materiais distintos, em atenção ao princípio da predominância do interesse, pelo qual cabe à União as matérias em que predomine o interesse nacional; aos Estados as de interesse regional e aos Municípios as de interesse local, o que será sempre averiguado de acordo com a Constituição em respeito ao denominado princípio da supremacia constitucional.”
Essa regra vale para o âmbito tributário, onde a responsabilidade de recolhimento e legislação sobre cada imposto depende do interessado em questão, seja ele estado, município ou a nação. Isso aumenta a complexidade do sistema tributário nacional, pois se torna mais difícil o correto recolhimento e gerenciamento contábil das empresas. Para nós desenvolvedores envolvidos com SPED, não é diferente. 4
eBook: Os desafios da NFS-e O impacto nos documentos fiscais eletrônicos é muito claro, no caso da NFS-e, devido a sua pluralidade: São mais de 5.500 municípios, onde boa parte deles possuem a solução e aqueles que ainda não estão adaptados, tendem a implantar a tecnologia. Embora existam padrões, não é uma regra obrigatória os municípios seguirem a risca, adotando o modelo por completo. O Padrão ABRASF é uma convenção que preza por buscar um modelo único que simplifique a vida de todos que estão envolvidos, porém não são todas as prefeituras que pensam dessa forma, existindo inúmeros modelos diferentes de comunicação, com campos, impressões e fluxos que complicam a vida do desenvolvedor que precisa lidar com esse documento. Outra dificultade devido a falta de padrões é que cada prefeitura lança suas regras e as modifica sem uma comunicação clara a toda a rede. Por isso, o desenvolvedor precisa ficar atento a portais das prefeituras e sites, que levam as informações muitas vezes de forma desencontrada e pouco esclarecedora. Quando isso acontece, o melhor a fazer é procurar o responsável pelo documento na prefeitura e entrar em contato por telefone, para maiores esclarecimentos.
O que é e como funciona o Padrão ABRASF Como já foi falado no capítulo anterior, existe uma convenção criada com objetivo de simplificar o trabalho das prefeituras e dos desenvolvedores, o Padrão ABRASF. Porém, não são todas as prefeituras que os aderem e podem ocorrer mudanças a qualquer momento. Não quer dizer que os municípios passam o tempo todo realizando mudanças, mas quando as fazem dificilmente avisam com antecedência (ou se quer avisam) para que o desenvolvedor prepare seus sistemas. Com objetivo de minimizar as dificuldades de padrões do ambiente de desenvolvimento, a ABRASF (Associação Brasileira das Secretarias de Finanças das Capitais) - representando os municípios - em alinhamento com os estados e órgãos fiscais desenvolveu um modelo conceitual que facilite as prefeituras atenderem seus requisitos tributários e simplificarem as obrigações acessórias por parte dos contribuintes. Além de reduzir o esforço dos municípios no desenvolvimento dos webservices, é uma forma de acelerar o trabalho do desenvolvedor de ERP, porque fica mais fácil para atender novas cidades e reduz a necessidade de adaptar o padrão de comunicação toda vez que é preciso a emissão para uma nova cidade.
O projeto, embora tenha abrangência nacional e por meio da representação da 5
eBook: Os desafios da NFS-e
ABRASF esteja alinhado com os interesses dos municípios, não é por legislação a obrigação do seu uso, pois deveria desde o início respeitar as particularidades de cada município. No documento “Modelo Conceitual” encontrado no site da ABRASF, é citado o seguinte:
(...) deveria ser a síntese das particularidades e exigências locais; deveria adequar-se às preferências tecnológicas dos municípios; teria aderência ao SPED, sendo que a sua implementação (desenvolvimento ou aquisição de aplicativos, obtenção da infra-estrutura necessária e adoção de padrões de segurança), estaria a cargo e sob a responsabilidade de cada Prefeitura que viesse a adotá-lo.
Isso abre uma brecha no projeto que possibilita os municípios optarem por sua adoção total, parcial ou não aderirem ao Padrão ABRASF. Embora seja convencional para as equipes responsáveis nas prefeituras que precisam ter seus próprios servidores seguir o Padrão ABRASF, há sempre muitos interesses envolvidos em serviços prestados ou desenvolvidos ao município. Isso faz com que, nem sempre, tenha adoção ao projeto e o município acaba por desenvolver sua solução própria. No site da ABRASF é possível encontrar todos os documentos descritivos e técnicos que explicam como funciona o Padrão ABRASF, que ajuda o desenvolvedor na hora de programar. Ele é constantemente melhorado pela própria associação, recebendo várias versões com correções e melhorias. Até o fechamento deste material, a versão mais atualizada é a 2.02.
Geração da NFS-e Na Lei Complementar n°116 de 31 de julho de 2003 (com uma busca rápida no Google pela lei, é possível encontrá-la na integra), onde o Governo Federal publicou obrigatoriedade da Nota Fiscal de Serviços, há em anexo uma lista descrevendo quais são as atividades que se enquadram na declaração da NFS-e. Também é possível verificar no mesmo documento, que qualquer prestação de serviços é livre de ICMS (Imposto sobre Circulação de Mercadorias e Serviços), que é de responsabilidade estadual. Na NFS-e, a identificação do prestador de serviços é obrigatoriamente feita pelo seu CNPJ, uma vez que pode ser conjugado com Inscrição Municipal (essa obrigação é excluída quando o contratado possui registro no exterior, sendo então aplicadas outras regras). Toda declaração da NFS-e deve ser necessariamente feita na competência do mês da ocorrência da prestação de serviços, uma vez que na emissão do RPS (Recibo Provisório de Serviços, que será abordado adiante) consta a data do fato gerador. Na maioria dos casos, 6
eBook: Os desafios da NFS-e
ainda é possível a declaração no mês seguinte, mas essa é uma regra que varia de acordo com a prefeitura. O valor do ISS na geração do documento é definido de acordo com a Natureza da Operação, bem como enquadramento no Simples Nacional, Regime Especial de Tributação e ISS Retido. Nesses casos é preciso se atentar às particularidades de cada regra. A alíquota que define esse valor, é definida pela legislação municipal, salvo caso de tributação em um serviço prestado fora do município, onde o contribuinte deve apresentar o valor recolhido.
O RPS Conhecido como RPS, o Recibo Provisório de Serviços é um documento de caráter físico e digital, autorizado pelo fisco, que é preenchido no ato do recebimento de um serviço, sendo fornecido ao consumidor com os dados que serão posteriormente informados à prefeitura. Ele é a representação de que o correto recolhimento do ISSQN (Imposto Sobre Serviços de Qualquer Natureza) por parte do contribuinte está acontecendo e deve possuir duas vias: uma impressa fornecida ao consumidor e outra digital, que é enviada ao webservice da prefeitura e que posteriormente é convertida em uma NFS-e. Uma dúvida recorrente é se o RPS é só uma representação da NFSe. Porém, são dois documentos distintos que fazem parte do fluxo, sendo possível a impressão tanto de um quanto de outro de maneira distinta. A empresa envia os RPS por lotes, como é demonstrado posteriormente, que chegam aos servidores da prefeitura e entra em processamento de lote. Posteriormente, após a validação, são geradas as NFS-e que ficam disponíveis para consulta.Se houver a necessidade de realizar o cancelamento de uma NFS-e, isso só é possível se ela já tiver sido gerada no servidor da prefeitura por meio do RPS enviado. Enquanto não for processada, também não é possível realizar a sua consulta, mesmo pelo recibo que foi emitido. A validade do RPS é o prazo que o contribuinte tem para enviá-lo para a prefeitura, a contar a partir da data de emissão do documento. Durante esse período, o Recibo Provisório deve ser convertido no servidor para uma NFS-e. Esse período também varia de acordo com cada município. O modelo de RPS varia para cada município de acordo com as suas exigências legais, podendo ou não adotar os padrões ABRASF. O desenvolvedor deve estar atento a esse detalhe quando for trabalhar com NFS-e, pois o não cumprimento dos decretos municipais que regulamentam o modelo do RPS incorrem em multas e dor de cabeça para o emitente. Por isso, toda vez que for necessário implantar um novo município no sistema, é preciso 7
eBook: Os desafios da NFS-e uma consulta para verificar quais são as particularidades daquela prefeitura em seu modelo de impressão. Para melhor compreensão, abaixo está um modelo físico de RPS conforme a prefeitura de Botucatu:
Veja que no próprio RPS, a prefeitura descreve os prazos para conversão em NFS-e e o limite máximo de envio do documento que deve ser seguido pelo contribuinte.
8
eBook: Os desafios da NFS-e
Modelo de fluxo A imagem do modelo de fluxo abaixo foi retirada do Modelo Conceitual do Padrão ABRASF, para explicar como funciona a transmissão do RPS e emissão de uma NFS-e (novamente, é importante ressaltar que é necessário estar atento às particularidades de cada prefeitura):
O fluxo segue o seguinte processo: 1. O contribuinte preenche os dados da prestação do serviço no RPS dentro da sua aplicação ou manualmente no sistema online da prefeitura 2. O sistema faz o agrupamento em lotes e envia o conjunto de RPS para o webservice da prefeitura. Nesse momento, o documento ainda não foi convertido em uma NFSe. 3. Ao receber o RPS, o webservice coloca o documento em uma fila para que haja o processamento das informações e a conversão em uma NFSe. Podem ocorrer nessa etapa do processo, a comunicação de duas formas: a. Comunicação Assíncrona: O servidor realiza a conversão do documento, mas não retorna uma mensagem de autorização, sendo necessário realizar uma consulta posterior b. Comunicação Síncrona: O servidor recebe, realiza o processamento e retorna uma mensagem caracterizando a situação do documento. 4 .O próprio webservice envia, após processar e transformar o RPS em uma NFSe, o documento digital para armazenamento das informações. Posteriormente, os dados serão utilizados para confrontar o recolhimento do ISSQN com as obrigações acessórias à NFSe.
Uma vez que a NSe é gerada, não é possível que seja alterada pelo contribuinte, possibilitando somente o seu cancelamento ou substituição.
9
eBook: Os desafios da NFS-e
Obrigações Acessórias Na NFS-e não há, se comparado com o ECF por exemplo, obrigações acessórias diárias como a Leitura X ou Redução Z. Porém, algumas regras normalmente são seguidas pelas prefeituras para que haja a declaração e recolhimento dos impostos sobre serviços. O que normalmente acontece é a necessidade de uma declaração mensal dos impostos recolhidos consolidando todo o recolhimento do mês anterior, chamada pelas prefeituras de DMS (Declaração Mensal de Serviços). É sempre feita após o encerramento da competência vigente, que é um resumo dos mesmos RPS que foram declarados no mês. Essa obrigação gera o valor total que deve ser recolhido pelo contribuinte.
Nota Fiscal Conjugada A Nota Conjugada é uma NF-e ou NFC-e que substitui a emissão da NFS-e, quando há para uma mesma operação de venda produtos e uma prestação de serviços. Ela foi uma regra criada para que seja possível a emissão de um só documento, porém depende de cada município decidir por criar um convênio ou não com o Fisco estadual para delegar a responsabilidade de arrecadação dos impostos devidos. Quando esse documento existe, fica de responsabilidade da SEFAZ em arrecadar e depois repassar o valor do imposto para o município. É um assunto que gera inúmeras dúvidas decorrentes das particularidades encontradas em cada município ou estado, já que a permissão e as regras dependem da Sefaz Estadual conversar com a prefeitura. Atualmente é possível encontrar no país tanto municípios que emitem NF-e conjugada, como também a exemplo de Manaus, a emissão NFC-e conjugada, que emite para o consumidor um documento único com as devidas informações sobre impostos de produtos e serviços. Nesse caso pioneiro a NFC-e, a legislação que regulariza a sua emissão é o Decreto Municipal nº 2.720, publicado no Diário Oficial do município de Manaus, em 18 de fevereiro de 2014. Não há uma informação centralizada sobre quais são aqueles municípios que possibilitam essa operação, no caso são poucos. Para fazer esse levantamento, seria necessário acessar todas as regras de cada uma das cidades que utilizam a NFS-e e verificar a disponibilidade. 10
eBook: Os desafios da NFS-e Portanto, quando houver a dúvida em relação a uma cidade específica, é possível consultar o Portal da Sefaz do seu estado ou a legislação vigente do município e verificar se há convênio para a emissão da mesma. Caso isso não esteja disponível, é necessário a emissão dos documentos fiscais separadamente para cada operação. Alerta: A não adequação aos padrões pode resultar em prejuízo O desenvolvedor sempre está preocupado com a satisfação de seus clientes, que são tiram os maiores benefícios de uma solução bem desenvolvida e adaptada aos modelos de NFS-e existentes no país. Por isso, é preciso estar atento às possíveis mudanças e potenciais falhas para que não seja prejudicado em algumas situações. Emitir a NFS-e em várias cidades diferentes, como já foi citado diversas vezes, significa adaptar a impressão e comunicação para cada realidade de forma única. Caso as rotinas e o layout não sejam respeitados, as consequências são ruins para o emitente, que pode ser multado por descumprir com normas legais da prefeitura. Para entender melhor o impacto disso, fizemos um breve levantamento de algumas prefeituras e como descrevem o descumprimento da lei. Analisando os decretos de quatro prefeituras aleatórias diferentes, foi possível identificar algumas situações que o contribuinte pode ser prejudicado. Os municípios analisados foram: Olinda (PE), Catalão (GO), Campinas (SP) e Maringá (PR). Cada um possuí suas particularidades, assim como em qualquer outro do país. Então utilizamos algumas situações individuais para exemplificar onde podem ocorrer alguns problemas: O não envio do RPS ou não geração da NFSe: Se houver problemas no envio do RPS e posteriormente a conversão para NFS-e não gerando o documento eletrônico, para a prefeitura é como se a Nota não tivesse sido enviado. Ou seja, ocorreu uma venda sem declaração de impostos. Nesse caso pode ocorrer duas situações: • Não declaração do imposto por ausência da NFSe
•
Declaração incorreta que é validada pelo sistema (os webservices não validam regras tributárias)
Caso aconteça alguma dessas duas situações, o contribuinte é considerado infrator, levando a multas ou processos judiciais. A Prefeitura de Catalão expõe o caso da seguinte forma: Parágrafo único. A falta de recolhimento do ISSQN incidente na operação identificada 11
eBook: Os desafios da NFS-e por meio de NFS-e, sujeita o infrator à multa estabelecida na legislação municipal, lançada por n otificação de Lançamento, Auto de Infração ou Auto Intimação, observados os procedimentos regulamentares. Ainda discrimina as penalidades em valores a serem pagos: I – de R$ 50,00 (cinquenta reais) a R$ 1.000,00 (um mil reais) pela falta de geração de cada Nota Fiscal de Serviços Eletrônica – NFS-e; II – de R$ 20,00 (vinte reais) por Recibo Provisório de Serviços – RPS convertido fora do prazo estabelecido pela legislação tributária; III – de R$ 50,00 (cinquenta reais) a R$ 1.000,00 (um mil reais) para cada RPS não emitido; IV – de R$ 50,00 (cinquenta reais) para cada RPS emitido e não convertido em NFS-e, nos prazos regulamentares; V – de R$ 50,00 (cinquenta reais) a 100,00 (cem reais) para cada RPS não convertido em NFS-e e não informado pelo tomador dos serviços nos prazos regulamentares;
Posteriormente, cumprindo as obrigações acessórias, na Declaração Mensal de Serviços, as prefeituras também regulamentamam que o valor das NFS-e enviados durante o mês deve ser o mesmo daquelas declaradas no resumo mensal. Caso isso não aconteça, a prefeitura pode multar ou investigar o contribuinte. Nesse caso, usamos um exemplo da Prefeitura Municipal de Olinda: Art. 15. As infrações relativas à Declaração Mensal de Serviços Eletrônica – DMS-e ficam sujeitas as seguintes penalidades: I – de R$ 50,00 (cinquenta reais) a 500,00 (quinhentos) pelo atraso por mais de trinta dias na apresentação da Declaração Mensal de Serviços Eletrônica – DMS-e; II – de R$ 250,00 (duzentos e cinquenta reais) a R$ 500,00 (quinhentos reais) para cada Declaração Mensal de Serviços Eletrônica – DMS-e entregue com informações declaradas de forma inexatas, incompletas, inverídicas ou com enquadramento indevido da tributação como isentos, imunes ou não tributáveis; III – de R$ 250,00 (duzentos e cinquenta reais) a R$ 1.000,00 (um mil reais) para cada Declaração Mensal de Serviços Eletrônica – DMS-e entregue com omissão de registros de documentos cujo lançamento implique formalização de operações tributáveis referentes à serviços prestados, intermediados ou tomados, situação em que a multa será aplicada por documento. IV – de R$ 250,00 (duzentos e cinquenta reais) por descumprimento de obrigações acessórias relacionadas à Declaração Mensal de Serviços Eletrônica – DMS-e que não possua penalidade específica.
12
eBook: Os desafios da NFS-e
Não observância do layout de impressão A falta de padrão na impressão da NFS-e também pode causar problemas ao emitente caso não siga os padrões da prefeitura, pois cada uma também possui o seu modelo diferente. Uma regra que merece atenção do emitente é a Lei da Transparência, que exige dos contribuintes a disponibilização para o consumidor final do valor do total da compra que é destinado ao pagamento de impostos. Atualmente, a lei ainda está em vigência com punições educacionais, mas a previsão é que sua obrigatoriedade passe a vigorar a partir de 2015. Quando isso acontecer, o contribuinte passa a ser multado se ausentar tal informação nos documentos fiscais. O desenvolvedor precisa se atentar aos detalhes, para que não prejudique seu cliente. Nesses casos, quem acaba sendo punido é o contribuinte, que utiliza seu software de emissão de NFS-e confiando de que ele está dentro das regras. Quem utiliza Componentes Tecnospeed ou Manager e-doc tem a garantia de que o emitente terá sempre seu documento fiscal emitido dentro da legalidade. Por meio do nosso radar fiscal, estamos sempre monitorando e realizando as mudanças necessárias em nossos produtos para atender as demandas legais.
NFS-e: Uma visão de desenvolvedor para desenvolvedor No ponto de vista do desenvolvedor, uma frase que resume bem a vida de quem trabalha com esse documento é: a NFS-e é uma pedra no sapato. Todo ano de eleições é um período de instabilidade para o mercado brasileiro, principalmente quando se aproxima das datas de votação. Muitas decisões são adiadas para depois dos resultados, acontecem poucas mudanças estruturais e é tempo dos governos entregarem os projetos que ainda não estão completos. A expectativa fica então em cima das possíveis novas lideranças e quais são as possíveis mudanças que podem vir a acontecer, para que sejam feitos então os planos futuros. O sonho de todo gerente de projeto na área de desenvolvimento de software, é trabalhar com um cenário onde as mudanças sejam no mínimo, previstas com alguns meses de atecedência. Para falar a verdade, já nos conformamos com mudanças, pois é algo inerente a qualquer projeto de software, então a preocupação passa a ser o impacto 13
eBook: Os desafios da NFS-e que esta causará. Quem normalmente está dia após dia pensando em como inovar em seus produtos e entregar o maior valor para seus clientes, pouco tem atenção a entender o cenário político (porque tempo é algo escasso nos dias de hoje) e por isso dedica seu trabalho em observar as tendências de tecnologia e desenvolvimento, implementar melhorias e desenvolver features que precisam ser levadas em conta no seu planejamento. Correto? Não para quem trabalha com documentos fiscais eletrônicos. A política brasileira tem um impacto enorme nos planos de quem desenvolve software, e é muito importante que isso seja levado em consideração sempre na empresa. Para a Tecnospeed, potenciais mudanças políticas trazem uma enorme incerteza no ambiente fiscal no país, que possui impacto direto na tecnologia utilizada pelos ambientes públicos para lidar com as soluções fiscais. Afinal, hoje temos um cenário em que boa parte de tudo que é feito em relação ao contexto contábil fiscal é baseado em tecnologia e quem dita as regras acaba sendo o Estado. Na prática, funciona mais ou menos assim: No roadmap de atividades, são definidos os planos para que uma nova versão do software seja lançado, com novas features que vão permitir a empresa ganhar mais mercado. Mesmo que não haja uma cerimônia padronizada para traçar os planos, as equipes tem um caminho para percorrer. Assim, a equipe de desenvolvedores é mobilizada para que as tarefas necessárias sejam executadas. Vamos supor que os planos são para que fevereiro de 2015 a nova versão esteja 100% online. Porém, durante o projeto, uma nova regra de uma cidade de um cliente que emite NFS-e altera todo o modelo de comunicação com os servidores da prefeitura, não sendo mais um padrão ABRASF, inclusive. Como é um cliente importante, uma pessoa da equipe se concentra durante o mês para entregar uma nova homologação para o novo modelo. A equipe de desenvolvimento, que antes era composta por 4 pessoas, agora só tem 3 e consequentemente precisa adiar o prazo de lançamento. Mais uma vez o fisco, na figura da prefeitura nesse caso, faz a empresa interromper seus planos para se adequar às suas necessidades. Isso é mais comum do que se imagina no ambiente brasileiro, pois as lideranças políticas tem autonomia para realizar mudanças de acordo com suas estratégias. Acontece com a NFS-e em âmbito municipal, com a NF-e em âmbito nacional e com NFC-e em âmbito estadual. Um exemplo recente foi a constante mudança de prazos no Paraná com 14
eBook: Os desafios da NFS-e obrigatoriedade de PAF-ECF, que surpreendeu muitas software houses que preparam seus clientes para atender essa demanda. Quanto desse tempo das equipes poderia ter sido alocado em inovações no software, que aumentaria a satisfação dos clientes? Por isso, as empresas que desenvolvem software precisam estar atentas ao cenário político e antenadas com as mudanças e tendências, para que estejam preparadas para possíveis mudanças sem sofrer com a execução de seus projetos. Em conversa com alguns gestores, é possível perceber que o método mais utilizado por eles é o de sempre reservar um tempo, com base histórica, para que mudanças em legislação sejam implementadas no software. Apesar de ser o método mais utilizado, é perceptível que existem alguns problemas:
1) O tempo reservado para as adequações destas mudanças comprometem o desenvolvimento de novos projetos inovadores, com foco no negócio da empresa. Ou seja, em geral, os gestores de projeto sofrem pressão por parte da direção por não serem tão ágeis na implementação de novas funcionalidades, o que pode inclusive comprometer a exploração de novos mercados e consequentemente comprometer o crescimento da empresa. 2) Como os projetos de documentos eletrônicos tem responsabilidades em esferas diferentes, não existe uma sincronia para publicação e liberação de mudanças. Isso pode comprometer o tempo reservado, todo de uma vez, gerando um desgaste entre setores da empresa, pois afinal de contas o setor de marketing e vendas está aguardando tal recurso para lançá-lo 3) Também existem os casos onde a identificação das mudanças, ocorre em cima da hora. Isso exige um replanejamento do projeto e uma sobrecarga de implementação em tempo recorde. Para muitas empresas, essa implementação de forma tão rápida pode comprometer a qualidade do produto, gerando insatisfação no cliente final.
Se os padrões diferem para cada município, significa que cada prefeitura lança suas regras e as modifica sem uma comunicação clara a toda a rede. Por isso, o desenvolvedor precisa ficar atento a portais das prefeituras e sites, que levam as informações muitas vezes de forma desencontrada e pouco esclarecedora. A própria SEFAZ nacional no início do projejto NF-e teve inúmeras dificuldades de infraestrutura - e que até hoje vem sofrendo mudanças. No caso da NFS-e, em sua maioria, os servidores são da própria prefeitura, que gera instabilidade nos webservices e dificulta mais ainda a vida do desenvolvedor. Ao enfrentar todas essas dificuldades, fica mais caro desenvolver o mesmo software sem qualquer inovação perceptível ao cliente . Ou seja, o desenvolvimento 15
eBook: Os desafios da NFS-e passa longos períodos somente realizando modificações e readequações decorrentes de obrigatoriedades.Em um cenário onde as software houses possuem clientes espalhados por todo o Brasil, quanto maior é a abrangência geográfica da empresa, maior é a demanda por atender as demandas fiscais.
Um Padrão Único para resolver todos os problemas Para reduzir o esforço do desenvolvedor, a Tecnospeed criou o Padrão Único da NFS-e. Uma ferramenta do produto que possibilita o desenvolvedor ter somente um modelo de comunicação do ERP, baseado em TX2, para todas as cidades que há emissão. A partir das informações geradas pelo sistema, o componente NFSe faz o papel de adequar os dados do XML de acordo com os campos daquele determinado padrão e realizar o envio . Assim, o desenvolvedor não precisa gastar tempo modificando o seu produto toda vez que precisa mandar o documento para uma nova cidade. Além de novos municípios, o componente sofre atualizações constantes de acordo com as mudanças legais. Esta solução oferece à empresa desenvolvedora mais rapidez na integração de seu software com a prefeitura e consequentemente mais satisfação do contribuinte, que ao necessitar emitir Nota Fiscal de Serviços para um novo município, rapidamente pode ter seu sistema adaptado. Outro benefício é a redução de custos com manutenção, já que a TecnoSpeed monitora e implementa as constantes mudanças realizadas pelos municípios, proporcionando maior agilidade em readequações. Com o Componente NFSe da Tecnospeed, o desenvolvedor pode focar no que realmente importa para o seu software, sem se preocupar com o cenário instável de mudanças que atrasam constantemente a criação de novas soluções e implantação de melhorias no software.
16
eBook: Os desafios da NFS-e
17