Jump to content

wendelswl

Membros
  • Content Count

    27
  • Joined

  • Last visited

Everything posted by wendelswl

  1. Me deram a mesma resposta, estou insistindo com eles. Já enviei 3 e-mails e a resposta é a mesma. Acho que só vão resolver o problema quando mais pessoas reclamarem.
  2. Seguem os arquivos conforme solicitado. 29181209029006000166550010000011871015341068-sit.xml 29181209029006000166550010000011871015341068-ped-sit.xml 29181209029006000166550010000011871015341068-nfe.xml
  3. Estou com o mesmo problema, e a SEFAZ insiste que o erro está conosco. Enviei novamente o e-mail para eles com todas as informações, caso tenha algum retorno positivo posto aqui.
  4. Boa tarde. Fiz atualização hoje 14/06 e o problema foi sanado.
  5. Bom dia a todos, André, de acordo este post que estou acompanhando só consegui êxito com certificado A1 e Windows Server 2008 R2/2012 R2 fazendo o seguinte procedimento: ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; O colega acima mencionou que dessa forma esta utilizando Capicom e vez de WinCrypt, com essa reversão da revisão 15264 este cenário foi modificado? Nos comentários do Cristiano neste post também vejo uma alternância de TLS para funcionamento em determinados sistemas operacionais, para NF-e 4.0 não seria única e exclusivamente TLS 1.2? Agradeço antecipadamente o empenho de todos envolvidos, está sendo bastante produtivo para nós os dois posts.
  6. Cleyton e Marcelo, aqui deu certo tb, só que tive que definir no ACBr.inc o {.$DEFINE DFE_SEM_CAPICOM} novamente, pois já tinha retirado o suporte a capicom da aplicação. Obrigado, temporariamente vou utilizar desta forma.
  7. Daniel, primeiramente obrigado pela resposta. Se não me engano OpenSSL só funciona com certificado A1 (estou testando com certificado A1 inicialmente), mas neste caso eu teria problemas com A3, tenho clientes em produção com o mesmo. O curioso é que até a última atualização estava funcionando no próprio Windows Server 2012 R2, cheguei a emitir algumas NF-e`s 4.0 através do mesmo. Não tenho documentado a revisão da versão anterior. Vou continuar na busca aqui por soluções e qualquer coisa compartilho a solução, agradeço a todos pelas respostas.
  8. Fiz atualização no Windows Server 2008 R2 e Windows Server 2012 R2, nos dois casos o erro continua mesmo após os updates. Caso alguém tenha alguma dica adicional agradeço.
  9. Bom dia Marcelo, tinha feito atualização dos componentes há uns 15 dias e estava emitindo normalmente, após a atualização que fiz no dia 12/06 começou a apresentar este erro. Mais uma vez obrigado pelo feed Felipe, já tinha efetuado a configuração no componente. Windows ainda sendo atualizado, posto o resultado.
  10. Opa Frederico, bom dia. Estou utilizando o WinCrypt sim. Estou baixando os updates do Windows Server 2008 R2 neste momento, assim que concluir testo e posto os resultados.
  11. Bom dia Felipe, não tenho mais a dependência da Capicom, fiz isso nas diretivas contidas no ACBr.inc, a marcação de TLS 1.2 seria essa no componente ACBrNFe1.SSL.SSLType := LT_TLSv1_2 ou no navegador? Só um detalhe, só acontece no windows server 2008 r2, no windows 10 funciona perfeitamente. Agradeço antecipadamente,
  12. Estou enfrentando o mesmo problema, fiz atualização hoje. 12/06/2018.
  13. Pessoal, obrigado. O erro era no campo cNF do meu XML. Podem fechar o tópico e desculpem-me pelo transtorno..
  14. Prezados, bom dia. Percebi uma mudança após atualizar a versão do ACBr na seguinte situação: Tenho um determinado XML sem assinar, faço um LoadFromFile pelo componente e logo após chamo o método Assinar, percebi que nesta situação sempre é gerada uma nova chave de acesso para a nota fiscal, mesmo já constando uma chave de acesso no XML anterior. Na situação em que há rejeição é necessário modificar as propriedades do componente, assinar e transmitir novamente, e o ideal seria que a chave de acesso não fosse alterada neste procedimento, visto que, trata-se da mesma nota fiscal. Percebi pelos fontes que o método Assinar sempre chama o método GerarXML, que passa pelo código abaixo sempre gerando uma nova chave de acesso. Os colegas estão tendo esta dificuldade? Sempre fiz desta maneira e a chave nunca era alterada, há algo de errado neste fluxo? function TNFeW.GerarXml: Boolean; var chave: String; Gerar: Boolean; xProtNFe : String; xCNPJCPF : string; begin Gerador.ListaDeAlertas.Clear; Usar_tcDe4 := (NFe.infNFe.Versao >= 3.10); Versao := Copy(NFe.infNFe.VersaoStr, 9, 4); xCNPJCPF := nfe.emit.CNPJCPF; if not EstaVazio(nfe.Avulsa.CNPJ) then xCNPJCPF := nfe.Avulsa.CNPJ; chave := GerarChaveAcesso(nfe.ide.cUF, nfe.ide.dEmi, xCNPJCPF, nfe.ide.serie, <-- AQUI nfe.ide.nNF, StrToInt(TpEmisToStr(nfe.ide.tpEmis)), nfe.ide.cNF, nfe.ide.modelo); Agradeço por alguma resposta antecipadamente.
  15. Bom dia Italo, Em análise a sua resposta, o método consultar não retorna os eventos referente às manifestações efetuadas, e sim os eventos da NF-e (Carta de Correção, Cancelamento). A minha dúvida na verdade seria como confirmar se o evento de manifestação de destinatário realmente foi concretizada em caso de retorno perdido. Além disso existem mais situações em que necessitaria deste retorno, por exemplo: Imagine que instalamos a nossa solução em um determinado cliente que já fazia manifestação através de solução anterior ou até mesmo pelo aplicativo da SEFAZ. Na primeira utilização do módulo enviaremos o NSU 0, para obter o resumo dos últimos 90 dias e persistir as informações necessárias. Até onde pesquisei, não há como obter a informação de status dos eventos de manifestação através de nenhum método de consulta. Não vejo nenhum webservice que forneça tal retorno, com exceção do NFeConsultaDest, que será descontinuado. Vou tentar controlar pela aplicação fornecendo ao usuário o status da manifestação como desconhecido para estes casos em que a mesma não for efetuada pelo sistema ou não conseguir obter o retorno. Caso haja alguma novidade sobre tal operação espero que alguém se manifeste. Obrigado ao colega Ítalo pelos retornos.
  16. Prezado Ítalo, mais uma vez obrigado pelo feedback. Ocorreu sim o download do arquivo procEventoNFe do NSU de número 6, mas o mesmo se trata de uma carta de correção e não do evento de manifestação do destinatário. Analisando minuciosamente as NT's 2014.002 e 2012.002 percebi o seguinte: O WS NFeDistribuicaoDFe não fornece ao destinatário o evento de manifestação que ele mesmo efetuou, ou seja, através dos xml's retornados pelo WS é impossível obter tal informação. Acredito que o aplicativo de MD-e da SEFAZ faça utilização do WS NfeConsultaDest que, até onde li, será desativado. Favor, me corrija se estiver errado. Mas se eu estiver certo, como a aplicação que efetuou a manifestação do destinatário teria a confirmação que tal evento realmente chegou à SEFAZ caso haja alguma falha de comunicação na primeira tentativa de obter o retorno? Até onde analisei, não vi nenhum webservice em que o autor do evento de manifestação possa consultar os seus eventos que não seja o "NfeConsultaDest". Na oportunidade envio todos os outros XML's do processo em anexo, caso queira efetuar análise. Wendel Oliveira SWL SOFTWARE 201601.rar
  17. Prezado Italo, bom dia. primeiramente agradeço a disponibilidade e presteza. O componente está configurado para salvar os arquivos em disco, Após alguns testes acabei apagando os arquivos, mas gerei um outro que possuem os NSUs de 1 a 4 conforme mensagem que postei anteriormente. Segue em anexo. 20160104174606-dist-dfe.xml
  18. Prezados, bom dia. Tenho uma dúvida... Já li vários posts aqui do fórum e até então não localizei a resposta, gostaria da ajuda dos nobres colegas para tentar resolver uma situação. :), segue um teste que fiz: Fiz a emissão de 3 NF-e's contra meu CNPJ, utilizei o DistribuicaoDFe e consegui o resumo das mesmas (NSUs 1, 2 e 3) através do nosso sistema. Efetuei a manifestação de ciência de operação da NF-e correspondente ao NSU nº 1 através do programa da SEFAZ-SP, consequentemente, foi gerado um novo NSU de número 4 retornando as informações com o XML da NF-e. No nosso sistema o controle interno do último NSU consultado era o NSU de número 3, quando invoquei o método DistribuicaoDFe novamente, recebi as informações devidas do NSU de número 4 com o XML da NF-e, porém não consigo identificar a propriedade do componente que me retorna o tipo de Manifestação que ocorreu (Ciência da Operação, Operação Realizada, etc...). Fiz este teste com o intuito de capturar um evento efetuado pelo escritório de contabilidade, mantendo em nosso sistema sempre a informação atualizada, visto que, controlamos o último NSU na aplicação. Além disso, baixei o programa de Manifestação do Destinatário de SP em outra maquina, e fiz a consulta partindo do NSU de número 0 (últimos 3 meses), assim sendo o mesmo identificou a ciência da operação do NSU número 4 normalmente, por isso vi que havia esta possibilidade através de algum WS que não sei qual é. Alguém sabe informar se é possível obter esta informação através do componente?
  19. Prezado, boa noite. Entendi que não se deve inutilizar a NF-e em ambiente SVC-RS, pois o serviço não é disponível lá, esta situação já está sendo tratada por nosso ERP. O que estou tentando explicar é que caso haja um erro por parte do desenvolvedor (que foi o nosso caso), o webservice apresentaria um retorno para a aplicação com a exceção correspondente de que o serviço não é disponível e dessa forma acredito que ficaria explícito que este ambiente não deve ser utilizado. Para tal situação a condição acima deveria ser modificada como sugeri, pois se o tipo de emissão for SVC-RS a URL do action seria modificada para "NfeInutilizacao", Da forma que está, tanto a consulta quanto a inutilização nada é retornado pelo webservice, a exceção é levantada em branco. Ou seja, o problema só ocorre se o tipo de emissão for SVC-RS, se for para a Sefaz-BA tudo acontece naturalmente. Obrigado pelos esclarecimentos e segue a sugestão. Saliento que vossa explicação foi claríssima e obrigado mais uma vez pela disponibilidade.
  20. Boa tarde. Há um problema nas funções mencionadas, pois sem as correções que sugeri a URL fica incorreta e o webservice não retorna nada, desta forma a exceção aparece sempre em branco. Se o tipo de emissão da NF-e for normal a url termina com 'NfeInutilizacao' e não com 'NfeInutilizacao2', observe abaixo e ficará mais claro. SOAP 1.2 The following is a sample SOAP 1.2 request and response. The placeholders shown need to be replaced with actual values. POST /webservices/NfeInutilizacao/NfeInutilizacao.asmx HTTP/1.1 Host: nfe.sefaz.ba.gov.br Content-Type: application/soap+xml; charset=utf-8 Content-Length: <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Header> <nfeCabecMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NfeInutilizacao"> <versaoDados></versaoDados> <cUF></cUF> </nfeCabecMsg> </soap12:Header> <soap12:Body> <nfeDadosMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NfeInutilizacao"></nfeDadosMsg> </soap12:Body> </soap12:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Header> <nfeCabecMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NfeInutilizacao"> <versaoDados></versaoDados> <cUF></cUF> </nfeCabecMsg> </soap12:Header> <soap12:Body> <nfeInutilizacaoNFResult xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NfeInutilizacao"></nfeInutilizacaoNFResult> </soap12:Body> </soap12:Envelope>
  21. Boa tarde a equipe do ACBR. Na unit ACBRNFeWebServices há um problema na inutilização quando utiliza-se estado Bahia (29) nos seguintes procedimentos: Procedure TNFeConsulta.DefinirServicoEAction; Procedure TNFeInutilizacao.DefinirServicoEAction; Na condição contida na função deve-se adicionar um filtro de forma de emissão, pois para SVC-RS ocorrem erros: Alterar de: if (FConfiguracoes.Geral.ModeloDF = moNFe) and (FConfiguracoes.Geral.VersaoDF = ve310) and (FConfiguracoes.WebServices.UFCodigo in [29]) then // 29 = BA Para: if (FConfiguracoes.Geral.ModeloDF = moNFe) and (FConfiguracoes.Geral.VersaoDF = ve310) and (FConfiguracoes.Geral.FormaEmissao = teNormal) and (FConfiguracoes.WebServices.UFCodigo in [29]) then // 29 = BA Segue unit alterada para vossa apreciação caso seja necessário. Não analisei os layouts anteriores ao 3.10 para efetuar a modificação, Para o ambiente 3.10 funciona perfeitamente. ACBrNFeWebServices.pas
  22. Bom dia. Pessoal, vi que o post é antigo, porém estou iniciando os trabalhos com boletos da caixa e utilizo o Fortes Report (Carnê). Enviei alguns boletos para homologação e recebi as seguintes mensagens do banco: FICHA DE COMPENSAÇÃO - LOCAL DE PAGAMENTO PREENCHIDO INCORRETAMENTE (PREENCHER CONFORME ITEM 4.2.2.1 DO MO 67119, OU SEJA, “PREFERENCIALMENTE NAS CASAS LOTÉRICAS ATÉ O VALOR LIMITE”) - RETIFICAR TODOS OS CAMPOS ONDE CONSTA A EXPRESSÃO “CEDENTE” PARA “BENEFICIÁRIO” E ONDE CONSTA A EXPRESSÃO “SACADO” PARA “PAGADOR” - RETIFICAR OS CAMPOS PARA (=) VALOR DO DOCUMENTO, (-) DESCONTO, (-) OUTRAS DEDUÇÕES/ABATIMENTO, (+) MORA/MULTA/JUROS, (+) OUTROS ACRÉSCIMOS e (=) VALOR COBRADO NESTA SEQÜÊNCIA. - RETIFICAR O CAMPO “PAGADOR/AVALISTA” PARA CAMPO “SACADOR/AVALISTA” RECIBO DO PAGADOR - NÃO CONSTA A EXPRESSÃO “RECIBO DO PAGADOR” - RETIFICAR TODOS OS CAMPOS ONDE CONSTA A EXPRESSÃO “CEDENTE” PARA “BENEFICIÁRIO” E ONDE CONSTA A EXPRESSÃO “SACADO” PARA “PAGADOR” - NÃO CONSTA O CAMPO “NÚMERO DO DOCUMENTO” - RETIFICAR OS CAMPOS PARA (=) VALOR DO DOCUMENTO, (-) DESCONTO, (-) OUTRAS DEDUÇÕES/ABATIMENTO, (+) MORA/MULTA/JUROS, (+) OUTROS ACRÉSCIMOS e (=) VALOR COBRADO NESTA SEQÜÊNCIA Em anexo vai a imagem de um dos boletos que enviei. Atualizei meu componente hoje. Tem algo de errado na minha atualização ou realmente os erros a seguir existem?? Agradeço antecipadamente. Wendel Oliveira SWL SOFTWARE
  23. Prezado, vc pode entrar no site da SEFAZ de origem com o certiificado digital e obter o XML original da NF-e novamente. A partir daí existem "n" formas de gerar o PDF da mesma.
  24. Prezado, vc está utilizando o CSOSN incorreto. Consulta o manual da NF-e e veja que nesse CSOSN não deve ir valor de ICMS.
×
×
  • Create New...