Italo Giurizzato Junior

Boa tarde Fabio, Seria interessante neste caso termos o XML de retorno do envio que consta o primeiro DisgestValue e o de retorno a consulta. Desta forma vamos saber quem esta gerando o DisgestValue errado.

Boa tarde a todos, Em primeiro lugar quero reforçar que o componente ACBrNFSe disponibilizado no Trunk2 não esta funcional. Isso não significa que nada impede de vocês realizarem testes, mas não existe a garantia que vai funcionar. Foi criado um arquivo INI chamado cidades e neste foi colocado todas as cidades que o componente ACBrNFSe (trunk) atende. Exemplo: [1600303] Nome=Macapá UF=AP Provedor=Fiorilli Ao configurar o componente com o código IBGE da cidade o componente se utiliza desse arquivo para descobrir qual é o provedor, que neste exemplo é o Fiorilli. De posse dessa informação o componente busca um arquivo INI que tenha o nome do provedor. Se vocês derem uma olhada na pasta ...\Fontes\ACBrDFe\ACBrNFSe vão notar que somente os provedores: 4R, Ginfes, Fiorilli e os genéricos ABRASFv1 e ABRASFv2 foram criados. O ACBrNFSe (trunk) atendia por volta de 60 provedores, isso significa que falta criar os demais, ou seja, 55. Como criar o arquivo INI do provedor: 1. tome como base os que já existam; 2. abra a Unit do respectivo provedor para extrair dela as informações necessárias para a montagem do respectivo INI. É trabalhoso, sim, mas só dessa forma será possível realizar os testes. Eu não tenho condições de criar todos, pois sou funcionário de uma empresa e não posso passar as 8 horas trabalhando com o componente, tenho os meus afazeres aqui na empresa também.

Boa tarde Osmar, Se após o envio o banco de dados não for atualizado acusando que a SEFAZ retornou Status 100 ou se ocorreu um erro de Timeout, a primeira coisa a ser feita é realizar uma consulta e não enviar novamente. Ao consulta se a SEFAZ retornar que a nova não consta no banco de dados, ai sim você envia novamente, pois fica confirmado que o problema ocorreu no envio. Por outro lado se a SEFAZ retornar o protocolo de autorização, alem de ficar claro que o problema foi no retorno o XML vai passar a ter o protocolo de autorização desde que o componente esteja carregado com a nota em questão. Lhe garanto que se você tratar dessa forma os problemas de notas em duplicidades vão acabar.

Boa tarde Dércio, O valor da Base de Calculo esta sim sendo impresso o que é impresso é o valor do ICMS ST, no quadro dos itens.

Boa tarde Heto, O campo cSitConf é do método ConsultaNFeDest o método DistribuicaoDFe esse campo não existe. O que existe é um campo chamado cSitNFe que retorna: 1=Uso Autorizado ou 2=Uso Denegado. Quando uma nota é enviada na SEFAZ podem ocorrer 3 situações: 1. A nota ser rejeitada, neste caso a nota não é armazenada no banco de dados da SEFAZ, isso lhe permite que você faça a correção e envie ela novamente (com o mesmo numero e série). 2. A nota ser autorizada, neste caso a nota é armazenada no banco de dados da SEFAZ e a mesma retorna o protocolo de autorização. 3. A nota ser denegada, neste caso a nota é armazenada no banco de dados da SEFAZ e a mesma retorna o protocolo de denegação. Obs: uma nota denegada não pode ser corrigida e enviada novamente. Rejeição significa que a nota contem erros e estes precisam ser corrigidos para que a SEFAZ possa aceita-la. Denegação significa que a nota não contem erros, mas a SEFAZ se recusa a autoriza-lo por algum problema do emitente/destinatário possuir com o Fisco.

Boa tarde Robinho, Esse XML nem sequer esta assinado. Não deixe a cargo do usuário solicitar a geração do XML, depois a sua assinatura, depois a sua validação e por fim o envio. Na minha aplicação é apresentado a lista de conhecimentos não enviados, o usuário tem que selecionar os que deseja enviar para SEFAZ e depois clicar no botão [Emitir]. Ao clicar no botão será lido do banco de dados os dados de todos os conhecimentos selecionados, será ADD um CT-e no componente para cada conhecimento, depois é executado o método Validar, pois este verifique se o CT-e esta assinado ou não, como não estão automaticamente o método assinar é executado o XML é salvo em disco e a validação é realizada, por fim o método Enviar é executado. O método Enviar se encarrega de montar o lote com todos os XML gerados, assinados e validados, o lote é enviado a SEFAZ. Se tudo estiver correto o retorno dos protocolos de autorização é retornado da SEFAZ e o componente se encarrega de anexa-los aos XMLs. Desta forma tenho a absoluta certeza que o XML será gerado, assinado, validado, enviado e protocolado, com uma simples ação do usuário.

Boa tarde Marcelo, No consultar NFSe por RPS notei pelo retorno que há necessidade de manter o componente carregado com o RPS que foi enviado, para que o componente extrai alguns dados do mesmo para realizar a consulta. Já o consultar NFSe não descobri ainda o motivo do erro. Por favor atualize os fontes e teste novamente o Consulta NFSe por RPS, mantendo o componente carregado com o conteúdo do XML do RPS.

Bom dia Osmar, Se você tem problemas de duplicidade de NF-e, o problema esta na sua aplicação e não no componente. A sua aplicação não esta gerenciando de forma correta a numeração das notas.

Bom dia Paulo, Pela sua postagem o XML não esta sendo enviado e sim esta sendo rejeitado pelo validado interno. O que esta ocorrendo é um erro de validação antes do envio, e não uma rejeição da SEFAZ ao processar a sua nota e detectar informações incorretas. Já fiz a correção no componente no que se refere a essa nova TAG, para que utiliza o componente o problema foi sanado. Vamos aguardar o pessoal disponibilizar uma nova compilação do ACBrMonitor Plus.

Bom dia, Segundo a Nota Técnica 2013/005 versão 1.22 - página 20 temos: 1. o grupo <dest> é opcional para a NFC-e, sendo assim nenhum dado do destinatário não precisa ser informado. 2. os campos <CNPJ> / <CPF> e <indIEDest> são obrigatórios, por outro lado o <xNome> e <IE> são opcionais, sendo assim se você deseja informar o nome do cliente será obrigado a informar o CNPJ ou o CPF do mesmo mais o indIEDest. Neste caso o grupo <dest> será gerado no XML. 3. Note que o grupo <enderDest> é opcional para a NFC-e. Esta vendo como é bom baixar as nota técnicas e reservar um tempinho para ler, acabamos descobrindo uma série de coisas.

Bom dia Marcelo, Se você mantem os seus fontes atualizados diariamente, deve ter notado que enviei uma atualização do ACBrNFSe (repositório Trunk) na sexta feira dia 11, isso comprova o que o Daniel disse, "não vamos deixar na mão". Quanto as URLs no caso dos fontes do repositório Trunk basta abrir a unit ACBrNFeUtil e procurar pelas function GetURLRS e GetURLSVRS e comparar as URLs com o documento publicado. Já no Trunk2 temos um arquivo INI chamado ACBrNFeServicos, basta procurar pelas seções [NFe_RS_P], [NFe_RS_H], [NFe_SVRS_P] e [NFe_SVRS_H] e comparar as URLs com o documento. Eu não entendo qual é a dificuldade em se fazer isso para descobrir se o componente esta ou não já utilizando das novas URLs. No caso da NFS-e a configuração do provedor esta sendo através de arquivo INI, já disponibilizei para os provedores: 4R, Fiorilli, Ginfes e os genéricos ABRASFv1 e ABRASFv2. O relacionamento entre as cidades e os provedores esta no arquivo INI chamado Cidades. Se conseguíssemos colocar o layout do XML do RPS em arquivo INI, acredito eu que o componente ficaria muito flexível para os provedores que não seguem o layout ABRASF.

Boa noite Marcio, Essas novas URLs foram atualizadas por mim no dia 01/05/2015. Portanto se você atualizou os seus fontes depois da data acima lhe garanto que sim, as suas NFC-e estão sendo enviadas se utilizando das novas URLs.

Boa noite a todos, As URLs publicadas pela SEFAZ-RS, no dia 30 de abri foram disponibilizadas no dia 01/05 tanto nos fontes do trunk quanto no trunk2. Isso já foi dito por mim em diversos post. Portanto faz 4 meses que fiz a atualização dos fontes e disponibilizei nos repositórios. Gostaria de entender qual é a preocupação. Quanto a NFS-e estou estudando uma forma de flexibilizar o componente o máximo possível. Existem vários usuários que arregaçam as mangas e põe a mão na massa, mas infelizmente outros nem sequer são capazes de ler uma nota técnica de 6 páginas. Desculpe o desabafo e como o Daniel disse o código esta ai, abra-o, estude-o e nos ajude.

Boa tarde, O ACBrNFe é um emissor de NF-e e NFC-e que segue 100% os manuais e notas técnicas publicadas pelo ENCAT no Portal Nacional da NF-e. Portanto não vejo com bons olhos ficar inserido dezenas de IF em seu código para corrigir o que os outros fazem de errado. Peça a seu cliente que entre em contato com o fornecedor dele, para que este entre com o desenvolvedor do emissor de NF-e para que sejam feitas as devidas correções.

Boa tarde Hasa, Não, só esta sendo implementado no ACBrMonitor Plus. Se eu estiver errado, por favor Régys me corrija.

Boa tarde, Vamos a pergunta clássica: Todos os fontes de todas as pastas estão atualizados?

Boa tarde Gabriel, Por favor atualize e teste novamente.

Boa tarde Adriano, O CNPJ do certificado tem que ser o mesmo do RPS e do lote e tem mais, podem haver a necessidade de cadastrar o contribuinte para que o mesmo possa usar o web services para emitir a NFS-e. Ao informar o CNPJ não coloque os caracteres de formatação, ou seja, pontos, traços, barras, etc.

Boa tarde a todos, Régys, estou desconfiado que esse erro de index deve estar sendo gerado no momento da leitura do arquivo de retorno do envio do evento. Com o Monitor compilado será difícil descobrir a origem do mesmo, mas realizando um debug acredito que vamos achar.

Boa tarde Mateus, Ai que esta o problema, esse endereço de consulta se refere ao mesmo ambiente para onde a nota foi enviada? Se você enviou para o ambiente de homologação, ao tentar realizar uma consulta no ambiente de produção vai ter como resposta que a chave não existe.

Boa tarde Eventon, Por favor post como anexo a unit que você alterou, para que possamos avaliar e caso esteja tudo OK enviarmos para o repositório.

Boa tarde Robinho, Esses arquivos também são de envio e de retorno, só que estão envelopado. Esses arquivos só são salvos se você atribuir o valor True a propriedade: Configuracoes.WebServices.Salvar. Portanto para que os mesmos não sejam salvos basta atribuir o valor False a propriedade acima.

Bom dia Mateus, Você esta consultando no mesmo ambiente que a nota foi enviada?

Bom dia Robinho, Por favor atualize todos os fontes e compile a aplicação com o Build. Foi enviado uma alteração esta semana para o repositório. Agora ao atribuir o valor False a propriedade: Configuracoes.Geral.Salvar os arquivos XMLs de envio e de retorno não serão salvos em disco. Por outro lado para salvar os arquivos com validade jurídica devemos atribuir o valor True a propriedade: Configuracoes.Arquivos.Salvar. Realize testes e nos report algum comportamento fora do esperado.

Bom dia Daniel, Me parece que alguém do fórum tinha implementado o respectivo comando e postado aqui mesmo no fórum.