Italo Giurizzato Junior

Boa tarde a todos, O acesso ao webservice esta normal, o problema é quanto ao processamento das requisições. Se o servidor deles não esta conseguindo dar conta do recado não tem nada o que podemos fazer do nosso lado. A não ser aumentar o valor da propriedade de configuração: Timeout

Boa tarde Juliano, Em vez de informar o código completo, ou seja, 4217204 informe somente o código do município: 17204, uma vez que 42 se refere ao código da UF.

Boa tarde Jean, Favor atualizar todos os fontes de todas as pastas e reinstale os componentes através do ACBrInstall_Trunk2. Note que fiz uma alteração no arquivo INI do provedor Fiorilli.

Boa tarde a todos, Maiquel, o que o igmaster deseja é enviar o evento de Encerramento de um MDF-e - Manifesto de Documentos Fiscais Eletrônicos, portanto não tem nada haver com a Manifestação do Destinatário e muito menos com NF-e. igmaster, somente o emitente do MDF-e é quem pode enviar o evento de Encerramento, foi você que emitiu o MDF-e?

Visulizar Arquivo NFS-e Presente e Futuro Por: Italo Jurisato Junior e Rafael Teno Dias Autor Italo Jurisato Junior Enviado 13-11-2018 Categoria Dia do ACBr 1a edição

Boa tarde Luiz, Se estava funcionando e parou de uma hora para outra, o problema pode estar no webservices deles. Já entrou em contato com a prefeitura?

Boa tarde Adilson, Você esta com todos os fones de todas as pastas atualizados? Antigamente cada componente possuía as suas próprias rotinas referente a certificados, assinatura do XML e validação do mesmo. Agora todas essas rotinas estão concentradas nas units cujo nome começa com ACBrDFe. Portanto se funciona para um tem que funcionar para todos. Verifica a configuração do componente, pode ser que no caso do CT-e tem algo a mais na configuração em relação a do MDF-e (por exemplo).

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Robério, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Hugo, Mude a configuração para libCapicom ou libCapicomDelphiSoap.

Boa tarde Braz, Por favor leia a regra de negócio G46 que se encontra na página 42 do Manual do CT-e versão 3.00

Bom dia Robério, Desculpe mas o seu arquivo esta muito desatualizado. Favor atualizar todos os fontes de todas as pastas, reinstale os componentes usando o ACBrInstall_Trunk2. Depois altere o arquivo Cidades.ini e anexe novamente. Desde já muito obrigado pela compreensão e colaboração.

Fernando, Neste caso se o CT-e possui 10 notas ele vai realizar a consulta 10 vez em um curto espaço de tempo, correto? E se na medida que o usuário vai informando os dados da nota, já chama essa consulta? Faz com que seja solicitado logo de inicio a chave da nota, em seguida faz a consulta, se estiver cancelada, uma mensagem é apresentada e solicita a próxima nota caso tenha. Desta forma os dados da nota cancelada nem vai para o banco de dados e acredito que com isso acaba gerando um intervalo de tempo maior entre uma consulta e outra e consequentemente evitando a rejeição por consumo indevido.

O que você esta atribuindo a: IdentificacaoRps.Tipo ? Se atribuir o valor trNone o grupo <Rps> que mencionei não será gerado.

Fernando, Pelo que entendi a transportadora sequer recebe o XML da NF-e referente a carga que vai transportar, correto? Logo tudo se baseia no DANFE. Em qual momento você roda a rotina que consulta a nota, a medida que lança as notas ou quando vai alimentar o componente?

Bom dia Hugo, Me parece que os seus fontes estão desatualizados. Favor atualizar todos os fontes de todas as pastas, reinstale os componentes usando o ACBrInstall_Trunk2. O seu arquivo INI não confere com o que esta no repositório.

Bom dia a todos, Notem que no XML dito como valido possui logo no inicio o grupo <Rps> dentro do grupo <InfDeclaracaoPrestacaoServico> já o outro não possui.

Bom dia Fernando, Não sei se resolve o problema, mas acredito que minimiza ele. O emitente da NF-e caso venha cancelar uma nota, deve sempre enviar imediatamente o arquivo *-procEventoNFe.xml tanto para o cliente quanto para a transportadora, para que ambos saibam que a nota foi cancelada. O arquivo XML mencionado acima contem o pedido de cancelamento bem com o protocolo retornado pela SEFAZ atestando o cancelamento da nota.

Bom dia Warley, Revisei todos os fontes, não consigo entender o motivo de não mostrar a rejeição.

O que podemos fazer é escrever as unit referentes aos novos eventos. Para esses eventos fazermos que o XML seja gerado e assinado, como não esta disponível o Schema desses novos eventos comentamos a linha que chama o Validar. Conto com a ajuda de todos, desta forma a implementação dos novos eventos bem como os ajustes nos eventos que já existem fica muito mais rápido.

Boa tarde Joceandro, Muito obrigado pela colaboração. Já enviei para o repositório os schemas e uma alteração no componente criando o enumerador ve02_05_00. Pelo que pude ver, temos alguns eventos novos, isso significa que devemos criar para esses eventos units como foi criado para os demais.

Boa tarde, Eita mais eventos, essa coisa não tem fim. Tenho o manual com o layout dos eventos, e os Schemas (arquivos XSD) para que o XML seja validado antes do seu envio, já foi publicado?

Boa tarde Douglas, Notei que você não informou o numero da nota a ser consulta. Já a criação das pastas acredito que é devido da falta de configuração com relação ao path onde deve ser salvo os XMLs.

Bom dia, Pela imagem que você anexou diz que a mensagem não esta assinada ou seja o XML não esta assinado. Você utiliza o componente ACBrNFe? Pode anexar o XML da NF-e que esta tentando enviar e que ocorre o problema?