Release Notes – Versão 1.10.1.0

Versão 1.10.1.0 – 02/08/2015

E-mail avisando vencimento de certificado

Esta versão do InvoiCy disponibiliza melhorias no processo de envio de notificações de vencimento do certificado, onde além de notificar o usuário internamente na aplicação, o sistema também passa a enviar um e-mail para o endereço informado no campo “E-mail para notificações” no cadastro da empresa, desde que a empresa possua uma caixa para envio de e-mail configurada.

Seleção do modelo de contrato para cadastro de empresas via Web Service

Para facilitar o processo de licenciamento da empresa já no momento de seu cadastro, foi disponibilizado um novo grupo no Web Service de cadastro de empresas, que permite enviar as informações de qual módulo do InvoiCy está habilitando a empresa e o modelo de contrato firmado. Para conferir as mudanças do layout de integração, sabendo como enviar os dados de modelo de contrato clique aqui.

QRCode da NFC-e na integração via WS

Devido algumas validações realizadas pelo estado do Amazonas, foi necessário modificar a geração do QRCode, desta forma nesta versão a informação enviada através da integração Web Service pelo InvoiCy passa a atender as regras do estado em questão.

Reenvio de documentos para descarte

Foi melhorado o controle para o processo de execução do reenvio de documentos referenciados (descarte). A partir de agora quando o documento estiver com um status diferente de autorizado, ou quando um documento é referenciado para inutilizar ou cancelar, o InvoiCy primeiro irá fazer uma consulta deste documento para verificação de status, que normalmente estará como “necessita interação”. Caso nesta consulta ocorrer alguma falha e não tiver um retorno válido, como autorizado ou inexistente na SEAFZ, o processo de consulta deve se repetir para este documento até obter um retorno válido, possibilitando estabelecer o retorno correto.

Se ocorrerem rejeições ou um cancelamento do documento fora do prazo, o cancelamento será rejeitado e a empresa deverá fazer uma devolução de NF-e. Desta forma é importante verificar com atenção as notificações que o InvoiCy enviará durante o processo, porém é necessário que a empresa tenha uma conta de e-mail cadastrada, caso contrário a aplicação usará a própria conta do InvoiCy para o envio.

Exportação automática de NFC-e

No processo de exportar documentos por FTP foi incluso no InvoiCy a opção de Exportação Manual, onde será possível informar uma data inicial e uma data final, exportando os documentos conforme as datas informadas, mesmo que também já exista um agendamento para a exportação automática. Sendo assim, caso configurar uma exportação manual, a data do agendamento automático não será afetada pela data informada no processo manual, onde as duas exportações configuradas deverão executar normalmente.

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

Padrão System

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

O Padrão System segue o padrão ABRASF. Segue abaixo as particularidades deste novo padrão:

1. Habilitação para emissão via Webservice

A solicitação para habilitação de emissão via Webservice deve ser realizada via portal da prefeitura, clicando na opção ‘Solicitação de uso da NFS-e’. Na tela de solicitação, deve ser informado o CNPJ do contribuinte e após isso, nas opções de ‘Tipo de Solicitação’, selecionar a segunda opção para começar a emitir em ambiente de homologação, como está mostrando na tela abaixo:

Para possibilitar a emissão em ambiente de produção, deve ser seguido o mesmo passo informado acima, porém neste caso, selecione a terceira opção em ‘Tipos de Solicitação’.

2. Numeração do RPS

A numeração do RPS deve ser ‘obrigatoriamente’ sequencial, não sendo possível pular a numeração subsequente do mesmo.

3. Série do RPS

A série disponibilizada pela prefeitura para a emissão de RPS via Webservice é a ‘RPP’.

4. Itens por RPS

É possível informar mais de um serviço no mesmo RPS, mas somente se os serviços tenham sido efetuados no mesmo município da prestação do serviço e da incidência do ISS, bem como o mesmo país, possuir a mesma alíquota e o mesmo código do serviço, além da mesma exigibilidade de ISS.

5. Impressão do RPS

Para imprimir um RPS que ainda não foi efetivado no sistema, é necessário solicitar autorização da prefeitura. Para isso, entre em contato com o setor responsável por NFSe, e informe que o RPS foi enviado via WebService e que será convertido em NFSe. Para a impressão da NFSe, não é necessária a autorização.

6. O sistema não permite:

• Efetivar uma nota sem Tomador.

7. Cancelamento de NFS-e

Em alguns municípios atendidos por este padrão não é possível realizar o cancelamento da última NFS-e emitida, nesse caso o prestador deverá emitir uma nova nota com os dados corrigidos para então realizar o cancelamento do documento anterior.

8. Exemplo XML

Segue um exemplo de XML de envio do Padrão System, veja aqui

Padrão Memory

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

O padrão Memory é semelhante ao modelo ABRASF, porém possui diversas particularidades que requerem tratamento diferenciado. As características que integradores deverão considerar são:

• O xml de envio do RPS não possui campos para substituição, devendo esta ser realizada diretamente no sistema de nfse do município.

• Como o serviço de cancelamento através de web service não atende as necessidades do InvoiCy, não disponibilizamos cancelamento de NFS-e em nosso sistema. O usuário deverá acessar o sistema do município e solicitar o cancelamento da nota. Como é necessário que um fiscal avalie o pedido e autorize o cancelamento, o usuário precisa aguardar esta ação e posteriormente cancelar a nota no InvoiCy para que o status seja atualizado (o InvoiCy apenas atualizará o status da nota para cancelado, sem comunicar-se com a prefeitura).

• É obrigatório informar ao menos o Nome / Razão Social do Tomador para efetivar uma nota. Tomador vazio ou não informado causará rejeição do lote.

• O prestador deve estar cadastrado e habilitado no sistema online da prefeitura a inserir lotes de RPS’s. Os dados do prestador também serão validados com os dados presentes no sistema NFSE.

• É necessário informar a hash de acesso da empresa no campo Chave primária Autent. do cadastro da empresa no Invoicy. Esta informação pode ser obtida através do menu Meu Perfil > Chave de acesso Web Service no sistema da prefeitura.

• Como a nota não é efetivada no mesmo instante do envio, é necessário realizar uma consulta posterior para verificar se a nota foi efetivada, respeitando as orientações do artigo “Bloqueio do Web Service no InvoiCy“.

1. Exemplo de XML

Segue um exemplo de XML do Padrão Memory enviado ao InvoiCy NFS-e, acesse aqui.

Padrão Memory – Antigo

O padrão Memory é semelhante ao modelo ABRASF, porém possui diversas particularidades que requerem tratamento diferenciado. As características que integradores deverão considerar são:

• O prestador deve estar cadastrado e habilitado no sistema online da prefeitura a inserir lotes de RPS’s. Os dados do prestador também serão validados com os dados presentes no sistema NFSE.
• Como o serviço de cancelamento através de web service não atende as necessidades do InvoiCy, não disponibilizamos cancelamento de NFS-e em nosso sistema. O usuário deverá acessar o sistema do município e solicitar o cancelamento da nota. Como é necessário que um fiscal avalie o pedido e autorize o cancelamento, o usuário precisa aguardar esta ação e posteriormente cancelar a nota no InvoiCy para que o status seja atualizado (o InvoiCy apenas atualizará o status da nota para cancelado, sem comunicar-se com a prefeitura).
• O xml de envio do RPS não possui campos para substituição, devendo esta ser realizada diretamente no sistema de nfse do município.
• É obrigatório informar ao menos o Nome / Razão Social do Tomador para efetivar uma nota. Tomador vazio ou não informado causará rejeição do lote.
• É necessário informar a hash de acesso da empresa no campo Chave primária Autent. do cadastro da empresa no Invoicy. Esta informação pode ser obtida através do menu Meu Perfil > Chave de acesso Web Service no sistema da prefeitura.

• Como a nota não é efetivada no mesmo instante do envio, é necessário realizar uma consulta posterior para verificar se a nota foi efetivada, respeitando as orientações do artigo “Bloqueio do Web Service no InvoiCy“.

1. Natureza da Operação.

O campo de natureza da operação deverá seguir o padrão do InvoiCy NFS-e abaixo:

2. Exemplo de XML

Acesse o XML de exemplo do Padrão Memory, clicando aqui.

Padrão NF-Eletronica

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

Para utilizar o Padrão NF-Eletronica deve-se atentar para algumas particularidades.

1 Envio

1.1 Numeração

A numeração do RPS deve ser sequencial e não permite pulos, ou seja, para conseguir efetivar um novo número de RPS, os anteriores devem estar efetivados. Por exemplo, ao enviar um lote contendo os RPS 1, 2, 3, 4, 5, os RPS 1 e 2 efetivaram, porém, o número 3 rejeitou (por algum erro de preenchimento), dessa forma, o 4 e o 5 também rejeitarão, devido ao pulo de numeração. É preciso corrigir o número 3, reenviar o mesmo e, após efetivar, reenviar o 4 e o 5.

1.2 Valores

Atentar para tags de valor, a prefeitura aceita somente duas casas decimais, então caso esse número de casas após a virgula for maior o valor DEVE ser arredondado, por exemplo, valor base é de R$440,23 e minha alíquota é de 3%, então (440,23*0,03) = 13,2069 porém para o padrão NF-Eletronica os números após a virgula devem ser arredondados, então o valor a ser enviado corretamente deve ser R$13,21. Porém esse valor deve sempre possuir duas casas decimais após a virgula, esse arredondamento deve ser feito somente quando o número de casas decimais for maior que 2.

1.3 Tomador Estrangeiro

As informações do tomador devem ser preenchidas mesmo se o tomador for estrangeiro. O InvoCy assume que o tomador é estrangeiro quando as tags TomaCNPJ e TomaCPF estão vazias e o País do tomador (TomaPais) não for o Brasil, automaticamente o InvoCy interpreta que o tomador é estrangeiro.

1.4 Intermediário, itens e substituição.

No padrão NF-Eletronica não é possível adicionar informações sobre intermediários, itens e não possui substituição da NFS-e.

1.5 Envio de notas em lote

O padrão NF-Eletronica permite o envio de documentos em lote. É possível enviar várias notas para o InvoCy em uma única requisição ao Web Service, no retorno a tag DocArquivo estará alimentada em um único arquivo txt com todas as notas convertidas em Base64. A quantidade de notas por lote deve ser configurada nos Dados da Empresa.

            1.6 Natureza da Operação

Segue abaixo os códigos aceitos para o Padrão NF-Eletronica.

2 Upload do arquivo

Para efetuar o upload do arquivo junto ao sistema da prefeitura deve – se realizar a conversão da tag DocArquivo que está em Base64 para texto e salvar em um diretório o arquivo txt com os dados da nota (s). Após deve ser acessado o sistema da prefeitura e ir para o menu “Importação”, selecionar o arquivo com os dados da nota e clicar em “Criticar”, essa opção irá validar se todos os dados estão corretos, se não ocorrer erros a(s) nota(s) poderão ser importadas e convertidas para NFS-e. Segue imagem com o passo a passo da importação.

3 Retorno Prefeitura

Devido que o sistema da Prefeitura utiliza arquivos txt para a importação de notas e o mesmo deve ser feito diretamente no sistema da prefeitura, para que a nota seja efetivada no InvoCy, deve se exportar um arquivo txt do sistema da prefeitura com os dados da nota e popular a tag Arquivo e a tag ExtensaoArquivo com o arquivo convertido para Base64, após isso realizar o envio para o Web Service de envio de notas.

4 Consulta

O padrão NF-Eletronica não possui Web Service de consulta de notas, sendo assim as notas emitidas diretamente pelo sistema da prefeitura se efetivadas/canceladas não será possível disponibilizar a mesma no InvoiCy, pois não será possível consultar as informações da NFS-e.

5 Cancelamento

No padrão NF-Eletronica não é possível cancelar a nota através do InvoiCy, nele só será alterado o status da nota para cancelado, este deve ser feito diretamente no sistema da prefeitura.

6 Exemplo XML

Para visualização de um XML de exemplo para envio, clique aqui.

Para visualização de um XML de exemplo para envio com os dados exportados da prefeitura, clique aqui.

Padrão e-Governe ISS

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

O Padrão e-Governe ISS não segue nenhum modelo ABRASF, porém oferece suporte à tecnologia de Web Services. Os Web Services disponíveis são de Emissão e Cancelamento de NFS-e, não existindo Web Services para consulta. Segue abaixo as particularidades deste novo padrão:

1. Natureza da Operação

O campo de natureza da operação deverá seguir o padrão do InvoiCy NFS-e abaixo:

2. O sistema não permite:

• Informar o Intermediário do serviço.
• Substituição de RPS.
• Inutilização da Nota;

3. Número e Série do RPS

O sistema da prefeitura não leva em consideração a Série e nem o Número do RPS para realizar a emissão da NFS-e, a Série para qual a NFS-e será gerada é autorizada pela prefeitura, para tanto, deve-se verificar a Série que a prefeitura autorizou para que dessa forma possa-se utilizar a mesma no InvoiCy.

Apesar de não ser utilizado, o número do RPS continua sendo obrigatório para emissão.

4. Alíquota Especial

Existe uma regra no sistema da prefeitura, onde não é permitido informar um valor diferente de zero para a alíquota do ISS se o Prestador não for Optante do Simples Nacional e não ocorrer Substituição Tributária, quando não cumprir essas condições, a prefeitura atribui internamente à NFS-e a alíquota padrão de 3%. Portanto, quando o prestador não for Optante do Simples Nacional e não houver substituição Tributária, o valor a ser informado para a tag <ValAliqISS> deve ser 0.

Obs: Se o prestador não for optante pelo simples nacional ou se o ISS não for retido, a alíquota do ISS informada no XML não é recebido pela prefeitura.

5. Homologação

Não existe um ambiente exclusivo para homologação no padrão e-Governe ISS, o que define se a emissão ou cancelamento da NFS-e é destinada à homologação ou produção é o valor enviado em uma tag <homologacao> que é esperada nestes 2 web services, para consultar as NFS-e emitidas em homologação deve-se acessar através do menu “Notas Fiscais -> web Service – NF-e em Homologação”, o usuário será redirecionado para uma página contendo as últimas 10 NFS-e emitidas em homologação.

6. Consulta

O sistema da prefeitura não dispõe de nenhum web service para realizar consultas à NFS-e, no entanto o processamento do web Service de Emissão é síncrono, dessa forma é possível validar se a nota foi gerada com sucesso ou não através dos dados retornados por esse web service.

Para consultar os dados de uma nota fiscal, o usuário poderá acessar ao sistema web disponibilizado pela prefeitura através do menu “Notas Fiscais -> Pesquisar NF-e”, após isso será necessário informar os filtros que desejará aplicar, clicar em pesquisar e o sistema irá carregar uma grid com as notas que se enquadrem para os filtros aplicados.

7. Cancelamento

O cancelamento dos documentos é realizado através dos Web Services disponibilizados pelo InvoiCy.

8. Chave de Autenticação

A comunicação com os Web Services requerem uma “chave de autenticação” gerada no sistema da prefeitura, cada chave é única e a mesma deve ser informada no cadastro da empresa junto ao InvoiCy, para que o mesmo utilize a chave tanto na emissão e cancelamento, esta chave é responsável pelo reconhecimento do prestador no sistema da prefeitura. Para acessar ou gerar uma nova chave deve-se acessar o menu “Notas Fiscais -> Web Service – Gerar Chave Autenticação”, como apresentado na imagem abaixo:

Já no cadastro da empresa no sistema InvoiCy, deve informar o valor da chave de autenticação no campo “Chave Primária Autenticação”, de acordo com a imagem abaixo:

Veja um exemplo de XML enviado ao InvoiCy NFS-e, clicando aqui.

Padrão INFISC – Sapucaia

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

O Padrão INFISC Sapucaia não segue o padrão ABRASF. Segue abaixo as particularidades deste novo padrão:

1. Série do RPS

Para permitir a emissão de NFS-e, deve ser solicitada junto a prefeitura a liberação de uma numeração para emissão. Normalmente 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;
• Enviar o caractere & nos dados do RPS.

3. Exemplo XML

Acesse um exemplo de XML de envio, clicando aqui:

4. Optante pelo Simples Nacional

Os valores aceitos para optante simples nacional são:

Se for informado que o prestador é optante pelo Simples Nacional, o InvoiCy irá zerar alguns campos (listados abaixo), conforme instrução do manual de integração da INFISC:

• Base de cálculo
• Base de cálculo do ISS Retido
• Valor do ISS
• Alíquota ISS
• Base de cálculo do ISS

5. Canhoto de RPS

Desde setembro de 2015 está disponível no layout de recepção um novo campo RPSCanhoto. Este campo permite que na exportação da nota em PDF no sistema da prefeitura de Sapucaia do Sul seja possível imprimir um canhoto da nota, como mostra a imagem abaixo.

Controle de requisições recebidas pelo InvoiCy

Última atualização em: 19 de abril, 2016

 

Buscando melhorar a usabilidade da aplicação por parte dos usuários Parceiros e evitar problemas durante a realização de uma tarefa, seja de consulta, reenvio ou cancelamento de um documento, o InvoiCy conta com um controle das requisições recebidas, em decorrência de consumo indevido do Web Service, caracterizado por um número excessivo de conexões em um curto espaço de tempo.

Esse processo consiste em bloquear uma requisição que se repita mais de ‘N’ vezes dentro de um determinado período de tempo, pois ocorriam situações onde a mesma requisição era enviada várias vezes para o InvoiCy, o que sobrecarregava a aplicação, que não conseguia processar as requisições recebidas em um tempo aceitável. Nesses casos, normalmente o ERP está em um LOOP realizando uma tarefa (consultando, reenviando, cancelando) referente a algum documento, mas excede um número razoável de conexões em um curto espaço de tempo. O bloqueio é preventivo, para que esse loop não cause lentidão no sistema.

Para que isso não aconteça é preciso revisar/programar a integração considerando que:

• Em caso de reenvio ou consulta de documento, deve-se adicionar um “sleep” entre uma e outra conexão, de 15 segundos, por exemplo.
• Limitar o número total de consultas: se o sistema realiza uma consulta a cada 30 segundos, ele fará 20 consultas em um intervalo de cinco minutos. Se ainda assim não obtiver o retorno desejado, é importante que o sistema pare o loop de consultas, e deixe para o usuário fazer a consulta manualmente, ou agende para voltar a executar depois de um intervalo maior (2-5 minutos), realizando uma nova tentativa.
• A implementação desse controle não irá impactar na forma como o usuário integra com a aplicação, onde o mesmo poderá enviar várias vezes a mesma requisição, porém após um determinado número de vezes o InvoiCy irá bloquear e não processará as requisições recebidas. Passado o período de bloqueio, essas requisições serão processadas e enviadas. É importante destacar que o InvoiCy irá bloquear apenas a requisição que foi enviada diversas vezes, e não a empresa. E o tempo de bloqueio e a quantidade de requisições será controlada por módulo.

Porém, se o usuário não seguir as recomendações acima e mesmo após a requisição ser bloqueada temporariamente continuar enviando várias vezes essa mesma requisição, o InvoiCy irá bloquear a requisição de forma permanente, onde será necessário entrar em contato com nossa equipe de suporte para efetuar o desbloqueio da requisição.

Códigos de Retorno Cadastro de Empresa via Web Service

Última atualização em: 14 de agosto, 2019

Neste artigo iremos abordar os possíveis códigos de retorno ao realizar o cadastro de uma empresa através do Web Service do InvoiCy.

Ao realizar o cadastro de uma empresa via Web Service, você usuário poderá obter os seguintes retornos:

100 – Solicitação de cadastro recebida

Ao receber esse retorno significa que a sua empresa foi cadastrada com sucesso no InvoiCy.

101 – Falha na estrutura do XML ou campos obrigatórios não preenchidos

Nessa situação a empresa não foi cadastrada, pois algum dos dados informados não estava de acordo. O usuário receberá o código 101 juntamente com o campo que não foi informado corretamente.

103 – Falha na validação do certificado digital

Esse retorno ocorre quando há uma inconformidade com o certificado digital informado para a empresa, onde a senha pode estar incorreta, a data de validade estar vencida, ou o certificado informado não corresponder a empresa que está sendo cadastrada.

104 – E-mail do usuário é inválido

No momento de cadastrar a empresa, ao informar incorretamente o e-mail do usuário será retornado o código 104.

105 – Campos nome ou senha do usuário não informados

Se ao cadastrar a empresa não for informado corretamente as informações referentes ao nome e senha do usuário será retornado o código 105.

106 – Usuário já cadastrado

Se o usuário informado no momento de cadastrar a empresa já estiver cadastrado será retornado o código 106.

107 – Usuário e senha da caixa de e-mail não informada

Ao cadastrar uma empresa pode-se também configurar uma caixa de e-mail. Será retornado o código 107 quando o usuário e senha da caixa de e-mail não forem informados corretamente.

108 – Não foi possível conectar ao servidor de e-mail informado

Esse retorno irá ocorrer quando o servidor de e-mail informado não estiver de acordo, não possibilitando o acesso ao mesmo.

109 – Empresa Matriz não encontrada

Ao cadastrar uma Filial, quando a empresa Matriz não for encontrada irá retornar o código 109 para o usuário.

115 – A raiz do CNPJ do certificado informado difere da raiz do CNPJ da empresa! O certificado foi cadastrado com sucesso

Ao realizar o cadastro de uma empresa e informar um certificado digital que tenha sua raiz de CNPJ diferente da raiz de CNPJ da empresa cadastrada, será retornada essa mensagem apenas como um aviso, mas o cadastro do certificado será efetuado com sucesso da mesma forma.

173 – Chave de comunicação ou chave de parceiro inválida

O código 173 será retornado quando a chave de comunicação ou a chave de parceiro estiverem inválidas, retornando especificamente para o usuário qual das chaves está incorreta.