Antonio Carlos L

Mas isso de demorar aconteceria apenas para a primeira vez quando você parte do zero. E se mesmo demorando está conseguindo fique feliz. Se por exemplo o contador de seu cliente estiver usando algum aplicativo de consulta que faz isso a cada 1 hora em background a chance de você não conseguir por consumo indevido é total, mesmo que você só realize uma única consulta.

Se entendi a resposta do Juliomar basta passar as informações que internamente o componente vai gerar o hash

Maxsuel, erro 10060 indica que a URL não pode ser encontrada. As máquinas estão com DNS definido ou estão fazendo do IP do Gateway o DNS ?

Acho que você está equivocado com a tabela de CFOP que postou.

Talvez falte mais um try except quando da consulta onde um timeout faça sair.

Obrigado @Italo Giurizzato Junior pela atenção.

OI Juliomar. Levando em consideração sua resposta, olhei a chamada da consulta e esta identica ao exemplo do MDFe em procedure TfrmACBrMDFe.btnConsultarClick(Sender: TObject); Veja no código da Revision 33422 na unit ACBrMDFeWebServices . Existe outras duas variaveis FprotMDFe e FprocEventoMDFe, coloquei o bloco de código abaixo, que também são destruídas se existirem antes de serem criadas. Segui apenas a mesma logica em relação a FprocInfraSA. O fato é que se eu remover essa linha e fizer varias consultas acontecem vários MemoryLeak e acrescentando essa linha não ocorre. procedure TMDFeConsulta.Clear; begin inherited Clear; .... if Assigned(FPConfiguracoesMDFe) then begin FtpAmb := FPConfiguracoesMDFe.WebServices.Ambiente; FcUF := FPConfiguracoesMDFe.WebServices.UFCodigo; end; if Assigned(FprotMDFe) then FprotMDFe.Free; if Assigned(FprocEventoMDFe) then FprocEventoMDFe.Free; if Assigned(FprocInfraSA) then FprocInfraSA.Free; <<< adicionado FprotMDFe := TProcMDFe.Create; FprocEventoMDFe := TRetEventoMDFeCollection.Create; FprocInfraSA := TProcInfraSA.Create; end;

Revision 33422. Estava dando o seguinte memoryleak ao efetuar consulta MDFe. Achei a classe TProcInfraSA na unit ACBrMDFeWebServices A classe é criada no metodo TMDFeConsulta.Clear e esta sendo destruída no destrutor; Adicionei essa verificação antes de criar if Assigned(FprocInfraSA) then FprocInfraSA.Free; FprocInfraSA := TProcInfraSA.Create; e o leak desapareceu. Para vossas considerações.

As tentativas devem acontecer em um intervalo mínimo de 1 hora. Pode ser que ao tentar muitas vezes em intervalos menores tenha sido bloqueado.

Cara a sua questão é contábil e não de programação. Pela sua pergunta quem vai devolver é do simples nacional pois usa csosn 900. Entretanto quando você diz que todos os destaques usam cst 41 gera certa estranheza pois é isento. Essa empresa que vai receber a nota não é do simples e muito cuidado, provavelmente essa nota vai para o SPED e se estiver errado vai dar M. Siga a orientação do contador da empresa !

Meu querido, essa imagem.deve ser ou porque vc está dando trur em exibir mensagem ou porque seu código está exibindo

Eu imagino que o cliente deva ter um aplicativo de consulta da NF-e para baixar o XML, deve ser essa a origem. Ou o aplicativo de emissão fica tentando em loop sem consertar o problema emitir uma nota rejeitada.

Oi Flavio, vou falar em cima do trecho que vc apresentou. No seu relato você diz : "O que esta acontecendo é que no xml ao enviar, por ter o campo vOutros preenchido o campo vProd esta indo zerado, com isso estou tendo o retorno 564" <prod> <cProd>6566</cProd> <cEAN>7891027351557</cEAN> <xProd>CAD BROCH CD UNIV S/P SPICE 80 7891027351557 PC/5</xProd> <NCM>48202000</NCM> <CEST>1902100</CEST> <CFOP>6411</CFOP> <uCom>UN</uCom> <qCom>4.0000</qCom> <vUnCom>0.0000000000</vUnCom> <vProd>70.08</vProd> <cEANTrib>7891027351557</cEANTrib> <uTrib>UN</uTrib> <qTrib>4.0000</qTrib> <vUnTrib>0.0000000000</vUnTrib> <vOutro>17.52</vOutro> <indTot>1</indTot> </prod> Mas o campo zerado é <vUnCom>0.0000000000</vUnCom> e <vUnTrib>0.0000000000</vUnTrib> que suponho que : <vProd>70.08</vProd> e <qCom>4.0000</qCom> deva ser 17,52 o mesmo valor de <vOutro>17.52</vOutro> no item. Aparentemente esta sendo DIMINUIDO do valor da unidade comercial e tributada o valor de despesa acessoria que deveria somar ao preço final do produto. Pelo trecho do total <vProd>154.00</vProd> parece haver outros itens. Entretanto <total> <ICMSTot> <vBC>0.00</vBC> <vICMS>0.00</vICMS> <vICMSDeson>0.00</vICMSDeson> <vFCP>0.00</vFCP> <vBCST>0.00</vBCST> <vST>0.00</vST> <vFCPST>0.00</vFCPST> <vFCPSTRet>0.00</vFCPSTRet> <vProd>154.00</vProd> <vFrete>0.00</vFrete> <vSeg>0.00</vSeg> <vDesc>0.00</vDesc> <vII>0.00</vII> <vIPI>0.00</vIPI> <vIPIDevol>0.00</vIPIDevol> <vPIS>0.00</vPIS> <vCOFINS>0.00</vCOFINS> <vOutro>17.52</vOutro> <vNF>171.52</vNF> </ICMSTot> </total>

Creio que você esteja se referindo a essas questões : 1 - Então o vBCEfetivo seria simplesmente igual ao vProd?!?! Se sim estou fazendo errado, pois estou usando a seguinte fórmula para obter o vBCEfetivo: vProd * (1 - (pRedBCEfet / 100)) 2 - O pICMSEfet é simplesmente o pICMS + pFCP?!?! Se sim vai ser uma maravilha, pois será um valor único para todos os produtos!!! Alguém aí pode confirmar quais seriam os percentuais do pICMS e pFCP usado no Rio?!?!? Se você ler em um post anterior a esse seu, eu disse : " ... Sobre o vBcEfetivo. Imagina que é uma operação tributada normalmente ( mesmo do simples ) a vBcEfetivo é o valor do produto. E o percentual pela regra do RJ é o percentual de ICMS do estado acrescido do percentual do FCP." O MARCO POLO fala exatamente disso no vídeo e ainda tece criticas ao infame "SERIA". Mas você quer algo mais explicito : vBCEfet é o valor do produto, pICMSEfet é o valor do ICMS normal + FPC, e vICMSEfet é (vBCEfe x pICMSEfet )

Caro @bnobre voltei ontem do recesso. Creio que essa explicação do cara que é contador va dirimir suas dúvidas.