Italo Giurizzato Junior

Boa tarde Clayton, Depois que você copiou as DLLs para a pastas do executável removeu da pasta System? Pode ser que tenha alguma DLL (desatualizada) perdida que a sua aplicação ou o Windows esteja usando em vez da correta.

Juliano, O provedor Betha possui dois webservices, um segue a versão 1 do layout da ABRASF e outro segue a versão 2. Esse que ocorreu erro de estrutura pode ser de uma versão que você esta enviado para o webservice de outra versão. É preciso entrar em contato com esses cabeçudos e perguntar para eles qual é o código correto que tem que ser informado no XML. Se te passarem o mesmo código que já esta sendo informado, então fica claro que existe um erro no webservice.

Boa tarde a todos, Um detalhe importante, o SubstituirNFSe são dois processos em um. A substituição consiste em enviar um RPS que vai gerar uma nova nota, mas o pedido de cancelamento de uma outra nota. Em resumo essa nova nota vai substituir a que será cancelada. Aproveitando fiz algumas correções nos fontes do componente, favor atualizar, reinstalar e façam novos testes.

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.