Permitir resolver notas em conflito via Web Service

Última atualização em: 19 de julho, 2019

Durante o processo de emissão de NFS-e pode ocorrer que um determinado documento fique com status ‘em conflito’. Esse retorno geralmente ocorre quando há falha na comunicação com a prefeitura e esta não possui o serviço de consulta ou exige o número de protocolo para realizar a consulta, porém como ocorreu problema na comunicação, o número do protocolo não está disponível.

Para realizar a correção de documentos com status ‘em conflito’, ao receber esse retorno do web service, o ERP poderá solicitar que o prestador verifique junto ao sistema da prefeitura se o documento está registrado lá, caso esteja, ele deverá pegar os dados referente ao número da NFS-e, código de verificação e protocolo. Estas informações deverão ser enviadas ao InvoiCy por meio do web service de recepção de documentos.

O envio das informações para o InvoiCy deverá seguir o modelo no link a seguir: Clique aqui .

Caso a nota constar no sistema da prefeitura, o ERP deverá enviar ao InvoiCy o número da NFS-e, o código de verificação e o protocolo. Nesse caso, a tag NotaExiste deverá ser enviada como “S”,  a partir disso o InvoiCy irá atualizar os dados do documento e será disparada uma consulta ou uma tentativa de reenvio, se a comunicação com o web service da prefeitura ocorrer normalmente, o status da NFS-e será atualizado no InvoiCy.

Se a nota não existir no sistema da prefeitura, o ERP deverá enviar ao InvoiCy o mesmo evento de correção apresentado anteriormente, porém enviando o campo NotaExiste como “N”,  nesse caso não devem ser enviadas as tags Protocolo, NFSeCodVerificacao e NFSeNumero.

Em alguns padrões existe um controle na numeração de lotes, que devem ser sequenciais. Como o número do lote é gerado e controlado automaticamente pelo InvoiCy, na maioria dos casos a empresa não precisa se preocupar com esse número.  Quando a prefeitura rejeitar o lote devido a problemas na sequência do lote (ou dizer que esse número de lote já foi utilizado em emissões anteriores), buscamos identificar que esse erro ocorreu e o sistema se resolver automaticamente. Entretanto, até conseguirmos tratar todos os possíveis retornos, a emissão em alguns padrões pode necessitar de interação manual para recalibrar a sequência do lote.

Quando o caso relatado acima ocorrer, o usuário poderá verificar no site do município qual o número do lote da última nota autorizada e informar ao invoiCy qual o número de lote o RPS em questão precisa utilizar para emitir.

Após enviar essas informações, o InvoiCy irá retornar ao ERP o status do documento, utilizando o mesmo layout de retorno de consulta de documentos.

Importação de NFS-e emitida na Prefeitura

Última atualização em: 07 de maio, 2019

O InvoiCy passa a disponibilizar uma nova funcionalidade que irá consultar e importar as notas emitidas pelo próprio Prestador na prefeitura de forma automática, permitindo assim que as empresas que emitem NFS-e armazenem suas notas de forma centralizada e organizada.

É importante destacar que essa funcionalidade estará disponível apenas para notas emitidas em produção. E no momento irá funcionar apenas com os padrões BETHA, GINFES, NF PAULISTANA e NOTA CARIOCA.

Para fazer uso dessa nova funcionalidade é muito simples. Primeiramente, é necessário ativar a extensão de Documentos importados para a empresa, e configurar o parâmetro ‘Tipo de arquivos para importar no módulo NFS-e’, como demonstra a imagem abaixo. Para mais informações sobre essa extensão leia o artigo Extensão Documentos importados.

Após ativar a extensão, um processo irá automaticamente consultar na prefeitura as notas emitidas pela empresa e importar para o InvoiCy. A consulta sempre será realizada nas primeiras horas do dia seguinte, buscando as notas do dia anterior.

Caso desejar, após a importação você poderá realizar a consulta e download dessas notas. Para mais informações sobre esse processo leia o artigo Exportação de NFS-e recebidas e emitidas.

Padrão SysISS

Última atualização em: 09 de abril, 2021

O Padrão SysISS segue o modelo padronizado ABRASF. Segue abaixo suas particularidades:

1. Recibo Provisório de Serviços

  • Obrigatoriedade do número do lote e do RPS ser sequencial;

2. O sistema não permite:

Gerar link de Impressão da NFS-e no modelo da prefeitura.

3. Cancelamento

  • Cancelamento de NFS-e pelo não pagamento dos serviços prestados: O fato gerador do ISS é a prestação do serviço. Caso tenha sido emitida uma NFS-e para um serviço efetivamente prestado, o ISS será devido e não será possível seu cancelamento simplesmente pelo motivo do mesmo não ter sido pago pelo tomador.
  • Cancelamento de NFS-e se não houver devolução do pagamento antecipado, sinal ou adiantamento: Caso a NFS-e tenha sido emitida em decorrência de o prestador ter recebido adiantamento, sinal ou pagamento antecipado, mas o serviço não tenha sido prestado, a NFS-e somente poderá ser cancelada se efetivamente ocorrer a devolução do valor ao tomador de serviços.
  • Cancelamento de NFS-e com ISS pago. Caso o ISS referente à NFS-e estiver pago não será possível seu cancelamento.

 4. Tomador do exterior

  • Não informar apenas o CPF ou CNPJ;
  • O campo de Exigibilidade ISS deve ser informado 4, conforme layout (Exportação);
  • Informar obrigatoriamente o campo CEP;
  • Não informar o Brasil como país de prestação de serviço.

5. Código CNAE

  • O código CNAE segue a regras legislativas do município, sendo informado apenas quando o município possuir em sua legislação a permissão para tal.

6. Natureza da Operação:

O campo de natureza da operação deverá seguir o padrão ABRASF:

natop

7. Regime Especial de Tributação

Conforme o padrão ABRASF seguem os seguintes valores para o campo de Regime Especial de Tributação:

tributacao

8. Alíquota

A alíquota do ISS será informada automaticamente baseada no serviço selecionado e definida pela administração tributária e não poderá ser alterada pelo prestador quando:

  • Exigibilidade do ISS for exigível ou Exigibilidade Suspensa por Decisão Judicial ou Exigibilidade
  • Suspensa por Processo Administrativo;
  • O Tipo de Tributação do ISS do Prestador for homologado;

A alíquota será informada pelo prestador de serviços quando:

  • A Exigibilidade do ISS for exigível ou Exigibilidade Suspensa por Decisão Judicial ou Exigibilidade
  • Suspensa por Processo Administrativo;
  • O município da prestação do serviço for diferente do município do prestador;
  • Houver retenção de ISS;
  • Prestador não estiver enquadrado como MEI – Microempreendedor Individual.

A alíquota do ISS será automaticamente zerada e não poderá ser alterada pelo prestador quando:

  • A Exigibilidade do ISS for Não Incidência, Isenção, Exportação ou Imunidade;
  • O prestador estiver enquadrado como MEI – Microempreendedor Individual, independentemente de qualquer condição;
  • O prestador for optante pelo Simples Nacional e não tiver o ISS retido pelo tomador;
  • A Exigibilidade do ISS for exigível ou Exigibilidade Suspensa por Decisão Judicial ou Exigibilidade
  • Suspensa por Processo Administrativo e o Tipo de Tributação do ISS do Prestador for Estimativa ou Fixo.

 9. Exemplo XML

Clique aqui, para visualizar um exemplo de XML de envio.

Padrão GENFE

Última atualização em: 09 de abril, 2021

O Padrão GENFE segue o modelo sugerido pela ABRASF, na versão 1.0. Disponibilizando a tecnologia de Web Services para realizar as emissões de NFS-e. Abaixo, estão descritas as particularidades deste padrão:

1. Número de RPS

O Padrão GENFE utiliza numeração sequencial e série única para a emissão de NFS-e.

2. O sistema não permite:

  • Recepção de RPS sem dados do Tomador (Endereço, Número, código da cidade e UF);
  • Substituição de RPS;

3. Outras Informações

O padrão GENFE não possui uma tag específica para informar “outras informações” sobre o RPS a ser emitido. Por isso no cadastro da empresa deve-se escolher o valor “Sim” para o campo “Concatenar Discriminação e Outras Informações”, como mostra a imagem:

OutrasInformacoes

4. Ambientes

A prefeitura dispõe além do ambiente de produção o ambiente de homologação, para fazer uso deles e consequentemente dos Web Services, é necessário contatar a mesma e fazer a solicitação formal, fornecendo informações como CNPJ e Inscrição Municipal.

Para visualizar um exemplo de XML enviado ao InvoiCy NFS-e, clique aqui.

Padrão VLCNET – Antigo

Última atualização em: 09 de agosto, 2016

 

O Padrão VLCNET é do tipo TXT, não disponibilizando de Web Services para emissão, consulta e cancelamento de NFS-e, fazendo-se necessário a geração de arquivos para upload no sistema web da prefeitura. Abaixo estão detalhadas as particularidades deste padrão:

1. Número e Série Única do RPS

O padrão VLCNET utiliza somente uma única série para emissão de NFS-e, sendo esta formada apenas pelo caractere “U” (sem aspas), consequentemente, não é permitido que haja repetição dos números de RPS, os números deverão ser utilizados de forma sequencial, a partir da numeração já utilizada para a emissão de NFS-e no sistema web da prefeitura.

2. Natureza da Operação

Tabela com as opções de Natureza da Operação aceitas pela pelo sistema VLCNET:

3. O sistema não permite

  • Inutilização da Nota
  • Substituição de RPS
  • Não dispõe de ambiente de homologação

4. Obrigatoriedade de Informações

De acordo com o manual disponibilizado pela empresa desenvolvedora deste padrão de NFS-e, das 14 informações que compõe o RPS no arquivo TXT, somente 2 não são obrigatórias de se informar, sendo elas: Discriminação do Serviço e a informação de Outros Impostos, sendo que todas as demais informações devem ser preenchidas corretamente a fim de não haverem erros no arquivo TXT a ser gerado.

O campo Outros Impostos, no layout do padrão VLCNET é composto pela concatenação dos valores do PIS, COFINS, CSLL, IRRF e INSS. Então, se o prestador do serviço informar alguns desses valores no layout de integração (ou todos os valores desses impostos), o InvoiCy reconhecerá e formatará esse campo de acordo com o que se pede no manual do padrão VLCNET.

5. Tomador

Para que o prestador de serviço possa emitir uma NFS-e contra determinado tomador, esse tomador deve estar cadastrado no sistema da prefeitura, pois o layout do arquivo que é gerado para upload no sistema web da prefeitura contém somente uma informação que remete ao tomador, sendo ela o campo “CPF/CNPJ do Tomador”.

Para cadastrar um novo tomador, pode-se acessar através do sistema web da prefeitura o menu “MANUTENÇÃO => Cadastro de tomadores”, como mostra a imagem abaixo:

Cadastro de Tomadores

Após ser redirecionado para uma nova tela, basta clicar no botão “Incluir” e após isso informar as informações do tomador de serviço.

Outra forma de cadastrar novos tomadores é realizar a geração de um arquivo TXT, o layout de integração para geração deste arquivo pode ser encontrado no manual disponibilizado no sistema da prefeitura no menu “AJUDA => Manual Online” no item “6. Layout de Importação de Tomadores”.

O padrão VLCNET permite que seja emitido um RPS sem tomador, nesse caso, basta apenas que não se informe as Tags referentes à CPF e CNPJ do Tomador no layout de integração do InvoiCy.

Para emitir um RPS para tomador estrangeiro, deve-se informar o valor para a Tag referente ao “Documento do Tomador Estrangeiro”, além de não poder se informar valores para as Tags de CPF e CNPJ do Tomador.

6. Importação do RPS

Após a geração do arquivo TXT contendo o RPS, é necessário acessar o sistema web da prefeitura e realizar o upload do mesmo. Para isso deve-se primeiramente validar o arquivo, acessando o validador através do menu “MANUTENÇÃO => Validação de RPS”, onde o usuário é redirecionado para a seguinte tela:

Img2

Onde se deve selecionar o arquivo que se deseja importar, e clicar em “Validar”. Após isso, se o arquivo estiver com sua estrutura totalmente correta, o sistema libera para que este arquivo seja importado, através do menu “MANUTENÇÃO => Importação de RPS”, como mostra a imagem:

Img3

Nesta nova tela, além de selecionar o arquivo que se deseja importar, deve-se escolher qual o valor da alíquota do ISS a ser utilizada. Após, basta clicar no botão “Importar”, para realizar a importação do RPS.

7. Importação do Retorno

Como este padrão não tem suporte à Web Services, é necessário exportar um arquivo XML contendo as informações das NFS-e emitidas e que se deseja importar o retorno das mesmas.

Através do menu ”MANUTENÇÃO => Exportação em XML” o usuário é redirecionado para uma tela onde se apresentação 2 tipos de filtros. O primeiro, “Mês/Ano” informa-se quando se deseja gerar o arquivo XML contendo todas as NFS-e geradas na competência escolhida. O Segundo filtro, “NFS-e Inicial e NFS-e Final”, possibilita que o usuário informe o número inicial e o número final de NFS-e que se deseja exportar do sistema, como mostra a imagem:

Img4

Lembrando que além do arquivo de retorno gerado em Base64, obrigatoriamente deve-se informar o valor “XML” para a Tag “ExtensaoArquivo”.

8. Exemplo XML

Segue um exemplo de XML de envio contendo os campos que serão enviados para o InvoiCy NFS-e. Para visualizar o XML de exemplo clique aqui.

 

Padrão VLCNET

Última atualização em: 09 de abril, 2021

O Padrão VLCNET é do tipo TXT, não disponibilizando de Web Services para emissão, consulta e cancelamento de NFS-e, fazendo-se necessário a geração de arquivos para upload no sistema web da prefeitura. Abaixo estão detalhadas as particularidades deste padrão:

1. Número e Série Única do RPS

O padrão VLCNET utiliza somente uma única série para emissão de NFS-e, sendo esta formada apenas pelo caractere “U” (sem aspas), consequentemente, não é permitido que haja repetição dos números de RPS, os números deverão ser utilizados de forma sequencial, a partir da numeração já utilizada para a emissão de NFS-e no sistema web da prefeitura.

2. Natureza da Operação

Tabela com as opções de Natureza da Operação aceitas pela pelo sistema VLCNET:

3. O sistema não permite

  • Inutilização da Nota
  • Substituição de RPS
  • Não dispõe de ambiente de homologação

4. Obrigatoriedade de Informações

De acordo com o manual disponibilizado pela empresa desenvolvedora deste padrão de NFS-e, das 14 informações que compõe o RPS no arquivo TXT, somente 2 não são obrigatórias de se informar, sendo elas: Discriminação do Serviço e a informação de Outros Impostos, sendo que todas as demais informações devem ser preenchidas corretamente a fim de não haverem erros no arquivo TXT a ser gerado.

O campo Outros Impostos, no layout do padrão VLCNET é composto pela concatenação dos valores do PIS, COFINS, CSLL, IRRF e INSS. Então, se o prestador do serviço informar alguns desses valores no layout de integração (ou todos os valores desses impostos), o InvoiCy reconhecerá e formatará esse campo de acordo com o que se pede no manual do padrão VLCNET.

5. Tomador

Para que o prestador de serviço possa emitir uma NFS-e contra determinado tomador, esse tomador deve estar cadastrado no sistema da prefeitura, pois o layout do arquivo que é gerado para upload no sistema web da prefeitura contém somente uma informação que remete ao tomador, sendo ela o campo “CPF/CNPJ do Tomador”.

Para cadastrar um novo tomador, pode-se acessar através do sistema web da prefeitura o menu “MANUTENÇÃO => Cadastro de tomadores”, como mostra a imagem abaixo:

Cadastro de tomadores

Após ser redirecionado para uma nova tela, basta clicar no botão “Incluir” e após isso informar as informações do tomador de serviço.

Outra forma de cadastrar novos tomadores é realizar a geração de um arquivo TXT, o layout de integração para geração deste arquivo pode ser encontrado no manual disponibilizado no sistema da prefeitura no menu “AJUDA => Manual Online” no item “6. Layout de Importação de Tomadores”.

O padrão VLCNET permite que seja emitido um RPS sem tomador, nesse caso, basta apenas que não se informe as Tags referentes à CPF e CNPJ do Tomador no layout de integração do InvoiCy.

Para emitir um RPS para tomador estrangeiro, deve-se informar o valor para a Tag referente ao “Documento do Tomador Estrangeiro”, além de não poder se informar valores para as Tags de CPF e CNPJ do Tomador.

6. Importação do RPS

Após a geração do arquivo TXT contendo o RPS, é necessário acessar o sistema web da prefeitura e realizar o upload do mesmo. Para isso deve-se primeiramente validar o arquivo, acessando o validador através do menu “MANUTENÇÃO => Validação de RPS”, onde o usuário é redirecionado para a seguinte tela:

Img2

Onde se deve selecionar o arquivo que se deseja importar, e clicar em “Validar”. Após isso, se o arquivo estiver com sua estrutura totalmente correta, o sistema libera para que este arquivo seja importado, através do menu “MANUTENÇÃO => Importação de RPS”, como mostra a imagem:

Img3

Nesta nova tela, além de selecionar o arquivo que se deseja importar, deve-se escolher qual o valor da alíquota do ISS a ser utilizada. Após, basta clicar no botão “Importar”, para realizar a importação do RPS.

7. Importação do Retorno

Como este padrão não tem suporte à Web Services, é necessário exportar um arquivo XML contendo as informações das NFS-e emitidas e que se deseja importar o retorno das mesmas.

Através do menu ”MANUTENÇÃO => Exportação em XML” o usuário é redirecionado para uma tela onde se apresentação 2 tipos de filtros. O primeiro, “Mês/Ano” informa-se quando se deseja gerar o arquivo XML contendo todas as NFS-e geradas na competência escolhida. O Segundo filtro, “NFS-e Inicial e NFS-e Final”, possibilita que o usuário informe o número inicial e o número final de NFS-e que se deseja exportar do sistema, como mostra a imagem:

Img4

Lembrando que além do arquivo de retorno gerado em Base64, obrigatoriamente deve-se informar o valor “XML” para a Tag “ExtensaoArquivo”.

8. Exemplo XML

Segue um exemplo de XML de envio contendo os campos que serão enviados para o InvoiCy NFS-e. Para visualizar o XML de exemplo clique aqui.

Padrão SAPITUR

Última atualização em: 08 de abril, 2021

O Padrão SAPITUR segue o modelo padronizado ABRASF. Segue abaixo suas particularidades:

1. Recibo Provisório de Serviços

  • Cada lote de RPS permite no máximo 50 RPS.
  • Importação de RPS após o prazo: No momento da importação, a data do RPS será validada com as configurações do sistema de emissão de NFS-e, caso a data esteja fora do prazo, o RPS será recusado.
  • Tipo de serviço por RPS: Cada recibo provisório deve ter apenas um tipo de serviço informado, com alíquota correspondente e valor total do serviço informado, portanto o item da lista de serviço é um campo obrigatório.
  • O arquivo base64 retornado pelo InvoiCy para que o usuário possa fazer o upload no site da prefeitura deve obrigatoriamente ser salvo na codificação UTF-8 (sem BOM).

2. Alíquota

A alíquota informada deve obedecer:

  • Os percentuais definidos pelo município para cada tipo de serviço.
  • O regime de tributação quando a empresa for optante pelo Simples Nacional.
  • A regra para cálculo de ISS quando existir Regime Especial de tributação.
  • A forma de tributação quando o contribuinte for autônomo.

3. O sistema não permite:

  • Consulta da NFS-e
  • Impressão da NFS-e
  • Substituição de Notas Fiscais, apenas pelo sistema da Prefeitura
  • Cancelamento de Notas Fiscais, apenas pelo sistema da Prefeitura

4. Cancelamento

  • Não possui Web Services de cancelamento no sistema, o processo de cancelamento da nota só pode ser efetuado por meio do Sistema da Prefeitura. O cancelamento da nota pode ser efetuado dentro dos 7 dias previstos por lei ou conforme a questão legal da própria prefeitura do seu município.

5. Substituição

  • A substituição de NFS-e só é permitida por meio do sistema web da prefeitura.

6. Tomador de Serviço

  • O XML não tem suporte para RPS de tomadores do exterior, neste caso o prestador de serviços precisa fazer a emissão da nota diretamente pelo Sistema da Prefeitura.
  • Antes de realizar a importação para conversão de RPS em NFS-e, é necessário que os tomadores estejam devidamente cadastrados no Sistema da Prefeitura.
  • As informações de identificação e endereço do tomador são obrigatórias.

 7. Natureza da Operação:

O campo de natureza da operação deverá seguir o padrão ABRASF:

NaturezaOperacao

8. Regime Especial de Tributação

Conforme o padrão ABRASF seguem os seguintes valores para o campo de Regime Especial de Tributação:

RegimeEspecialdeTributação

9. Exemplo XML

Para acessar um exemplo de XML de envio, clique aqui

Padrão SAPITUR – Antigo

 

O Padrão SAPITUR segue o modelo padronizado ABRASF. Segue abaixo suas particularidades:

1. Recibo Provisório de Serviços

  • Cada lote de RPS permite no máximo 50 RPS.
  • Importação de RPS após o prazo: No momento da importação, a data do RPS será validada com as configurações do sistema de emissão de NFS-e, caso a data esteja fora do prazo, o RPS será recusado.
  • Tipo de serviço por RPS: Cada recibo provisório deve ter apenas um tipo de serviço informado, com alíquota correspondente e valor total do serviço informado, portanto o item da lista de serviço é um campo obrigatório.
  • O arquivo base64 retornado pelo InvoiCy para que o usuário possa fazer o upload no site da prefeitura deve obrigatoriamente ser salvo na codificação UTF-8 (sem BOM).

2. Alíquota

A alíquota informada deve obedecer:

  • Os percentuais definidos pelo município para cada tipo de serviço.
  • O regime de tributação quando a empresa for optante pelo Simples Nacional.
  • A regra para cálculo de ISS quando existir Regime Especial de tributação.
  • A forma de tributação quando o contribuinte for autônomo.

3. O sistema não permite:

  • Consulta da NFS-e
  • Impressão da NFS-e
  • Substituição de Notas Fiscais, apenas pelo sistema da Prefeitura
  • Cancelamento de Notas Fiscais, apenas pelo sistema da Prefeitura

4. Cancelamento

  • Não possui Web Services de cancelamento no sistema, o processo de cancelamento da nota só pode ser efetuado por meio do Sistema da Prefeitura. O cancelamento da nota pode ser efetuado dentro dos 7 dias previstos por lei ou conforme a questão legal da própria prefeitura do seu município.

5. Substituição

  • A substituição de NFS-e só é permitida por meio do sistema web da prefeitura.

6. Tomador de Serviço

  • O XML não tem suporte para RPS de tomadores do exterior, neste caso o prestador de serviços precisa fazer a emissão da nota diretamente pelo Sistema da Prefeitura.
  • Antes de realizar a importação para conversão de RPS em NFS-e, é necessário que os tomadores estejam devidamente cadastrados no Sistema da Prefeitura.
  • As informações de identificação e endereço do tomador são obrigatórias.

 7. Natureza da Operação:

O campo de natureza da operação deverá seguir o padrão ABRASF:

NaturezaOperacao

8. Regime Especial de Tributação

Conforme o padrão ABRASF seguem os seguintes valores para o campo de Regime Especial de Tributação:

RegimeEspecialdeTributação

9. Exemplo XML

Acesse o exemplo de XML de envio, clicando aqui.

Padrão Metrópolis

Última atualização em: 08 de abril, 2021

O Padrão Metrópolis segue o modelo sugerido pela ABRASF, na versão 1.0. Disponibilizando a tecnologia de Web Services para realizar as emissões de NFS-e. Abaixo, estão descritas as particularidades deste padrão:

1. Número e Série Única do RPS

O Padrão Metrópolis utiliza uma Série única para a emissão de NFS-e, obrigando assim que o prestador utilize somente uma ÚNICA série e consequentemente não repita os números de RPS, utilizando-os sempre de forma sequencial.

2. Natureza da Operação

Tabela com as opções de Natureza da Operação aceitas pela pelo sistema Metrópolis:

Tabela1

3. O sistema não permite:

  • Inutilização da Nota;
  • Recepção de RPS sem Tomador;
  • Recepção de RPS com Tomador Estrangeiro;
  • Substituição de RPS;

 4. Outras Informações

O padrão Metrópolis não possui uma tag específica para informações outras informações sobre o RPS a ser emitido, por isso, no cadastro da empresa, deve-se escolher o valor “Sim” para o campo “Concatenar Discriminação e Outras Informações”, como mostra a imagem:

Imagem1

5. Ambientes

A prefeitura dispõe além do ambiente de produção o ambiente de homologação, para fazer uso deles e consequentemente dos Web Services, é necessário contatar a mesma e fazer a solicitação formal, fornecendo informações como CNPJ e Inscrição Municipal para o endereço de e-mail cedes02@edza.com.br ou ligar no número (71) 3273-3200.

6. Cancelamento

Pelo motivo do sistema Metrópolis não dispor de cancelamento de NFS-e via Web Service, o prestador que desejar realizar tal operação deve acessar o a aplicação Metrópolis Web através do portal da Prefeitura.

Imagem2

Após realizar o login com as credenciais habilitadas junto a prefeitura, deve-se acessar o menu “NFS-e => Nota Fiscal Eletrônica”.

Imagem3

Assim, o usuário é redirecionado para a tela de Consulta de NFS-e emitidas. Para realizar o cancelamento o usuário deve encontrar a NFS-e que deseja e clicar no botão referente ao cancelamento (X).

Imagem4

7. Informações do Tomador

O telefone do tomador só pode ser enviado com 11 dígitos.

8. Exemplo XML

Acesse o exemplo de XML enviado ao InvoiCy BR, através deste link.