Italo Giurizzato Junior

Bom dia Nilton, Você fez alteração no componente? Os arquivos que você anexou se refere ao componente do Trunk2?

Vinicius, Favor atualizar os fontes e testar novamente.

Bom dia Vinicius, Fiz diversas correções visando resolver todos os problemas de geração do XML bem como a sua validação. O teste inicial que fiz foi usando a opção Gerar e Enviar RPS no programa exemplo. Qual opção você utilizou?

Bom dia Emanuel, A falha de schema é retornada pela SEFAZ logo após o envio ou é o componente que antes do envio já apresenta a falha? Se é um retorno da SEFAZ isso significa que o problema é nela, essa mensagem é muito comum quando é gerado o XML da NF-e segundo os manuais e notas técnicas e a SEFAZ ainda não esta preparada para o novo layout.

Boa noite Wesclei, ACBrNFe2 ??? Você ainda esta usando os fontes do repositório Trunk? Se sim, não damos mais suporte a esses fontes, somente aos fones do repositório Trunk2. Outra coisa, nenhuma SEFAZ-Autorizadora até o momento disponibilizou um web service de autorização hapto a recepcionar um lote de notas compactadas.

Boa noite, Sim, o componente imprimir o DANFE de uma nota Denegada, o que precisa verificar se logo acima do protocolo esta escrito: Protocolo de Denegação em vez de Protocolo de Autorização.

Boa noite Marcelo, O valor aleatório deve ser atribuído a cNFSe.

Boa tarde seberi, Se o componente não esta acrescentando o protocolo ao XML isso significa que ao realizar a consulta você esta consulta através da chave. Para que o componente atualize o XML ao realizar a consulta, primeiro o XML tem que estar assinado, segundo você deve carregar o XML ao componente, terceiro executar a consulta, quarto o componente tem que estar configurado para salvar em disco.

Boa tarde Fernando, Tenha em mente o seguinte: O componente possui 3 métodos de envio: Enviar, Gerar e EnviarSincrono. No caso do provedor Ginfes só podemos usar o método Enviar, pelo simples motivo que o provedor não disponibilizou no seu Web Services os outros 2. É preciso saber no caso do provedor Goiania quais dos 3 métodos foram implementados. Se estiver correto a unit pnfsNFSeG.pas esse provedor não tem o método EnviarSincrono. Outra coisa segundo o arquivo INI do provedor nota-se que foi informado somente o layout dos métodos: ConsNFSeRps e Gerar. Sendo assim você tem que usar o método Gerar e não Enviar. Favor entrar em contato com o provedor para saber exatamente quais são as funcionalidades disponibilizadas no Web Service.

Marcelo, Acho que você esta invertendo as coisas. o valor de cNFSe tem que ser um numero aleatório e que será utilizado para compor a chave do NFS-e. e não o contrario.

Leo, Esse erro esta ocorrendo na sua aplicação ou no programa exemplo? Se é na sua aplicação, por favor veja que no programa exemplo existe 6 configurações novas referentes ao Emitente, você deve incluir elas na sua aplicação, mais precisamente na rotina que configura o componente.

Boa tarde Rafael, Favor atualizar os fontes, note que fiz uma alteração no INI do provedor.

Boa tarde Vinicius, Favor atualizar todos os fontes e testar novamente. Note que o arquivo INI do provedor SP sofreu alterações.

Boa tarde Leandro, Realizamos diversas alterações, inclusive hoje, favor atualizar todos os fontes de todas as pastas e realize novos testes.

Boa tarde Leo, Na propriedade NumeroSerie atribua uma string vazia.

Bom dia Cristiane, O ACBrNFSe - Trunk2 já possui 58 provedores implementados, sendo que o ISSNet já foi testado por um colega do fórum e esta funcionando 100%, já o Thema é preciso testar.

Fernando, Eu preciso do arquivo soap de envio, você tinha antes anexado o soap de retorno e esse agora nada mais é o arquivo de envio mas sem o envelope soap, para mim isso não serve.

Fernando, Anexa o envio, por favor.

Bom dia Marcelo, Notei que no seu XML esta faltando o conteúdo do campo cNFS-e, pode ser esse o problema do erro ao tentar validar o XML. Segundo, conforme o arquivo INI desse provedor somente o lote é assinado, dai o fato das propriedades XMLOriginal e XMLAssinado estão com o XML sem a assinatura.

Bom dia Nilton, Post como anexo os XML gerados para que eu possa analisar. Fiz uma alteração, favor atualizar os fontes e testar novamente.

Bom dia Fernando, Primeiramente peço que não post o conteúdo do XML como parte do texto e sim anexe o mesmo. Segundo, vamos a mensagem de erro retornada: O servidor não reconheceu o valor do cabeçalho HTTP SoapAction. Por favor, configure o componente para salvar os arquivos soap: Configuracoes.WebServices.Salvar := True. Realize um novo teste de envio e anexe os arquivos gerados cujo nome possui a palavra soap (*-soap.xml).

Bom dia a todos, Marco, se o componente ACBrNFSe esta funcionando é graças a todos vocês que realizam os testes e apontam onde estão os problemas. Eu apenas tento interpretar o que esta ocorrendo e procuro implementar a correção da melhor forma possível. Nem sempre a solução é a melhor possível e chega as vezes gerar efeitos colaterais, mas faz parte, no final depois de escovar os BITs tudo se ajeita.

Bom dia Bruno, Conforme a Nota Técnica 2015/004 versão 1.03 que trata sobre o Combate a Pobreza - página 2 temos uma tabela com regras de validação e uma delas é a Rejeição 746 que diz: Se tomador do serviço for emitente de CT-e (verificar CNE) e diferente de Remetente ou Destinatário: - Rejeitar se o tipo de serviço informado for Normal (tpServ=0) Se o seu CT-e foi rejeitado significa que o campo tpServ (#26) é igual a 0 (normal) e o toma (#38) é igual a 4 (outros) e os campos #39 até #56 contem os dados do Emitente e os dados do Remente e do Destinatário não são iguais do Emitente.. O seu CT-e possui 3 atores diferentes envolvidos: Emitente (transportadora) o Remente e o Destinatário da carga, mas é informado que o Tomador, ou seja, quem vai pagar pelo frete é a transportadora, então quer dizer que o transporte é uma cortesia?

Boa noite Hugo, Você vai ter que ter um segundo ACBrCTeServicos.INI com as novas URLs e enviar para os seus clientes e pedirem a eles a realizar a troca na data de seu inicio.

Boa noite Rafael, A solicitação do PIN ocorre toda vez que a aplicação necessita do certificado, como por exemplo: Assinar, Enviar, Consultar, .... Ou assim que o PIN é informado ele volta a solicitar o PIN novamente? O meu cliente utiliza de um certificado A3 e ele pede somente uma vez o PIN depois só se a aplicação for encerrada, caso contrario não. O componente é criado e destruído toda vez que você vai executar uma ação?