BigWings

Já existe a condição para não gerar a tag ICMSUFDest, basta não preencher com valor maior que zero a tag pICMSInterPart. procedure TNFeW.GerarDetImposto(const i: Integer); begin Gerador.wGrupo('imposto', 'M01'); Gerador.wCampo(tcDe2, 'M02', 'vTotTrib ', 01, 15, 0, nfe.Det[i].Imposto.vTotTrib, DSC_VTOTTRIB); if (( NFe.Det[i].Imposto.ISSQN.cSitTrib <> ISSQNcSitTribVazio ) or (( NFe.infNFe.Versao > 3 ) and ( nfe.Det[i].Imposto.ISSQN.cListServ <> '' ))) then begin if NFe.infNFe.Versao >= 3 then (**)GerarDetImpostoIPI(i); (**)GerarDetImpostoISSQN(i); end else begin (**)GerarDetImpostoICMS(i); (**)GerarDetImpostoIPI(i); (**)GerarDetImpostoII(i); end; (**)GerarDetImpostoPIS(i); (**)GerarDetImpostoPISST(i); (**)GerarDetImpostoCOFINS(i); (**)GerarDetImpostoCOFINSST(i); if nfe.Det[i].Imposto.ICMSUFDest.pICMSInterPart > 0 then (**)GerarDetImpostoICMSUFDest(i); Gerador.wGrupo('/imposto'); end;

Com o cabo serial também não precisei do Sleep, apenas com cabo USB.

Esse erro geralmente é por falta de preenchimento do CSOSN do item.

Tenho emitido NF-e e NFC-e em modo síncrono, sem problemas. Sempre trabalhei com envio de nota única em cada processamento. Em minha experiência o modo síncrono, com protocolo OpenSSL é o mais rápido.

Sim, deve usar o CFOP 5656 e informar o código ANP referente ao lubrificante.

Boa tarde, Quando o Windows está configurado para data em formato americano (mm/dd/yyyy) o ACBrIBPTax não carrega corretamente a vigência inicial e final. Corrigi usando a função disponível no ACBrUtil, segue anexo. Implementei também um overload da função Procurar. Já havia postado antes mas não foi incluído no repositório. Gostaria que analisassem. ACBrIBPTax.pas

Veja a versão do FastReport. O ACBr é testado, até onde sei, no FR 5, pra quem tem o FR 4 como eu, ocorrem erros desse tipo. Em outro tópico deram uma dica pra "converter" os .fr3 para a versão 4, mas ainda não tive sucesso. Tente com o arquivo anexo, pra mim está funcionando. DANFeNFCe.fr3

Parece ter havido um erro no fórum no meu post acima, consigo ver a imagem mas não acessar os anexos, e ele não aparecia como último post da thread. Vou anexar novamente aqui. U_Principal.rar

Aproveitei pra inserir o email e telefone no demo. Segue fontes do demo e exemplo do erro. U_Principal.dfm U_Principal.pas

Quando não há email cadastrado na página da receita o ACBr retorna a string TELEFONE no email. Fiz uma pequena correção, segue anexo. ACBrConsultaCNPJ.pas

Oi, Dábila. Acredito que era alguma configuração da impressora, porque ela foi substituída por algum outro motivo e na nova o problema não ocorreu.

No caso do XML em anexo, o erro é o grupo de medicamentos que aparentemente não pode aparecer em NFC-e.

A exceção é para o subgrupo de encerrantes, o grupo de combustíveis deve ser informado para o CFOP 5656, no mínimo o código ANP e UF de consumo do produto.

Testei dessa forma e resolveu o problema. Mesmo reduzindo para Sleep(50) imprimiu normalmente. Obrigado. O buffer da porta estava no máximo, tentei várias configurações de buffer e não surtiu nenhum efeito.

Ainda não resolvi. Instalei o driver correto com a ajuda do suporte da Daruma (tem que aparecer no driver o signatário Daruma e não Microsoft), e fiz os testes com os aplicativos deles e funcionou sem problemas. Já no ACBr só funciona se desativar o ControlePorta. Por enquanto não estou recomendando esse modelo.

Testei em outro PC onde a impressão funcionou, mesmo com o ControlePorta ativado. Você disse pra remover o driver antigo, da DR700, mas não encontrei como. Apenas removi a porta virtual e instalei o driver fornecido pela Daruma. Tem algo mais que devo fazer pra remover os drivers DR700 e DR800 que instalei anteriormente? Outra coisa, você testou em Windows 8/8.1? Enquanto isso vou vendo com o pessoal da Daruma.

Régys, O problema acontece se a propriedade "ControlePorta" do PosPrinter estiver marcada. No meu programa essa opção está sempre ativada, então quando testei a impressão pelo demo do ACBr e imprimiu normal, consegui isolar o problema. Deslize meu não ter testado o demo antes, desculpem. Em todo caso, eu havia ativado a propriedade para não precisar abrir e fechar a porta serial da impressora sempre que fosse emitir algum relatorio, ou mesmo NFC-e, e desativando continuou a emitir normal, mas não tenho como testar em outros modelos de impressora. A ControlePorta ainda é necessária?

Faça em homologação, com data de hoje, o webservice de homologação já está criticando as tags.

Trunk2, revisão de 30/11/2015. Funciona normalmente na DR700. Vou tentar conseguir uma impressora pra testar aqui, pode ser alguma coisa no driver USB ou hardware do cliente. Obrigado.

Achei que o erro estava na transmissão de uma NF-e com campo CEST, nunca fiz exportação de txt para o emissor gratuito. Entretanto, olhando o layout disponivel aqui: http://www.emissornfe.fazenda.sp.gov.br/v310/docs/[Emissor_NF-e]_Manual_de_layout_TXT-NF-e_v3.10.1.pdf O campo CEST já está no layout: I|cProd|cEAN|xProd|NCM|NVE|CEST|EXTIPI|CFOP|uCom|qCom|vUnCom|vProd|cEANTrib|uTrib|qTrib|vUnTrib|vFrete|vSeg|vDesc| O emissor gratuito que está importando é da versão 3.0?

Alguém tem experiência com essa impressora na emissão do DANFE NFC-e via ESCPos? Não tinha conhecimento desse modelo novo da Daruma, e um cliente adquiriu. Quando tenta emitir a NFC-e, o QR-Code não imprime, e quando vai imprimir a próxima nota, ele sai. Estou tentando conseguir uma para testes, se alguém já tiver impresso NFC-e nesse modelo e puder dar alguma dica, agradeço.

Qual erro acontece quando se informa a CEST? Não vi nenhuma regra de validação referente a ele na NT 2015/003 que implementou o campo. Talvez siga a mesma regra do grupo de tributação interestadual, e só possa ser informado a partir de 01/01/2016.

Essa tag não representa a versão do layout da NF-e, aí sempre será 1.0. Veja a tag "versao" dentro de infNFe.

Ao atualizar os fontes do svn, os meus já eram um pouco antigos, percebi que foi removido o dfm com os datasets e estão sendo criados agora via código. Ao tentar imprimir um DACTE usando o arquivo ACBr\Exemplos\ACBrDFe\ACBrCTe\Delphi\Report\DACTE.fr3 recebo a mensagem: --------------------------- Erro --------------------------- Erro(s) encontrado(s): Dataset "LocalEntrega" não existe Dataset "ModalAereo" não existe --------------------------- OK --------------------------- Pelo que vi o dataset que antes era chamado LocalEntrega agora é CalculoImposto. Tentei de todas as formas alterar o arquivo .fr3 para alterar essa referência mas continuava aparecendo a mensagem acima. A única forma que consegui foi alterando no código de volta o nome do dataset para LocalEntrega. O DACTE.fr3 ainda é mantido? A última alteração dele é de julho. Qual o melhor arquivo .fr3 a ser usado? Segue arquivo com correções que funcionaram pra mim. PS: Corrigi também o problema com o motorista tratado em outro tópico. ACBrCTeDACTEFR.pas

Essa validação foi implementada na NT 2015/002, que entrará em vigor no ambiente de produção a partir de 01/12/2015.