Para facilitar a compreensão das informações operacionais deste manual, conheça os principais termos e conceitos relacionados às funcionalidades apresentadas.
Nota Fiscal de Serviços Eletrônica (NFS-e)
A Nota Fiscal de Serviços Eletrônica (NFS-e) é um documento fiscal digital criado para viabilizar a comunicação entre o prestador de serviços e a prefeitura do município. A NFS-e foi desenvolvida pela Receita Federal em conjunto com a Associação Brasileira das Secretarias de Finanças das Capitais (Abrasf), com o objetivo de integrar e trocar informações entre contribuintes e municípios, reduzir custos, ampliar o controle da arrecadação do ISS e facilitar a fiscalização.
Por ser um documento exclusivamente digital e de responsabilidade municipal, a prefeitura deve disponibilizar o ambiente responsável pela auditoria e autorização do documento eletrônico. A autenticação da NFS-e ocorre por meio do envio do XML do Recibo Provisório de Serviços (RPS) ao web service da prefeitura. Quando os dados estão corretos, o RPS é processado e a comunicação é concluída.
Estão diretamente envolvidos neste processo o prestador de serviços, que precisa emitir a nota para o cliente; a prefeitura, responsável pela disponibilização dos web services; e os desenvolvedores de software, responsáveis pela integração. Atualmente, os principais desafios relacionados à NFS-e são:
-
O modelo conceitual não é obrigatório.
-
Cada município pode implementar o processo conforme seus próprios critérios, com ou sem base no modelo da Abrasf.
-
Não há padronização quanto à quantidade de serviços, nomes dos serviços, quantidade e nome dos parâmetros, formato do documento, assinatura, respostas dos serviços, serviços complementares e ambientes de homologação e produção.
-
Cada município possui regulamentação própria para os formatos de impressão.
-
Podem ocorrer dificuldades com os servidores municipais.
-
É necessário realizar credenciamento.
-
Nem sempre há documentação atualizada.
-
Em períodos de mudança de gestão municipal, os fornecedores podem ser alterados, o que pode modificar os padrões adotados pelo município.
Recibo Provisório de Serviços (RPS)
O Recibo Provisório de Serviços (RPS) é o documento utilizado pelos emitentes de Nota Fiscal de Serviços Eletrônica quando há impedimento para a emissão online da nota. Também pode ser usado por prestadores sujeitos à emissão de grande quantidade de NFS-e, como estacionamentos. Nesses casos, o prestador emite um RPS para cada transação e providencia sua conversão em Nota Fiscal de Serviços Eletrônica por meio do envio de arquivos em lote.
O prestador de serviços deve converter o RPS em Nota Fiscal de Serviços Eletrônica até o décimo dia subsequente ao de sua emissão, sem ultrapassar o dia 5 do mês seguinte ao da prestação dos serviços. Conversões realizadas após esse prazo sujeitam o prestador às penalidades previstas na legislação municipal.
Web Service
Por meio do Web Service, as empresas podem integrar seus próprios sistemas ao sistema de Nota Fiscal de Serviços Eletrônica (NFS-e) da prefeitura. Dessa forma, é possível automatizar os processos de emissão, consulta, substituição e cancelamento de NFS-e. O Web Service pode seguir o modelo nacional de NFS-e, nas versões 1.0 ou 2.02, ou adotar formato próprio, como .txt ou .xml.
Essa tecnologia permite a integração entre sistemas e a comunicação entre diferentes aplicações, possibilitando que novas soluções interajam com sistemas já existentes e que plataformas distintas sejam compatíveis entre si.
Para que o ISS-Easy funcione corretamente, os Web Services da prefeitura do município do prestador e da Alterdata devem estar disponíveis. Caso um desses servidores esteja fora do ar, o ISS-Easy não funcionará. Para identificar problemas de conexão, o ISS-Easy disponibiliza duas rotinas: uma para testar a conexão com o Web Service da Alterdata e outra para testar a conexão com o Web Service da prefeitura.
A empresa prestadora de serviços deve estar cadastrada no Web Service da Alterdata para que o sistema funcione. Para realizar esse cadastro, entre em contato com o suporte técnico da Alterdata.
Interfaces Disponíveis
A seguir, estão resumidas as principais interfaces disponíveis no Web Service da NFS-e e suas funcionalidades.
1. Envio Assíncrono
1.1 Envio de Lote
Nesta interface, os prestadores de serviços podem enviar, por meio de seus sistemas, lotes de RPS para substituição por NFS-e. Trata-se de um serviço assíncrono: o prestador envia um lote de RPS e recebe o número do lote como protocolo de registro, mas o processamento não ocorre no mesmo momento do envio. A prefeitura processa o lote posteriormente. Se houver erros, as NFS-e não serão geradas; se não houver críticas, cada RPS dará origem a uma NFS-e. O sistema do prestador deve consultar o processamento por meio da interface de Consulta de Lote.
1.2 Consulta de Lote
Permite consultar as NFS-e emitidas pelo prestador a partir do número de lote informado. Nesse método, o Web Service retorna diversas informações, como o número do lote processado, as NFS-e geradas e possíveis erros de processamento. Trata-se de um serviço síncrono: assim que o sistema do prestador envia a solicitação, o Web Service retorna, na mesma conexão, as informações disponíveis. Se o lote já tiver sido processado, são retornados os dados do processamento; caso contrário, o serviço informa que o lote ainda não foi processado, e o sistema do prestador deve aguardar antes de consultar novamente.
2. Envio Síncrono
Essa interface possui estrutura semelhante à do envio de lote assíncrono. Os prestadores de serviços podem enviar lotes de RPS para substituição por NFS-e. A diferença é que o lote é processado na mesma conexão, retornando o número de lote como protocolo de registro e as informações do processamento. Se o lote apresentar erros, as NFS-e não serão geradas; se não houver críticas, cada RPS dará origem a uma NFS-e. O sistema do prestador também pode consultar as informações desse lote pela interface de Consulta de Lote.
3. Consulta de Notas
Permite consultar as NFS-e emitidas pelo prestador. Trata-se de um serviço síncrono, no qual o sistema do prestador envia ao Web Service uma solicitação de consulta, informando o período desejado, e recebe, na mesma conexão, as notas encontradas.
4. Cancelamento de Notas
Permite cancelar NFS-e. O cancelamento de notas é um serviço síncrono: o sistema do prestador envia uma solicitação contendo uma ou mais notas, e o Web Service processa o cancelamento e retorna as informações correspondentes na mesma conexão.
5. Consulta de NFS-e ou RPS
Permite recuperar as informações de uma NFS-e ou de um RPS convertido. Trata-se de um serviço síncrono: o sistema do prestador envia uma solicitação de consulta com uma ou mais NFS-e ou RPS, e o Web Service retorna, na mesma conexão, os dados correspondentes.
Estrutura dos Diretórios
Ao informar o diretório que será utilizado para processamento e armazenamento dos arquivos XML e PDF, o diretório padrão será "C:\Arquivos de programas\Alterdata\ISS-easy\DadosISSEasy". Nele, será criada uma estrutura de diretórios semelhante à imagem abaixo. De modo geral, ficarão armazenados os seguintes itens:
-
DLLs de integração do município.
-
Executável do aplicativo (ISSEasy.exe).
-
Arquivo INI de configurações e cadastros do aplicativo.
-
Subpastas para armazenamento de arquivos XML, PDF, backup e outros arquivos referentes às notas fiscais emitidas, em qualquer status.
Unknown Attachment
|
Diretórios |
Descrição |
|---|---|
|
Backup |
Diretório onde são criados os backups dos arquivos XML enviados ao Web Service da prefeitura, caso o sistema esteja configurado para isso. |
|
Config |
Diretório utilizado pelo usuário para criar os layouts dos relatórios usados pelo sistema. |
|
Envio\Cancelamento\Pendente |
Diretório onde são lidos os arquivos XML contendo o cancelamento das notas fiscais eletrônicas já emitidas. O XML deve seguir o padrão ABRASF. |
|
Envio\RecepcaoNFSe\Assinada |
Diretório intermediário onde são gravadas as notas assinadas antes do envio aos web services das prefeituras. É utilizado internamente pelo ISS-Easy. |
|
Envio\RecepcaoNFSe\Pendente |
Diretório onde são lidos os arquivos XML contendo os lotes de RPS para envio às prefeituras. Nesse diretório, as aplicações que emitem notas fiscais de serviço devem gerar o XML dos lotes de RPS, conforme o padrão ABRASF. |
|
Envio\RecepcaoNFSe\Recibos |
Diretório utilizado internamente pelo ISS-Easy para armazenar os XML retornados pela prefeitura com o protocolo de processamento dos RPS enviados. |
|
Envio\RecepcaoNFSe\Remessa |
Diretório utilizado para armazenar as notas a serem enviadas à prefeitura quando a integração é realizada via TXT. |
|
Layout NFS-e |
Modelo utilizado para a emissão de NFS-e. |
|
LayoutRPS |
Modelo utilizado para a emissão de RPS. |
|
Log |
Diretório utilizado para gravar os arquivos de log das operações realizadas pelo ISS-Easy. |
|
LogProcessamentoNFSE |
Armazena as operações realizadas no envio e no retorno dos dados com a prefeitura. |
|
Recebimento\Cancelamento\Autorizado |
Diretório onde são gerados os XML retornados pelos Web Services das prefeituras com a confirmação do cancelamento das notas fiscais. |
|
Recebimento\Cancelamento\Rejeitado |
Diretório onde são gerados os XML retornados pelos Web Services das prefeituras com a rejeição da solicitação de cancelamento das notas fiscais. |
|
Recebimento\RecepcaoNFSe\Autorizada |
Diretório onde são gerados os XML contendo as notas fiscais já emitidas pela prefeitura. Nesse diretório também é gerado o arquivo PDF com o espelho da nota fiscal, conforme o layout preestabelecido. |
|
Recebimento\RecepcaoNFSe\Rejeitada |
Diretório onde são gerados os XML retornados pelos Web Services das prefeituras com a rejeição de um RPS enviado. O XML informa o motivo da rejeição. |
|
Recebimento\RecepcaoNFSe\Retorno |
Diretório utilizado para armazenar as notas processadas pela prefeitura quando a integração é realizada via TXT. Os arquivos armazenados são processados pelo ISS-Easy, gerando o PDF da nota processada ou o XML com as rejeições. |
Código de Identificação Pessoal do Certificado Digital (PIN / PUK)
Caso o certificado digital cadastrado para a empresa seja do tipo A3, ao testar a conexão com a prefeitura será exibida uma tela solicitando o PIN do certificado. A senha PIN (Personal Identification Number — Número de Identificação Pessoal) é composta por números e/ou letras, possui de 4 a 8 caracteres e é utilizada para acessar o Certificado Digital, como em acessos ao site da Receita Federal e assinaturas de documentos. Essa senha pode ser alterada a qualquer momento por meio do software de gestão do token.
Após três tentativas incorretas de digitação do PIN, o certificado será bloqueado. O desbloqueio só poderá ser realizado com o PUK. O PUK (Pin Unlock Key — Chave de Desbloqueio do PIN) é uma senha composta por números e/ou letras, com 4 a 8 caracteres, utilizada exclusivamente para desbloquear o PIN. Ela também pode ser alterada a qualquer momento pelo software de gestão do token.
Após três tentativas incorretas de digitação do PIN e três tentativas incorretas de digitação do PUK, o Certificado Digital e o cartão inteligente serão inutilizados.