Luiz Fernando

Eu tive o mesmo problema anteriormente, conforme esse post. Até mandei a Unit alterada para com o ajuste sugerido, mas não foi comitada, no meu fonte local eu tenho essa alteração feita e até então não tive nenhum problema de rejeitar notas.

Bom dia. Como não obtive resposta, fiz as alterações sugeridas e estou enviando para analise. Segue unit alterada em anexo. Att. pcnNFeW.pas

Bom dia. Estou com um dúvida no repasse de ICMS ST, o que ocorre é o seguinte, na NT 2016 002 V 1.30, fala que o repasse é somente interestadual, conforme imagem abaixo. Porém a regra da Unit pcnNFeW, não esta levando em consideração isso. if (nfe.infNFe.Versao >= 4) and (nfe.Det.Imposto.ICMS.CST = cst60) and //Ajuste para funcionar no ACBrNFeMonitor ((nfe.Det.Imposto.ICMS.vBCSTRet <> 0) or //Qdo passar CST 60 e algum campo de repasse de ICMS ST (nfe.Det.Imposto.ICMS.vICMSSTRet <> 0) or //estiver preenchido será trocado o cst para cstRep60 (nfe.Det.Imposto.ICMS.vBCSTDest <> 0) or (nfe.Det.Imposto.ICMS.vICMSSTDest <> 0)) then nfe.Det.Imposto.ICMS.CST := cstRep60; Ai na versão 4.00 se eu possuir ICMS ST Retido anteriormente e o CST 060, essa regra sempre esta mudando para cstRep60, mesma com operações internas. Gostaria de saber a opinião de vocês sobre a adição de outra verificação, deixando desta forma. if (nfe.infNFe.Versao >= 4) and (nfe.Dest.EnderDest.UF <> nfe.Emit.EnderEmit.UF) and (nfe.Det.Imposto.ICMS.CST = cst60) and //Ajuste para funcionar no ACBrNFeMonitor ((nfe.Det.Imposto.ICMS.vBCSTRet <> 0) or //Qdo passar CST 60 e algum campo de repasse de ICMS ST (nfe.Det.Imposto.ICMS.vICMSSTRet <> 0) or //estiver preenchido será trocado o cst para cstRep60 (nfe.Det.Imposto.ICMS.vBCSTDest <> 0) or (nfe.Det.Imposto.ICMS.vICMSSTDest <> 0)) then nfe.Det.Imposto.ICMS.CST := cstRep60; Fico no aguardo.

Bom dia. Futuramente talvez possamos mudar isso, porém hoje não existe essa possibilidade. Vou fazer uma implementação e enviar para analise. Agradeço a atenção.

Boa tarde, Nascimento. Quanto ao suporte esta tudo ok. Essa dúvida seria mais por parte do ACBr mesmo, mas obrigado pela resposta.

Boa tarde. O pessoal da SkyTef me passou o manual de integração, já faço a mesma utilizando o ACBrTEFD, porém eles tem uma linha de recorte dos comporovantes. Pelo manual, pode possuir até 3 comprovantes. Alguém já viu isso? Segue em anexo o bloco do manual onde informa isso.

Boa tarde. Tenta acessar o endereço do webservice diretamente no seu navegador, verifique se o mesmo abre rapidamente.

Perfeito Ricardo, havia esquecido de mencionar o campo de valores dos itens e totais

Boa tarde. Sim, é nessa tag. A melhor forma de saber o funcionamento do ACBrNFe é utilizando o demo, que esta na pasta de exemplos.

Funcionou perfeitamente @EMBarbosa Muito obrigado.

Muito obrigado. Irei testar e retorno com o parecer.

Ok, sem problemas. Agradeço a atenção, realmente alterei pois sem querer utilizei Ctrl+D para indentação do delphi. Prestarei mais atenção na próxima vez que for enviar códigos.

Se resolvermos de outra forma, por mim sem problemas. A alteração foi feita no procedimento GerarNFe. // Adicionando Produtos for I := 0 to 400 do begin Produto := NotaF.NFe.Det.Add; //Adiciona demais dados dos itens conforme já havia no ACBrNFe_Demo. end; E no final desse procedimento só verifiquei o tempo de geração do XML. hHora := now; NotaF.GerarXML; ShowMessage(FormatDateTime('HH:NN:SS:zzz', Now - hhora)); ACBrNFe1.NotasFiscais.GerarNFe;

Fiz o teste com 400 itens, ficou 311 Kb, porém isso pode variar de acordo com as informações contidas nos itens do xml, notas referenciadas entre outras coisas. E o MOC prevê até 990 itens.

Perfeito. Esqueci de comentar, utilizo o Delphi Seattle, pelo que eu encontrei na documentação a classe TStringBuilder foi implementada no XE 2.

Boa tarde. Estou com um problema na geração do xml da NF-e com muitos itens, fiz uma simulação utilizando o ACBrNFe_demo, segue tomada de tempos. 100 itens = 2 segundos 200 itens = 4 segundos 300 itens = 7 segundos 400 itens = 14 segundos Para simular, onde o ACBrNFe_demo popula os itens, fiz um for de 1 até o número de itens desejados. Com algumas modificações no arquivo pcnGerador para utilizar a classe TStringBuilder, nenhum dos testes acima chegou a 1 segundo. Ressalto que mantive a compatibilidade com o delphi 7, porém não consigo testar com o Lazzarus. Entendo perfeitamente a complexidade de alterar esta unit, porém a diferença de tempo é absurda. Fiz vários testes e todos geram o xml corretamente. Gostaria de saber o que vocês acham sobre essa possível modificação? pcnGerador.pas

Obrigado.

Bom dia. Observei que o valor do grande total da última redução Z esta ficando R$ -1, quando cai nessa regra. if IsBematech and (ECFCRZ <> RZCRZ) then Segue unit com o ajuste proposto. Fico a disposição para qualquer esclarecimento. ACBrECFEscECF.pas

Também não possuo essa impressora, não tenho como confirmar se esta funcionando ou não.

Perfeito. Obrigado

Daniel, fiz um arquivo de log demonstrando o resultado da rotina implementada. Observe que a leitura do índice 4 retorna o erro de tipo de pagamento não definido, porém dá sequência para o 5 e 6 no meu caso, sendo que essa impressora possui somente 5 formas de pagamento. log.txt

Irá ler, pois incremento a variável de contagem do while, somente quando der certo a leitura da forma de pagamento. Caso der erro irá cair no except com a mesma verificação que ele fazia anteriormente. Porém, caso haja um índice vazio, ira ser feita uma leitura desnecessária, mas não vai fazer as 20 necessárias anteriormente.

Funciona da seguinte forma: 01 - Dinheiro 02 - Cheque 04 - Cartão. O comando 0901, vai retornar 3 formas de pagamento, eu faço o loop levando em consideração esse número, porém o índice no caso do cartão, continuará retornando o 04.

Pensando na sua colocação, acabei fazendo um ajuste na leitura, para ler somente a quantidade de formas de pagamento cadastradas. Segue em anexo unit para analise. ACBrECFEpson.pas

Ok, obrigado.