arce

@gutopmc Minha versão em produção está na revisao 12022 do svn do ACBr. Verifiquei que recentemente fizeram algumas mudanças nessas units. Ainda não fiz a atualização para a versão mais atual.

Sim Layout cfe 0.07 Versão do Sw.Base: 01.01.00 Dll Elgin 2.0.0.3 (Data de modificação 29/06/2016)

@Daniel Simoes Boa Tarde, sobre a análise outra coisa que pode ser observada é numero da sessão. Perceba que mesmo no cfe com o Base64 o número da sessão (antecedido pela palavra Resposta) está contém o número de outra sessão 999986. 22/09/16 14:54:07:069 - NumeroSessao: 999988 - Resposta:999986|06000|0000|Emitido com sucesso + conteúdo notas||| 22/09/16 14:51:55:175 - NumeroSessao: 999987 - Resposta:999986|06000|0000|Emitido com sucesso + conteúdo notas|||PENGZT48aW5mQ Outros comandos seguidos continuam retornando o numero de sessão 999986, até o momento que há uma desInicializacao/Inicializacao do SAT.

Bom dia Em dois SATs (ELGIN) aconteceu a seguinte situação, ao enviar um CFe o componente retornou as tags de confirmação de emissão preenchidas corretamente, porém sem o XML. No diretório parametrizado para salvar os arquivos o CFe não é gerado, fica apenas um arquivo como nome AD.xml (anexo); horas depois consultei no sistema de Retaguarda da SEFAZ e os cupons foram de fato emitidos. O estranho é que este erro não é constante, um cupom com as mesmas características foi emitido alguns minutos depois pelo mesmo equipamento. Emiti tbm com um KitDEV da Elgin sem apresentar problemas. Entrei em contato com o Rubens da Elgin e verificou a versão da dll e está correta. Segue anexo o LOG gerado pelo ACBr e o log extraído do equipamento (post seguinte - por causa do tamanho) para melhor entendimento. Os CFes que apresentaram o problema possuem a sessão 999988 e 999940. ACBrLogSAT.log AD.xml log do equipamento Log_ELGIN SAT_23092016.log

@rodrigoogioni Tive problemas no anexar PDF durante o processo de envio de email, estava cruzando informação dos destinatários. Segue as units sem o agrupamento do PDF. ACBrNFeDANFeRL.pas ACBrNFeDANFeRLClass.pas

@Glaucos Luiz Ginez Muito obrigado. Estava buscando essa solução à alguns dias. No trunk1 usava a impressão do Rave, que era agrupada. Alguns clientes já estavam reclamando. Eu apenas retirei o agrupamento do PDF, para que ficar em arquivos separados.

@Juliomar Marchetti Como disse anteriormente, esta opção já existia nas impressões antigas do ACBrNFe (trunk1), meus clientes já estão familiarizados com este modelo. Sobre a questão do manual até onde sei, o que não pode é retirar determinadas informações da DANFE.

Para sats que já foram ativos, se ele não for atualizado até 31/07/2016 ele ficará incapacitado de emitir CFe até q seja atualizado? ou o equipamento será "perdido"?

Boa tarde No antigo layout do RaveReport (trunk1), quando as uCom era diferente da uTrib a impressão dos itens era em duas linhas (anexo layout antigo). Alterei o fonte do FortesReport para se comportar da mesma forma. Segue os fontes, para análise de vocês, caso seja interessante incorporar ao trunk. DANFE_2Un_rave.pdf DANFE_2un_novo_fortes.pdf ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.lfm ACBrNFeDANFeRLRetrato.pas

Respondendo (ou não) minha pergunta , fiz testes com esta mesma Nfe, somando 0,10 centavo em algum item e transmitindo. A rejeição só aconteceu qndo a diferença entre soma dos itens e total desconto foi maior que 0,50 centavos. Lendo o manual da receita 6.0, a validação W10-10 que trata das tags do desconto não apresenta nenhuma informação adicional sobre o arredondamento. Diferente por exemplo da validação W16-10, onde (*3) significa "Considerar uma tolerância de R$ 0,50 para mais ou para menos (NT 2012/003)." (página 276) Caso não haja citação do tipo de arredondamento, seria a regra (*3) o default?

Qual a tolerância em centavos dessa rejeição? Digo isto, pelo seguinte exemplo que aconteceu comigo. Por questões de arredondamento, minha tabela referente aos itens da venda (que foi construída antes do surgimento da NFe) tem o campo desconto Numeric(18,4), e ao final de um determinada venda atribui o total do desconto R$ 28,00 reais; a aplicação rateou este valor nos itens gerando valores com mais de 2 decimais. Ao importar esta venda na tabela NFe, onde o campo desconto do item é Numeric(18,2), o total geral deste campo ficou R$ 28,02 reais. Realizei o seguinte teste, alterei o campo da itens nota para Numeric(18,4), o valor total ao importar a venda passou a ser igual ao da venda R$ 28,00 reais. Transmiti esta nfe em ambiente de homologação e ela autorizou. Ao analisar o XML notei que a soma dos itens era divergente, sendo esta diferença de R$ 0,02 centavos. Logo repito minha pergunta inicial, existe tolerância em centavos dessa rejeição? Se houver, quantos centavos são? Anexo XML da NFe autorizada. (se vcs somarem todas as tags vDesc dos itens o valor será 28,02, e a tag do total do desconto é 28,00) 35160711918344000109550010000031551722308360-nfe.xml

Bom dia Estou com problemas ao assinar os xmls de EnvioSincrono e CancelarNFSe com OpenSSL, para o provedor Fiorilli. Existem outros tópicos referentes a outros provedores com erros semelhantes no fórum, porém não estou conseguindo solucionar o problema. O arquivo de envio sincrono deve ter cada RPS assinado individualmente além de no fim do Lote ter uma assinatura geral. O método TDFeOpenSSL.Assinar é chamado pela primeira vez para assinar o RPS, depois no envio do loteSincrono é chamado novamente. Não estou conseguindo associar qual o valor correto para passar no parametro "infElement" para que o método XmlSecFindSignatureNode encontre o nó para a assinatura (como citado pelo @Daniel Simoes no post http://migre.me/ulwKX). Segue anexo um xml válido de LoteRPSSincriono que o responsável pelo provedor me enviou. OBS: Antes da revisão 11936 do SVN, era possível enviar os lotes síncronos via OpenSSL, mas o cancelamento assim como agora também não era possível enviar. recepcionarLoteRpsSincrono.xml

Daniel, realizei update, e após as últimas alterações referentes ao post do tópico que você indicou, tbm não estou conseguindo EnviarSincrono com OpenSSL. Não entendi a questão do "infElement", uma vez que o mesmo é alimentado da mesma forma com Capicom (que está funcionando corretamente)

Até onde sei, o grupo da partilha do ICMS deverá ser preenchido caso de operação interestadual para Consumidor Final, Não Contribuinte de ICMS. Porém no começo do ano o STF revogou a obrigatoriedade para empresas do Simples Nacional, veja este outro post http://www.projetoacbr.com.br/forum/topic/28130-difal-suspenso-pelo-stf/

O preenchimento ou não do DIFAL e FCP depende das características do destinatário. O grupo da partilha do ICMS deverá ser preenchido caso de operação interestadual para Consumidor Final, Não Contribuinte de ICMS O FCP depende da UF, por exemplo o estado do RJ possui, MG não, porém a atribuição ou não do FCP pode variar de NCM. (Consulte sempre um bom contador para tirar estas dúvidas) O grupo da partilha do ICMS independe do Regime Tributário do emitente.

Bom dia Estou com problema ao consultar o cadastro de CNPJs do estado do Rio de Janeiro. Estou utilizando certificado digital A1 e este pertence à contribuinte do estado de São Paulo. Através do ACBrNFe consulto os CNPJs de outros estados como PR, SC, RS, MT, entre outros, o único que está apresentando problema é o RJ. O Componente retorna esta mensagem Rejeicao: Sigla da UF da consulta difere da UF do Web Service Subentende-se que a url do webservice que estou tentando conectar esteja errada, olhei no NFeServices.ini e comparei com as urls do webservice e estão ok. Uso meu código desta forma. O que estou fazendo de errado? ACBrNFe1.Configuracoes.WebServices.UF := cmbUF.Text; ACBrNFe1.WebServices.ConsultaCadastro.UF := cmbUF.Text; ACBrNFe1.WebServices.ConsultaCadastro.CNPJ := cCPFCNPJ; ACBrNFe1.WebServices.ConsultaCadastro.Executar;

Daniel. Atualizei os fontes e agora a falha é diferente, mas ainda apenas com OpenSSL Falha ao Assinar - Cancelar NFS-e: Erro: Falha ao localizar o nó de Assinatura No link, vc citou a "infElement", porém com a Capicom o conteúdo desta tbm é vazia e o erro não ocorre. Segue os conteúdo da variável FPDadosMsg do método ACBrNFSeWebservices->"TNFSeCancelarNfse.DefinirDadosMsg;" antes e depois de assinar (no caso Capicom - que está ok). Provedor Fiorilli. Capicom-Canc-AntesAssinar.xml Capicom-Canc-Assinado.xml OpenSSL-Canc-AntesAssinar.xml

No caso de compartilhamento da impressora, após criar a porta serial virtual, instalei como Generic Text e compartilhei. Configurei a porta com \\meupc\GenericElgini9 e funcionou. Existe outra maneira de acessar a impressora compartilhada?

Bom dia Estou mudando o método de impressão do SAT do fortes para o posprinter. Com este novo método consigo imprimir apenas instalando as impressoras como GenericText. A questão é o QRCode, que não está sendo impresso corretamente. É necessário alguma configuração específica do posPrinter para tal?

Ítalo, o erro também está acontecendo com o servidor Fiorilli ao assinar o Cancelamento, utilizando OpenSLL Falha ao Assinar - Cancelar NFS-e: Erro: Falha ao interpretar o XML "xmlParseDoc"

AllanFC, muito obrigado. Estava acontecendo comigo também.

bom dia Peço desculpas, mas adicionei o código errado =/ Unit-> ACBrNFSeWebServices. O correto é: procedure TNFSeEnviarSincrono.FinalizarServico; begin inherited FinalizarServico; if(FProvedor <> proFiorilli)then if Assigned(FRetornoNFSe) then FreeAndNil(FRetornoNFSe); end; Add a condição para o provedor fiorilli. Está correta esta minha solução? Uma vez que não consigo obter o retorno através do código que citei no post anterior.

Com Capicom o erro não ocorre, o erro era relacionado as dll's

Este erro está acontecendo comigo também, porém, ao enviar o cancelamento da NFSe (provedor Fiorilli) Estou utilizando OpenSSL

Italo, na unit ACBrNFSeWebServices na classe EnviarSincrono o método FinalizarServico destrói o retorno após o envio. procedure TNFSeEnviarLoteRPS.FinalizarServico; begin inherited FinalizarServico; if Assigned(FRetornoNFSe) then FreeAndNil(FRetornoNFSe); end; Ao comentar o "if", consigo ler as tags de retorno... ACBrNFSe1.WebServices.EnviarSincrono.RetornoNFSe.ListaNFSe.MsgRetorno.Items[i].Codigo Com certeza este código existe por causa de outros provedores, adicionei uma condição para caso seja Fiorilli não destruir o retorno. Está correto este procedimento? OBS: Utilizo a opção ConsultarLoteAposEnvio = false