Padrão AWATAR WS

Última atualização em: 03 de janeiro, 2019

O Padrão Awatar WS segue o modelo próprio. Segue abaixo suas particularidades:

1. O sistema não permite:

  • Substituição de Notas Fiscais de Serviço Eletrônica;
  • Impressão do RPS no modelo da prefeitura;
  • Inutilização de Notas;
  • Intermediário do serviço.

2. Solicitação na prefeitura

  • Para realizar a emissão via web service o cliente deve solicitar na prefeitura do seu município o usuário e senha. No wizard de cadastro do InvoiCy BR deverá ser informado o usuário e senha nos campos de usuário e senha de autenticação.

3. 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, em certos municípios não possui a exigência para informar, portanto mantendo em branco.

4. Impressão

  • Possui disponibilidade de impressão pelo modelo da prefeitura do município onde a empresa está situada.

5. Formas de pagamento

As formas de pagamento devem ser seguidas conforme a tabela relacional do município:

6. Natureza da Operação

O campo de natureza da operação deverá seguir o padrão próprio do município:

7. Exemplo XML

Clique aqui para visualizar um exemplo de XML enviado ao InvoiCy NFS-e.

Padrão SafeWeb

Última atualização em: 29 de outubro, 2018

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

1. O sistema não permite:

  • Substituição de NFS-e;
  • Inutilização de NFS-e.

2. Obrigatoriedades

  • Informar valor no item da lista de serviço.

3. Tomador do exterior

  • O campo de Exigibilidade ISS deve ser informado 4, conforme layout (Exportação);
  • Informar o código do país dentro do grupo de serviço.

4. Código CNAE

  • O código CNAE segue a regras legislativas do município, devendo sendo informado, quando houver Alíquota e item da Lista de Serviço.

5. Impressão

  • Não possui disponibilidade de impressão pelo modelo da prefeitura do município onde a empresa está situada.

6. Natureza da Operação:

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

Natureza da operação

7. Regime Especial de Tributação

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

Regime Especial de Tributação

8. Exemplo XML

Clique aqui para visualizar um exemplo de XML enviado ao InvoiCy NFS-e.

Padrão Città

Última atualização em: 02 de outubro, 2018

PARTICULARIDADES PADRÃO CITTÀ

O Padrão Città utiliza o modelo de layout XML da ABRASF 2.0. Abaixo estão detalhadas as particularidades deste padrão:

  • O sistema não permite:
  • Inutilização da Nota;
  • Tomador

Não permite que enviei o RPS sem possuir tomador na nota.

  • Tomador estrangeiro

Para efetuar a correta emissão de notas fiscais para o estrangeiro deve-se deixar de informar os seguintes campos:

  • Código do município;
  • CNPJ.

Devendo ser informado apenas a razão social, número do documento do tomador estrangeiro e o código do país do tomador.

  • Outras Informações

O layout XML da prefeitura não possui o campo Outras informações portanto caso o contribuinte desejar informá-lo deve inserir no cadastro de empresa, a confirmação de concatenar Outras Informações na discriminação, como ilustra a imagem.

  • Cancelamento

O cancelamento de NFS-es obedece ao prazo estipulado pelo município. Geralmente deve ocorrer entre 5/15 dias úteis.

  • Impressão

O sistema possui impressão de NFS-e para a prefeitura, devendo possuir o usuário e senha disponibilizados pela prefeitura do seu município para realizar a impressão.

  • Natureza da Operação

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

Para visualizar um XML de exemplo clique aqui.

Padrão INFISC Bom Princípio

Última atualização em: 03 de setembro, 2018

O Padrão INFISC Bom Princípio não segue o padrão ABRASF. Segue abaixo as particularidades deste novo padrão:

1. Número e Série do RPS

O número da série é único obrigatoriamente. Para permitir a emissão de NFS-e, deve ser solicitada junto a prefeitura a liberação da série para emissão. A série disponibilizada é a de valor ‘S’.

2. O sistema não permite:

  • Informar o Intermediário do serviço;
  • Substituição de RPS;
  • Efetivar uma nota sem Tomador.

3. Cancelamento

O cancelamento pode ser efetuado a qualquer momento pelo contribuinte desde que não tenha efetuado a geração de sua guia mensal.

4. Tipo de placa do veículo

Placa de veículo com os possíveis seguintes formatos: XXX9999, XXX999, XX9999 ou XXXX999. Informar a placa em campo de Informações Adicionais quando tiver lei de formação diversa destes formatos e para placa da transportadora.

5. Tomador do Exterior

  • O CPF/CNPJ deve ser informado vazio;
  • A UF deve ser informada vazia;
  • Código do Município deve ser informado vazio;
  • Não é permitido substituição tributária para tomadores de serviço do exterior.

6. ISS Retido

O município não permite retenção de ISS para pessoa Física.

7. Impressão

Possui a opção de impressão com o modelo da prefeitura.

8. Exemplo XML

Clique aqui para visualizar um exemplo de XML enviado ao InvoiCy NFS-e.

LAYOUT XML 4.00

Última atualização em: 11 de maio, 2018

 

Olá! Este artigo tem por objetivo disponibilizar o layout 4.00 do XML da NF-e e da NFC-e. Aqui você irá encontrar a estrutura completa de campos para realizar a integração de seu ERP com o InvoiCy.

A tabela abaixo deve ser utilizada como legenda para interpretação dos campos do arquivo do envio e retorno do XML.

Coluna

Nome do Campo

Tipo

(tamanho)

N – campo numérico C – campo alfanumérico D – campo data H – campo hora

Ele

G – Grupo E – Elemento CG – Elemento de Grupo que deriva de uma escolha (choice) CE – Elemento que deriva de uma escolha (choice)

Pai

TAG raiz do XML de integração entre ERP e GNF-e

Ocorrência

x-y, onde x indica a ocorrência mínima e y, a ocorrência máxima:

1-1 = campo obrigatório, com uma possibilidade,

1-N = campo obrigatório, com uma ou várias possibilidades,

0-1 = campo opcional, com uma possibilidade,

0-N = campo opcional, com uma ou várias possibilidades.

Este layout encontra-se adequado com a Nota Técnica NT2016.002, disponibilizado pela SEFAZ (Secretaria da Fazenda). A íntegra desta NT pode ser consultada clicando aqui.

O layout 4.00 do XML está disponível para download em arquivo XLS. Para visualizá-lo, certifique-se de que você possui o Microsoft Excel instalado em seu computador.

DOWNLOAD:

LAYOUT XML 4.00 (NF-e e NFC-e)

Acesse também a Central de Downloads Migrate, onde você poderá encontrar diversos exemplos reais de NF-e e NFC-e para download.

 

Release Notes – Versão 1.32.0.0

Versão 1.32.0.0 – 14/02/2018 – Em produção

Envio de prévia da NF-e

A partir dessa versão o InvoiCy irá permitir o envio de uma prévia de NF-e através da integração via Web Service. Essa prévia consiste em um resumo da nota, que poderá conter apenas algumas informações principais, como pode ser observado na imagem abaixo a estrutura de envio da prévia com os campos obrigatórios.

Envio da prévia NF-e

A partir do recebimento dessa prévia será criado um registro da NF-e na tela de “Documentos em digitação”. Posteriormente essa nota poderá ser complementada manualmente pelo usuário e emitida através da tela de digitação do InvoiCy. Para mais informações leia o artigo Envio de prévia da NF-e.

Configuração para imprimir duplicatas no DANFE

Na tela de configurações de impressão da NF-e foi adicionada uma nova opção de configuração, ‘Imprimir duplicatas’, como demonstra a imagem a seguir.

Essa configuração possibilita ao usuário escolher se deseja imprimir as informações de Duplicatas no DANFE. Ao configurar a opção como ‘Sim’, o bloco Duplicatas será impresso no DANFE, como pode ser observado na imagem abaixo. Se optar por não imprimir as Duplicatas basta configurar a opção como ‘Não’.

Inutilização de NFS-e

A partir dessa versão clientes emissores de NFS-e poderão inutilizar no InvoiCy os documentos rejeitados. Destacando que apenas Caxias do Sul-RS disponibiliza serviço de inutilização, para os demais municípios a NFS-e será inutilizada apenas no InvoiCy. E para padrões que fazem uso da sequência de numeração do RPS não será permitida a inutilização. Para mais informações leia o artigo Serviço de inutilização de NFS-e.

Detalhamento da versão

Para conhecer todas as modificações realizadas nessa versão, clique aqui.

 

Versão 1.32.0.0 – mais detalhes

Última atualização em: 14 de fevereiro, 2018

Confira todas as alterações e melhorias realizadas na versão 1.32.0.0 do InvoiCy, que já está em produção:

Código da solicitação – Descrição

8078 – Processo de importação de arquivos para emissão: foram efetuadas algumas melhorias e correções no processo de importação de arquivos para emissão.

8198 – Cancelamento de licenças: o processo de cancelamento de licenças via tela não estava funcionando de acordo para algumas empresas que possuíam caracteres especiais em seus dados. Foi realizado um tratamento sobre esses caracteres para assim não impactar no cancelamento das licenças.

8283 – Logs do documento: na tela de detalhes do documento, aba Logs, será exibida uma quantidade de 100 logs, e caso houver novas tentativas de interação com esse documento sempre o último log será atualizado, mantendo ainda os logs antigos, mas sem ultrapassar o limite de 100 registros.

NF-e:

8257 – Prévia de NF-e: o InvoiCy irá permitir o envio de uma prévia de NF-e através da integração via WS, criando um registro da NF-e na tela de “Documentos em digitação”. Posteriormente o usuário poderá emitir manualmente essa NF-e através da tela de digitação do InvoiCy. Para mais informações leia o artigo Envio de prévia da NF-e.

8206 – Configuração para imprimir duplicatas no DANFE: através da opção ‘Imprimir duplicatas’ na tela de configurações de impressão da NF-e, o usuário poderá escolher se deseja imprimir as informações de Duplicatas no DANFE.

8234 – Envio de eventos via tela de detalhes: ao enviar uma carta de correção ou efetuar o cancelamento de uma NF-e via tela de detalhes do documento, informando algum caractere especial ou espaços após o último caractere do texto o evento não era efetivado com sucesso. Foi realizado um tratamento para remover esses caracteres e assim efetuar a emissão dos eventos.

8222 – Carta de Correção para NF-e: ao enviar uma carta de correção para uma NF-e, será validado se a chave de acesso informada condiz com o número da NF-e, caso não estiver de acordo retornará a seguinte mensagem: “O número do documento difere do número do documento na chave de acesso”.

CT-e:

8184 – Melhorias no DACTE: foram efetuadas algumas melhorias no DACTE, para não cortar as informações de natureza da operação e nome do emitente quando as descrições forem muito extensas. Também se otimizou o espaço diminuindo o tamanho do bloco de ‘Documentos originários’.

8177 – Envio de CC-e: nas versões anteriores não era possível enviar uma carta de correção no layout 3.0 para um CT-e que já estava autorizado no layout antigo 2.0. Efetuou-se um tratamento e a partir dessa versão será possível emitir o evento com o novo layout 3.0 para CT-e autorizado no layout antigo.

8212 – Retorno do envio de CC-e: a partir dessa versão, ao enviar uma carta de correção via integração Web Service, será retornado também o base64 do PDF da carta de correção.

MDF-e:

7962 – Detalhes dos eventos: ao acessar a aba ‘Eventos’ na tela de detalhes de um MDF-e, e clicar nas informações da grid, será aberta uma nova tela exibindo os detalhes do respectivo evento.

NFS-e:

8175 – Link de impressão da prefeitura para o padrão Nota Carioca: a partir dessa versão empresas emissoras de NFS-e para o padrão Nota Carioca também poderão configurar na tela de configurações para emissão se desejam receber no retorno o link de impressão da prefeitura, através da configuração ‘Retornar link de impressão da prefeitura, quando disponível’.

8117 – Inutilização de NFS-e: a partir dessa versão os clientes emissores de NFS-e poderão inutilizar os documentos rejeitados no InvoiCy. Para mais informações leia o artigo Serviço de inutilização de NFS-e.

8325 – Não imprimir itens no espelho do RPS: empresas que emitem NFS-e poderão configurar se desejam imprimir os itens no espelho do RPS, através da nova opção na tela de configurações de emissão de NFS-e “Imprimir os itens no espelho”, como demonstra a imagem abaixo.

Ao configurar essa opção como ‘Sim’ o espelho do RPS sairá com os itens impressos, como pode ser visto na imagem abaixo.

Já ao configurar a opção como ‘Não’ o espelho do RPS não irá imprimir os itens, de acordo com a imagem a seguir.

 

Envio de prévia da NF-e

Última atualização em: 05 de fevereiro, 2018

O InvoiCy conta com uma nova funcionalidade a partir de agora, a possibilidade de enviar uma prévia da NF-e através da integração via Web Service. Essa prévia consiste em um resumo da nota, que poderá conter apenas algumas informações principais da NF-e.

Ao receber essa estrutura da prévia, o InvoiCy irá criar um registro da NF-e na tela de documentos em digitação. Posteriormente essa nota poderá ser complementada manualmente pelo usuário e emitida através da tela de digitação do InvoiCy.

Na sequência apresentamos um passo a passo de como proceder para enviar a prévia de uma NF-e.

Primeiramente o seu ERP deve realizar a integração com o novo Web Service disponibilizado pelo InvoiCy. Trata-se do WS arecepcaoprevia.aspx. Este Web Service é único e deve ser utilizado apenas para efetuar o envio da prévia das NF-e. Abaixo, detalhamos o processo de integração com esse Web Service.

Para realizar a integração siga os seguintes passos:

1. Visualizando a estrutura WSDL do Web Service

Para visualizar a estrutura WSDL do Web Service basta copiar e colar o link do Web Service em seu navegador de internet, por exemplo, https://homolog.invoicy.com.br/arecepcaoprevia.aspx?wsdl. Assim podemos visualizar toda a estrutura do WSDL, conforme demonstra a imagem abaixo:

2. Realizando o consumo do Web Service

Você deverá realizar o consumo do Web Service para efetuar a integração. Ao consumir o WS deverá informar os seguintes parâmetros:

EmpPK: Chave de Parceiro disponibilizada pela Migrate para cada cliente.

Exemplo: PYcEsFuKroDBojfiFEl+Ms==

A chave de parceiro é gerada por nosso Sistema de Gestão no momento que a sua empresa é cadastrada como nosso parceiro. A mesma será enviada por e-mail e utilizada para controlar as empresas de clientes finais que utilizarão licenças adquiridas pela sua empresa.

EmpCK: Código HASH gerado em formato MD5 de acordo com os dados enviados.

Exemplo: 213f3b55d679e790258fd811cc86d309

Utilizado para validar a comunicação e proporcionar segurança à comunicação. Consulte o artigo Como gerar o código Hash MD5? para mais informações.

EmpCO: Identificador do PDV. Não é necessário o preenchimento.

Texto: Uso interno do InvoiCy. Não é necessário o preenchimento.

Documento: Conteúdo do XML da prévia a ser enviada para o InvoiCy.

Parâmetros: Neste campo podem ser informados alguns parâmetros, como por exemplo, quais dados deseja que retorne ao executar uma consulta de documentos. Não é necessário o preenchimento.

Dentro da TAG <inv:Documento>, você deverá informar o conteúdo XML da prévia. O conteúdo da tag “Documento” deve ser convertido para texto, como demonstra a imagem abaixo:

Para fazer download da estrutura SOAP de envio clique aqui.

3. Gerando a estrutura do arquivo XML da prévia

O layout para envio da prévia segue a mesma estrutura do layout de envio da NF-e, onde deve ser incluído apenas o campo <NumeroPedido>, e substituída a tag pai <Envio> por <EnvioPrevia>. Para visualizar o layout de envio da NF-e clique aqui.

A imagem abaixo representa o layout com os campos obrigatórios para o envio da prévia. Os demais campos do layout podem ser incluídos conforme a necessidade da empresa.

Envio da prévia NF-e

Para fazer download da estrutura do arquivo XML exibido na imagem clique aqui.

Abaixo esclarecemos algumas informações importantes sobre o envio da prévia.

– Número do pedido:

O número do pedido é único para cada documento enviado, ou seja, para cada novo número de pedido será gerado um novo documento.

Se o número do pedido enviado já existir no InvoiCy e a nota ainda estiver em digitação, os dados do documento serão atualizados.

Porém se o número do pedido já existir no InvoiCy, mas a nota não estiver mais em digitação, ou seja, estiver com status final (autorizada, rejeitada, cancelada), será retornada uma mensagem informando que o número do pedido corresponde a um documento já emitido.

– Série do documento:

Não é obrigatório informar a série para o envio da prévia. Nesse caso o InvoiCy irá pegar a série que está cadastrada como padrão para a empresa, e gerar o documento seguindo a numeração já existente.

Caso o cliente informe uma série, mas a mesma ainda não está cadastrada, o InvoiCy irá cadastrar a série para a empresa, porém não como série padrão.

– Informações de produto, destinatário e tomador:

Se o cliente informar apenas o código de um produto que já está cadastrado para a empresa, o restante das informações será apresentado quando o cliente acessar o documento em digitação, de acordo com o cadastro do item.

Da mesma forma, caso o cliente informe apenas o CNPJ do destinatário e/ou transportador, as informações serão acrescentadas ao documento em digitação de acordo com o cadastro de pessoas.

Quando o usuário informar o código de um produto, CNPJ do destinatário ou transportador já existente no InvoiCy, porém com mais algumas informações, estas informações serão atualizadas nos devidos cadastros.

O cliente também tem a opção de informar um produto, destinatário ou transportador que ainda não esteja cadastrado no InvoiCy, então no momento de recebimento da prévia os mesmos serão cadastrados de acordo com as informações recebidas.

Caso o cliente envie apenas algumas informações básicas, o cadastro será efetuado mesmo assim, e posteriormente poderá ser complementado via tela no InvoiCy.

4. Realizando a leitura do retorno do envio da prévia

Após o envio da prévia da NF-e, precisamos realizar a leitura do retorno do processamento do documento. O retorno recebido segue a seguinte estrutura XML:

Para fazer download da estrutura SOAP de retorno clique aqui.

Após o recebimento da prévia no InvoiCy, será gerado um registro da NF-e na tela de documentos em digitação, conforme imagem abaixo, que poderá ser complementado e emitido pelo usuário posteriormente.

5. Consulta da prévia

Após o envio da prévia, o cliente tem a possibilidade de executar uma consulta para visualizar os documentos que ainda estão em digitação. Para isso basta enviar a mesma estrutura de consulta de documentos do InvoiCy, juntamente com os parâmetros. A imagem abaixo representa uma estrutura básica para consulta de um documento.

Consulta de documento

Nos parâmetros apenas deve ser acrescentada a tag <DocumentosDigitacao>, com a informação ‘S’, como demonstra a imagem abaixo.

Parâmetros da consulta

Para mais informações sobre a consulta de documentos leia o artigo Consultando um documento.

Como inutilizar uma NFS-e?

Última atualização em: 05 de fevereiro, 2018

Neste artigo iremos demonstrar para as empresas que possuem NFS-e com status rejeitada, como realizar a inutilização das mesmas através do Web Service do InvoiCy.

Destacando que hoje apenas o município de Caxias do Sul-RS possui serviço de inutilização, então para os demais municípios as NFS-e serão inutilizadas apenas no InvoiCy, e não na Prefeitura.

Também é importante destacar que para padrões que exigem a sequência de numeração do RPS não será permitida a inutilização dos documentos.

1. Consumindo o Web Service

Primeiramente, você deve realizar o consumo do Web Service de Inutilização de NFS-e – https://homolog.invoicy.com.br/arecepcao.aspx?wsdl.

2. Criando o XML para o envio

Para obter os layouts de envio e retorno do XML de inutilização de NFS-e, faça o download do arquivo Inutilização.zip.

O XML a ser enviado deverá conter o número inicial e final juntamente com a série da NFS-e que deverá ser inutilizada.

O documento XML deve ser inserido entre as TAGS <inv:Documento> </inv:Documento> do SOAP de envio. Para saber como gerar a Tag inv:Documento corretamente e como gerar a chave de comunicação, consulte o artigo Gerar um XML de Envio passo-a-passo.

A imagem abaixo representa um exemplo de envio de inutilização através da ferramenta SoapUI.

3. Realizando a leitura do retorno do envio da NFS-e

Após o envio do XML, precisamos realizar a leitura do retorno da inutilização da NFS-e. O retorno recebido segue a seguinte estrutura SOAP:

A estrutura SOAP acima demonstra o retorno do serviço de inutilização de apenas uma NFS-e, porém, é possível inutilizar mais de uma NFS-e em uma única requisição.

O seu sistema deve ler o retorno, validando as informações conforme o layout de retorno. O retorno criará um grupo para cada NFS-e, contendo o número, série, situação, entre outros. Retornará também os erros, caso a prefeitura não permita a inutilização.

Envio de NFS-e em lote

Última atualização em: 27 de setembro, 2017

O InvoiCy Conector também possibilita o envio de NFS-e em lotes. Para isso foi criada uma nova aba de configurações, dentro do menu ‘Opções – Configurações Gerais’, como demonstra a imagem a seguir.

Através dessa tela é possível habilitar o envio de NFS-e em lote, bem como definir a quantidade de NFS-e que será enviada por lote. A imagem abaixo destaca essas configurações.

Ao salvar as configurações será apresentada uma mensagem em tela, informando que para a aplicação das configurações será necessário parar todos os serviços que estejam em execução.

Mensagem de confirmação

Ao clicar no botão ‘OK’, será aberta a tela dos serviços, para que você usuário se certifique que todos os serviços estejam parados. Caso algum serviço esteja rodando, clique no botão ‘Parar’, como demonstra a imagem.

Ao fechar essa tela será apresentada uma mensagem de sucesso sobre a aplicação das configurações, e solicitando se deseja iniciar os serviços novamente.

Mensagem de sucesso

Ao clicar no botão ‘Sim’, será aberta novamente a tela de serviços, para que você usuário inicie os serviços desejados. Assim que os serviços estiverem iniciados, o Conector fará o envio das NFS-e em lote conforme as configurações.

OBSERVAÇÃO: é importante destacar que o envio em lote funciona apenas para arquivos do módulo NFS-e. Para os demais módulos o envio dos arquivos não sofreu nenhuma alteração.