Italo Giurizzato Junior

Bom dia, Favor configurar o componente para salvar os arquivos soap. Configuracoes.webservices.salvar := True; Faça um novo teste e anexe os arquivos:*-ped-cad-soap.xml para que possamos analisar.

Bom dia Francisco, Altere o valor de SSLXmlSignLib para xsXmlLib2 e o valor de SSL Type para LT_TLSv1_2.

Bom dia Eduardo, Já tentou retirar do DPR e colocar no Form principal do seu projeto? uses (...), MidasLib;

Bom dia Lucas, Quem é o autor dessa consulta, o emitente ou o destinatário da mercadoria? O emitente tem por obrigação legal possuir os XMLs assinados e com o protocolo de autorização guardados pelo prazo legal. Por outro lado o destinatário tem a sua disposição um webservice chamado DistribuicaoDFe onde ele pode obter uma relação (resumo) das notas emitidas contra o seu CNPJ. Lembrando que esse webservice guarda somente as notas dos últimos 3 meses. Existem várias postagem no fórum que trata sobre esse assunto, vale a pena realizar uma pesquisa, você vai encontrar um material farto com dicas e fragmento de código.

Boa tarde Francisco, Na sua aplicação tem algo do tipo: ACBrUtil.WriteToTXT( PathWithDelim(ExtractFileDir(application.ExeName))+'temp.xml', ACBrUtil.ConverteXMLtoUTF8( RetWS ), False, False); Se sim, remova.

Boa tarde Eduardo, Basta declarar a unit MidasLib no uses do form principal do seu projeto.

Boa tarde, A partir do momento que o XML foi gerado, assinado, enviado e a SEFAZ respondeu não é o caso dos seus Schemas estarem desatualizados. No componente você atribuiu o valor ve400 a propriedade de configuração VersaoDF?

Boa tarde Roger, Até onde sei o *-nfedfe.xml só é gerado se você carregar o componente com o XML referente a nota que será consultada e depois executar o método Consultar e se a nota em questão tiver eventos vinculados a ela. Pelo que me recordo não se faz necessário atribuir o valor true a propriedade AtualizarXMLCancelado. Como dito anteriormente, se você entrar no site da SEFAZ e baixar o XML de uma nota e esta possuir eventos vinculados o XML que será baixado tem o mesmo layout do *-nfedfe.xml Logo reproduzimos esse XML no componente.

Henrique, Pelo que andei notando quando o componente é configurado com o libCapicom o grupo <Signature> é acrescentado antes da tag de fechamento </Pedido> que por sinal é a posição correta. Mas quando o componente é configurado com o libWinCrypt o grupo <Signature> é acrescentado antes da ultima tag do XML, ou seja, tag de fechamento </CancelarNfseEnvio>, ficando desta forma incorreto. Analisando os fontes notei que a rotina Assinar do libCapicom leva em consideração o conteúdo de um parâmetro chamado docElement cujo conteúdo é: Pedido></CancelarNfseEvento, isso instrui a rotina a incluir o grupo <Signature> antes dessa sequencia de tabs. Por outro lado a rotina Assinar do libWinCryot não leva em consideração o conteúdo do parâmetro docElement, levando em conta apenas a última tag do XML. Por favor realizem testes com o Capicom e peço que tenham mais um pouco de paciência, pois estou em busca de uma solução definitiva.

Boa tarde Rafael, Esse XML é o RPS, o cabeçalho é acrescentado na montagem do lote, pois o lote pode conter até 50 RPS mas o cabeçalho é um só. Configure o programa exemplo para salvar os arquivos Soap. Configuracos.webservices.salvar := True; Ao enviar um Lote de RPS através do método Enviar será gerado um arquivo chamado: *-env-lot-soap.xml, é este que você tem que enviar para eles analisarem. Esse arquivo é o que é enviado para o webservice, ele contem o cabeçalho bem como a lista de RPS.

Boa tarde a todos, Desfiz a alteração anterior. Me diz uma coisa, qual é o valor que vocês estão atribuindo a SSLLib?

Fiz uma alteração, favor atualizarem os fontes e façam novos testes.

Joceandro, Tudo bem que o A3 tem 3 anos de validade e o A1 tem apenas 1 ano e talvez dentro de 10 anos gasto com o A1 seja maior que o gasto com o A3. Mas vamos lá, o A1 é um arquivo que é instalado no Windows, na verdade nem precisa e você pode carregar o conteúdo do certificado para dentro do banco de dados. Isso simplifica muito, pois não há necessidade de instalar em várias maquinas, uma vez que o banco de dados esta no servidor. Sem mencionar a segurança que isso traz. O componente ACBreSocial lhe possibilita isso. Um usuário "mané" nem vai saber que para transmitir o e-Social se faz necessário de um certificado digital (que é a assinatura do dono da empresa), uma vez que ele esta instalado na maquina ou se encontra no banco de dados. Já o A3 é visível, pois ele pode ter um formado de cartão de credito que fica inserido em uma leitora que por sua vez esta conectado a maquina. Se o estrupício não conectar corretamente o cartão ou o cabo da leitura na maquina, pronto a coisa não funciona. E como você sabe curiosidade mata, ainda por cima se o cerificado A3 for no formato Token (pen-drive). Pergunte a esses clientes insistentes se eles confiam cegamente em todos os funcionários. Pergunte também se eles desejam segurança ou vulnerabilidade.

Kleberson, Favor atualizar os fontes. Não atribua nada aos campos tpFretamento e dhViagem. A alteração que fiz é para ele não gerar o grupo <infFretamento> a não ser que seja atribuído os valores tfEventual ou tfContinuo ao campo tpFretamento. Deixei o campo dhViagem opcional, logo só deve ser gerado caso seja informado uma data ao respectivo campo.

Kleberson, Vou verificar e disponibilizar a correção. Por favor aguarde.

Roger, A ideia do arquivo *-nfedfe.xml é conter o XML assinado e com o protocolo de autorização e a lista que eventos vinculados a nota. Se a nota foi cancelada vai conter somente o evento de cancelamento. Esse layout de arquivo não esta documentado no manual e nem nota técnica, mas se você acessar o site da SEFAZ-Autorizadora e baixar o XML de uma nota que contenha eventos, tais como carta de correção, ou cancelamento, ou outros, o XML vai ter a mesma estrutura do *-nfedfe.xml

Bom dia a todos, Como foi feito alguns ajustes isso com certeza provocou efeito colateral em alguns provedores. Peço que anexem o XML que antes era validado e o atual bem como o provedor. Muito obrigado.

Bom dia Everson, Será que o problema não é o nível que não é 3? Tentou mudar ele para 2 ou 4 para ver ser resolve o problema?

Bom dia Márcio, A solução para esse problema vai ser mudar essa informação de lugar. Onde hoje é o código de verificação colocar o numero da NFS-e substituída por ser uma informação pequena, talvez seja necessário mexer no titulo. E passar para baixo no lugar do numero da NFS-e substituída o código de verificação, aumentar a largura desse campo e diminuir os demais, como por exemplo a página.

Bom dia Claudemes, Favor atualizar todos os fontes de todas as pastas e iniciar os testes com o programa exemplo. Criei um provedor chamado DeISS para a prefeitura de Indaiatuba/SP.

Bom dia, Você esta realizando os testes com o programa exemplo? Ao atualizar os fontes, atualizou todos os fones de todas as pastas? No caso da sua aplicação, você atualizou os arquivos INI.

Bom dia Marcio, Essa alteração você fez para qual cidade? Você notou que podemos colocar essas informações no próprio arquivo Cidades.ini para a cidade desejada?

Bom dia Kleberson, O problema é que no seu XML consta o grupo <infFretamento>. Grupo opcional e que consta na Nota Técnica 2018/002. Mas existe um detalhe importante, somente a partir de 10/09/2018 que vai ser liberado essa alteração no layout do XML no ambiente de homologação. Logo não podemos gerar o XML com esse grupo a fim de realizar testes. O ambiente de produção só será liberado no dia 15/10/2018. Isso explica o erro retornado pela SEFAZ.

Bom dia Roger, Se você atribui o valor True a propriedade de configuração: AtualizarXMLCancelado o componente pega o XML assinado e com o protocolo de autorização e realiza a troca desse protocolo pelo de cancelamento e salva esse XML "atualizado" na mesma pasta que estava o "original" e não na pasta definida na propriedade de configuração chamada: PathCan. Logo ocorre uma substituição de arquivos, você perde o XML que continha o protocolo de autorização. Essa propriedade PathCan é uma herança que continua no componente. No passado o cancelamento não era um evento como é hoje, sendo assim ao solicitar o cancelamento de uma nota o XML contendo o pedido de cancelamento bem como o seu retorno eram salvos na pasta definida em PathCan. Hoje como dito, o cancelamento é um evento, logo ao enviar o evento de cancelamento de uma nota é criado se necessário uma pasta chamada: Cancelamento dentro de uma pasta chamada Evento que por sua vez é criada dentro do Path definido na propriedade de configuração chamado: PathEvento. Dentro da pasta ...\Evento\Cancelamento é salvo 3 arquivos XML: o pedido de cancelamento (*-ped-eve.xml), o retorno da SEFAZ (*-eve.xml) e o processamento do evento (*-procEventoNFe.xml) Segundo a versão 6.0 do Manual da NF-e ao cancelar uma nota, o emitente deve guardar pelo tempo legal o arquivo de processamento (*-procEventoNFe.xml) e disponibiliza-lo para o seu cliente e para as demais "pessoas" que precisam saber que a nota foi cancelada. Em nenhuma linha desse manual traz a informação que devemos ou podemos se assim desejarmos realizar a troca do protocolo de autorização pelo de cancelamento no XML da nota. Segundo o Ajuste SINIEF 07/05 o primeiro paragrafo da clausula primeira diz o seguinte: § 1º Considera-se Nota Fiscal Eletrônica - NF-e o documento emitido e armazenado eletronicamente, de existência apenas digital, com o intuito de documentar operações e prestações, cuja validade jurídica é garantida pela assinatura digital do emitente e autorização de uso pela administração tributária da unidade federada do contribuinte, antes da ocorrência do fato gerador. Resumindo, a Nota Fiscal hoje é o arquivo XML e só tem validade jurídica se estiver assinado digitalmente e com o protocolo de autorização de uso. Portanto no meu entendimento, se você ao cancelar uma nota trocar o protocolo de autorização pelo de cancelamento, o XML deixa de ter validade jurídica. Motivação para esse entendimento. Se enviamos um evento de Carta de Correção, devemos disponibilizar o arquivo *-procEventoNFe.xml (processamento do evento) para o nosso cliente e não realizamos nenhuma alteração no XML da nota fiscal, pois se assim fizermos o mesmo perde a validade jurídica. Logo se enviamos um evento de Cancelamento, devemos também disponibilizar o arquivo *-procEventoNFe.xml para o nosso cliente e não devemos realizar alteração no XML da nota, para que esta não venha perder a sua validade jurídica. Espero ter ajudado.

Boa tarde, Veja a tag <dhEmi> de ambos os XML, note que esta diferente. Isso significa que você esta gerando novamente o XML e atribuindo ao campo dhEmi a data/hora corrente da maquina antes de fazer a consulta. Não se deve fazer isso. Depois do XML gerado, não se deve gerar para realizar uma consulta e sim carregar o XML através do método LoadFromFile. Ao gerar o XML pela segunda vez com uma data/hora diferente da que foi enviado (mesmo que a diferença seja segundos) o digestValue será diferente.