Italo Giurizzato Junior

Boa noite Lucio, Já inclui na minha lista de tarefas. TK-2807

Boa noite Celso, Essa URL é de homologação ou de produção?

Olá pessoal, Quero comunicar o nascimento do mais novo membro da família ACBr. Estou falando do ACBrGTIN. Esse componente tem como objetivo realizar uma consulta na SEFAZ, onde é informado somente o GTIN do produto a ser consultado (também conhecido como código EAN) e temos como resposta informações cadastradas pelo "Dono da Marca" na GS1. Essas informações podem ser: o tipo do GTIN (que pode ser 8, 12, 13 ou 14) a descrição do produto o código NCM código do CEST. Infelizmente nem sempre teremos um retorno completo. Isso porque nem todas as empresas "Dono da Marca" cadastram os seus produtos na GS1 e muitas que cadastraram não autorizaram a divulgação dos dados. Neste caso podemos ter as seguintes rejeições: 9494: GTIN inexistente no Cadastro Centralizado de GTIN (CCG); 9495: GTIN existe no CCG com situação inválida. Solicitar ao dono da marca que entre em contato com a GS1; 9496: GTIN existe no CCG, mas dono da marca não autorizou a publicação das informações. Entrar em contato com o dono da marca; 9497: GTIN existe no CCG com NCM não cadastrado; 9498: GTIN existe no CCG com NCM inválido; Dica de uso do componente: Utilize ele ao cadastrar novo ou atualizar um produto na sua aplicação. Nunca, jamais mesmo, use o componente no momento da venda. Consta na NT 2022/001 versão 1.00 referente ao WS de Consulta do GTIN (página 6) a seguinte informação: Serão mantidos controles para identificar as situações de “uso indevido”, no consumo excessivo do Web Service em um curto espaço de tempo. As novas tentativas poderão ser rejeitadas com o erro “656–Rejeição: Consumo Indevido” Informação Importante: A Equipe ACBr esta trabalhando para disponibilizar o programa exemplo, bem como o pacote para o Lazarus e uma nova versão do ACBrInstall que permite a instalação no Delphi do novo componente: ACBrGTIN.

Boa tarde Celso, O provedor Fisco esta implementado sim no componente ACBrNFSeX, mas a cidade não consta no arquivo ACBrNFSeXServicos.ini Para incluir ela precisamos das URLs de homologação e de produção.

Boa tarde Lucio, Favor atualizar os fontes e faça novos testes.

Boa tarde, Já esta no SVN.

Bom dia Helder, Acredito que o componente ACBrGTIN ainda não tenha sido incluído no Instalador, sendo assim a sua instalação deverá ser feita manual. Caso você tenha dificuldades ou receito em fazer uma instalação manual, por favor aguarde mais um pouco que será disponibilizado uma nova versão do instalador que contempla o componente ACBrGTIN.

Bom dia Rafael, A impressão dessa informação esta prevista no manual? Outra coisa, pela imagem não teria espaço suficiente para imprimir essa informação.

Bom dia Joemil, Quanto a troca das URLs vamos seguir pela outra postagem. Vamos deixar essa para o problema do nosso amigo Renato. Bom dia Renato, Consegui alguma informação sobre o problema de usuário não autorizado?

Bom dia Joemi, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2801 Você chegou a entrar em contato com o provedor se essa alteração esta sendo feita em todas as cidades atendidas por eles?

Bom dia, Sapucaia do Sul/RS também se utiliza da versão 2.03? Tem alguma cidade que se utiliza da versão 2.01?

Boa tarde Rogerio, Esse erro provavelmente é de configuração. Boa tarde Brisola, O seu cliente é de Sorocaba? Pois aqui estamos tratando o problema do provedor que atende a cidade de Sorocaba. Se não for favor criar uma outra postagem. Desde já obrigado pela compreensão.

Boa tarde Wallace, Pelo componente novo ACBrNFSeX tenho o seguinte retorno. Método Executado: Enviar Lote Síncrono Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : True Erro(s): Código : E259 Mensagem: CNPJ/CPF não encontrado na base de dados. Correção: Confira o número do CNPJ/CPF informado. Caso esteja correto, o prestador do serviço não está inscrito no município.

Boa tarde Renato, Muito obrigado pela colaboração, ainda hoje estarei enviado para o SVN. Quanto a esse problema no ambiente de produção vai ser necessário entrar em contato com a prefeitura ou provedor para saber se requer uma usuário e senha especifica para este ambiente.

Boa tarde Marcus, Muito obrigado pela colaboração, ainda hoje vou enviar a alteração para o SVN.

Boa tarde Renato, Neste tópico esta sendo tratado a troca de URL do provedor Coplan. Por se tratar de outro provedor, favor criar uma nova postagem, desde já muito obrigado pela colaboração e compreensão. Boa tarde Marcus, As alterações estão sendo feitas somente no novo componente ACBrNFSeX.

Olá Pessoal, Foi publicado a versão 1.02 da NT e o que foi alterado foi simplesmente o código da rejeição e a descrição da mesma. Antes era: Rejeição 831: CFOP inválido, não informar 5932 ou 6932 para operações internas. Agora é: Rejeição 908: CFOP inválido, não informar 5932 ou 6932. Fonte: http://www.cte.fazenda.gov.br/portal/informe.aspx?informe=101

Rogério, Verifica se não tem nenhuma unit que faz parte do componente com uma bolinha vermelha, caso afirmativo delete a unit, atualize novamente, reinstale e compila novamente o programa exemplo e por fim faça novos testes.

Douglas, A minha sugestão de você olhar o MOC é que ele apresenta os cálculos e mostras em quais campos devem ser atribuídos os resultados. Infelizmente não tenho nenhuma rotina para anexar que você poderia tomar como base.

Boa tarde Douglas, Pega o MOC - Manual versão 7.03 - Visão Geral da NF-e, item 9. Sistemática de Cálculo em Operações Interestaduais (EC 87/2015) Quem sabe lhe ajuda a encontrar o problema. Veja o que diz a regra referente a rejeição 695: Informado indevidamente o grupo de ICMS para a UF de Destino (tag:ICMSUFDest): - Não é operação Interestadual (idDest<>2) ou - Não é operação com Consumidor Final (indFinal<>1) ou - Não é operação com Não Contribuinte (indIEDest<>9) ou - Operação de prestação de serviços (existe tag “ISSQN”) ou - Operação com combustível (tag:comb) derivado de petróleo: código ANP diferente de: 820101001, 820101010, 810102001, 810102004, 810102002, 810102003, 810101002, 810101001, 810101003, 220101003, 220101004, 220101002, 220101001, 220101005, 220101006, 560101001, ou - Data de Emissão anterior a 01/01/2016. Exceção 1: A critério da UF a regra de validação acima não se aplica na devolução (finNFe=4) por NFe Avulsa com IE do Emitente=ISENTO. Exceção 2: A regra de validação acima não se aplica se informada UF do local de entrega (tag: entrega/UF) diferente da UF do emitente (tag: emit/enderEmit/UF). Exceção 3: A regra de validação não se aplica, em produção, para Nota Fiscal com data de emissão anterior a 01/07/2016. (NT 2015.003)

Rogério, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde Marcos, Isso pode ser uma sobrecarga no webservice deles. Peça para os seus clientes abrir um protocolo na prefeitura expondo o problema, desta forma a prefeitura vai forçar o provedor resolver o problema. Quanto mais empresas que emite notas de serviço, protocolarem uma reclamação na prefeitura, mais rápido o problema será resolvido.

Boa tarde Rogerio, Já inclui na minha lista de tarefas. TK-2793

Boa tarde Rogério, Neste caso eu aconselho você usar o Fast Report em vez do Fortes Report. Pois com o Fast você pode criar um FR3 exclusivo para atender as suas necessidades.

Boa tarde Francelin, Muito obrigado pela colaboração, já fiz a alteração e enviei para o SVN. Se você ainda esta usando o componente antigo ACBrNFSe. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não esta mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/