adenilton

Obrigado por Responder André. O problema não é necessariamente precisar abrir um novo vinculado. Tudo bem se todas as vias forem impressas em um único vinculado. O problema do componente é tentar imprimir mais vias do que o configurado. Veja, configurei para imprimir duas vias. Fiz a venda em dois cartões. O número de vias deveria ser 4. O componente imprime as 4, fecha o vinculado e em seguida tenta imprimir mais 4 vias. Somando 8 vias ao todo. E isso é bug. Quanto ao fato de ter um segundo vinculado ou não, como provavelmente o ECF não devolve essa informação, acredito que o componente deveria ter uma propriedade para escolher isso. Talvez uma propriedade chamada "EcfPermiteMultiplosVinculados". Mas já que a política do componente, por enquanto é imprimir todas as vias num vinculado só, eu ainda não entendi que relação isso tem com o fato de imprimir detalhadamente os meios de pagamentos no Cupom Fiscal. Existe alguma regra que determine que devam existir tantos vinculados quantos meios de pagamentos no cupom? Desculpa, mas já olhei o código e ele é meio macarrônico. Vou me reservar a reportar e demonstrar o bug. Gostaria se possível que passasse para aqueles que desenvolveram a rotina, pois terão mais afinidade com ela. Pergunta, alguém já fez o teste que fiz na primeira mensagem? É até rápido de fazer.

Desculpa a demora. Seguem, em anexo, os logs do Ecf e do AcbrTef e screens da leitura X do emulador da Bematech MP-4200 TH F, utilizado nos testes. ecf.log TEF_DIAL.log

Debugando aqui o componente no método "TACBrTEFD.ImprimirTransacoesPendentes;", para a situação descrita na minha primeira mensagem, vi que o problema está nos seguintes laços: For K := 0 to Length( GrupoVinc )-1 do . . . For J := 0 to RespostasPendentes.Count-1 do . . . while I <= NVias do . . . Onde a variável GrupoVinc contém 2 registros, RespostasPendentes.Count vale 2 e NVias vale 2. 2x2x2 = 8. O componente, dessa forma iria tentar imprimir 8 vias em vez de 4. E quando ele imprime as 4 primeiras, ele fecha o vinculado. Depois disso tenta imprimir uma quinta via, no mesmo vinculado. Só que este já está fechado, causando o erro. Mais detalhes: Com isso em mãos o componente executa, quatro vezes o trecho abaixo, para o primeiro "GrupoVinc" if I = 1 then ECFImprimeVia( trVinculado, I, ImagemComprovante1aVia ) else ECFImprimeVia( trVinculado, I, ImagemComprovante2aVia ) ; O resultado é que ele imprime, somente para o primeiro "GrupoVinc", as quatro vias (duas para o primeiro meio de pagamento - visa e duas para o segundo meio de pagamento - mastercard. Depois disso ele vai para o próximo "GrupoVinc" não tenta abrir um novo vinculado, em lugar disso, com o vinculado já fechado, ele tenta executar novamente o trecho acima e o ECF dispara uma exceção. Vendo isso, dá pra perceber que quem programou, tentou implementar a impressão do vinculado, levando em conta cada meio de pagamento, mas a implementação acabou ficando bugada. Não me parece que o componente não suporta o fato de ter mais de um meio de pagamento do tipo cartão no ECF. O que parece é que sempre usaram assim por que ficou um bug nesse procedimento que ainda não foi corrigido, e por isso não conseguiam fazer do jeito certo. Desde já grato pelo atendimento à esta demanda.

Juliomar, entendo que todos usam assim, pois se tentassem detalhar os meios de pagamentos, não conseguiriam certo? Mas o que vos notifico, acredito ser um BUG do componente, não vale a pena avaliar o código e tentar resolver, pra deixar certinho? Bug deixado solto, pode fugir da gaiola e fazer estrago em outros lugares rsrs.

Obrigado por responder. O problema de colocar tudo em uma única forma de pagamento, é que depois como fica a conferência dos totalizadores de "MEIOS DE PAGAMENTOS" da Redução Z? Algumas empresas utilizam essa informação da redução para confrontar com os relatórios da automação. Alguns contadores também utilizam essa informação na Redução Z para fazer os lançamentos nos caixas fiscais. Nos testes que fiz, o que percebi foi o componente não verificar que o vinculado já estava fechado e que todas as vias já haviam sido impressas. Poderia explanar melhor sobre o limite de modelos de ECF? Li que alguns ECFs não suportam mais de um vinculado. Me parece que só a Daruma suporta. Mas acredito não ser esse o caso, pois o componente não tenta abrir um novo vinculado após o final do primeiro. O que ele tenta é imprimir uma próxima via, indevidamente, quando todas as vias já estão impressas e o vinculado fechado.

Boa tarde, Não estou conseguindo efetuar uma venda TEF em múltiplos cartões, caso eu registre no ECF uma forma de pagamento diferente para cada cartão. Vamos ao cenário de teste e às informações de como reproduzir o problema. Para começar estou utilizando o Delphi XE5, instalado em um Windows 10 x64. Estou utilizando o ACBR do repositório https://svn.code.sf.net/p/acbr/code/trunk2, e os fontes estão atualizados até a revisão 11791 (liberada em 17/05/2016). Estou utilizando o emulador da Bematech MP-4200 TH FI. No emulador estão cadastradas as seguintes formas de pagamento: Forma Pagto: 1 -> Dinheiro Permite Vinculado: N Forma Pagto: 2 -> Duplicatas Permite Vinculado: S Forma Pagto: 3 -> Mastercard Permite Vinculado: S Forma Pagto: 4 -> Visa Permite Vinculado: S A solução TEF utilizada é a versão de demonstração da Pay&Go. Agora vamos à aplicação TEFDDemo 1 - Deixei a aplicação TEFDDemo configurada conforme imagem 1.png em anexo; 2 - A guia operação ficou, conforme a imagem 2.png em anexo; 3 - Cliquei no botão "Abrir"; 4 - Em seguida, cliquei no botão "Vende Item"; 5 - Em seguida, Cliquei no botão "CRT", (o campo "Indice CARTÃO", da guia "Configuração" preenchido com o valor 4 [Visa] e o campo "Valor TEF", da guia "Operação", preenchido com valor 0,3); 6 - Depois, fui na guia "Configuração" e mudei o valor do campo "Indice CARTAO" para 3, que equivale à forma de pagamento Mastercard, e novamente na guia "Operação", cliquei em "CRT" 7 - Ainda na guia "Operação", mudei o valor do campo "Valor ECF" para 0,3 e cliquei em pagamento. No input seguinte(Digite o Cód. Forma de Pagamento), informei o código 4(que foi a forma de pagamento utilizada no passo 5). Cliquei mais uma vez no botão "Pagamento" e informei o Código da forma de pagamento 3 (passo 6); 8 - Mudei o valor do campo "Valor ECF" para 0,4 e cliquei mais uma vez em "Pagamento", informando dessa vez o código 1 (Dinheiro); 9 - Cliquei em "Fechar" e o cupom ficou como na imagem 3.png; 10 - Cliquei no botão "ImprimirTransacoesPendentes" e no final da impressão do vinculado, o componente dispara o erro: 'Erro retornado pela Impressora: Categoria: 7-Erro em Relatório Gerencial ou CCD. Motivo: 14-Envio de texto genérico para CCD ou Relatório Gerencial já fechado.' Fiquei monitorando o trecho trVinculado : ACBrECF1.LinhaCupomVinculado( ImagemComprovante.Text ) com breakpoints e percebi, para tentar entender o porque do problema e percebi, que, mesmo após fechado o vinculado, o componente volta novamente e tenta executar a linha informada acima. O componente está configurado para imprimir duas vias do comprovante. Isso implica que ele deveria executar esse trecho 4 vezes. No entanto ele tenta executar uma quinta vez, daí o erro ocorre. Obs: Preciso que fique registrado no ECF as diferentes formas de pagamentos utilizadas no processo. e não apenas uma forma de pagamento genérica "cartão". Bug? Estou errando no modo de fazer isso? Desde já grato pelo atendimento à esta demanda.

Obrigado EMBarbosa, a sugestão de alteração no fonte do componente resolveu. Pergunta: A alteração vai ser adicionada ao SVN?

Para confirmar o problema, ainda a título de exemplo, após mudar a linha 239 para: for int0140 := 1 to 1 do Também altere o procedimento btnB_FClick(Sender: TObject) para: procedure TFrmSPEDPisCofins.btnB_FClick(Sender: TObject); begin // Alimenta o componente com informações para gerar todos os registros do // Bloco F. with ACBrSPEDPisCofins1.Bloco_F do begin with RegistroF001New do begin IND_MOV := imSemDados; // //F010 - Identificação do Estabelecimento // with RegistroF010New do // begin // CNPJ := '11111111000191'; // // //F100 - Demais Documentos e Operações Geradoras de Contribuição e Créditos // with RegistroF100New do // begin // IND_OPER := indRepCustosDespesasEncargos; // COD_PART := '1'; // COD_ITEM := '000001'; //Codigo do Item no registro 0200 // DT_OPER := Date(); // VL_OPER := 0.01; //Deve ser Maior que zero // CST_PIS := stpisCredPresAquiExcRecTribMercInt; //Para Operação Representativa de Aquisição, Custos, Despesa ou Encargos, Sujeita à Incidência de Crédito, o CST deve ser referente a Operações com Direito a Crédito (50 a 56) ou a Crédito Presumido (60 a 66).Para Operação Representativa de Receita Auferida, Sujeita ao Pagamento da Contribuição, o CST deve ser igual a 01, 02, 03 ou 05.Para Operação Representativa de Receita Auferida NÃO Sujeita ao Pagamento da Contribuição, o CST deve ser igual a 04, 06, 07, 08, 09, 49 ou 99. // VL_BC_PIS := 0; // ALIQ_PIS := 1.2375; // VL_PIS := 0; // CST_COFINS := stcofinsCredPresAquiExcRecTribMercInt; // VL_BC_COFINS := 0; // ALIQ_COFINS := 3.04; // VL_COFINS := 0; // NAT_BC_CRED := bccAqBensRevenda; // IND_ORIG_CRED := opcMercadoInterno; // COD_CTA := ''; // COD_CCUS := ''; //// COD_CCUS := '123';//Para usar o COD_CCUS é necessário gerar, primeiro, um registro 0600 correspondente. // DESC_DOC_OPER := ''; // end; // end; end; end; btnB_F.Enabled := false; if cbConcomitante.Checked then begin ACBrSPEDPisCofins1.WriteBloco_F; LoadToMemo; end; end; Em seguida execute a aplicação, clique nos botões "Bloco 0", "Bloco A", "Bloco C", "Bloco D" e "Bloco F" e depois em "Gerar TXT", conforme imagem (2.png) em anexo. Note agora que o bloco F foi gerado no componente como "Sem dados", mas o mesmo não consta no arquivo gerado!

Primeiramente gostaria de elogiar a todos os responsáveis pelo projeto open source e pela dedicação de vocês. Quanto à reposta do EMBarbosa: [Só pra confirmar, você está falando do SPED Contribuições certo? É que ficou postado na área do SPED PIS/COFINS.] R: Desculpa, mas não encontrei no fórum do SAC(http://www.projetoacbr.com.br/forum/forum/23-acbr-sac/) uma área para "SPED Contribuições", somente para "SPED Pis/Cofins". Mas se pensar bem, a EFD Contribuições não é o mesmo que o SPED PIS/COFINS? Ref: http://www1.receita.fazenda.gov.br/sistemas/efd-contribuicoes/o-que-e.htm. [Você consegue reproduzir o problema com o programa de exemplo?] R: Sim, consegui reproduzir o problema aqui na aplicação de demonstração (Utilizando a aplicação do trunk2, com fontes da biblioteca atualizado até hoje - 21/10/2015) e abaixo segue os passos para que também possa identificar o problema: 1 - Na aplicação de demonstração, no arquivo Frm_SPEDPisCofins.pas, linha 239, troque: for int0140 := 1 to 2 do Por: for int0140 := 1 to 1 do Em seguida, execute a aplicação e clique nos botões "Bloco 0", "Bloco A", "Bloco C", "Bloco D" e depois em "Gerar TXT", conforme imagem (1.png) em anexo. Irás notar que ele não irá gerar os blocos F e M, mas irá gerar o Bloco 1, como 'sem dados", mas o Bloco 1 NÃO FOI MARCADO, certo? Agora restaure o conteúdo da linha 239 para o que estava lá anteriormente e refaça o procedimento acima para gerar o TXT. Você notará que agora ele irá gerar os Bloco F e M, além do Bloco I que não foi marcado. Por que isso aconteceu? Bom, o código do componente acaba gerando em cascata alguns blocos, mesmo que você não os informe que seja "com" ou "sem" dados. Se olhares para o código do procedimento SaveFileTXT na unit ACBrSpedPisCofins.pas, irás ver que no final ele executa o procedimento WriteBloco_9 para totalizar os registros. Até aí tudo bem. Agora vamos no procedimento WriteBloco_9 e notamos que ele verifica se o Bloco 1 Já foi gravado. Caso o Bloco 1 não tenha sido gravado, ele chama o procedimento WriteBloco_1 para escrever o Bloco 1 como "sem dados". Até aí tudo bem. Agora vamos para o procedimento WriteBloco_1 que é chamado, conforme mencionado acima. Nele é verificada a existência do Bloco P. Se ele não encontrar o Bloco P, ele grava. É aí na gravação do Bloco P onde está o problema, vejamos abaixo: procedure TACBrSPEDPisCofins.WriteBloco_P; begin if (Bloco_P.Gravado) or (Bloco_0.Registro0145Count = 0) then exit ; if not Bloco_M.Gravado then WriteBloco_M; /// BLOCO P WriteRegistroP001; WriteRegistroP990; Bloco_P.WriteBuffer; Bloco_P.Conteudo.Clear; Bloco_P.Gravado := True ; end; Olhe para a verificação em: if (Bloco_P.Gravado) or (Bloco_0.Registro0145Count = 0) then exit ; Quer dizer, se não tiver um registro 0145 ele não irá gravar o P, mas também não irá gravar o M, que por sua vez não gravará o F, e assim por diante. No entanto o registro 0145 não deve interferir nos blocos M, F, D, C, etc. Como está em cascata no código. A existência do registro 0145 deve garantir somente a obrigatoriedade do bloco P. Próximo ponto: [Outra coisa, em quais páginas do Guia Prático estão a informação de que o bloco precisa ser gerado?] R: Essa informação encontra-se nas páginas 24-35 do "Guia Prático EFD-Contribuições – Versão 1.20", Seção 4 – Obrigatoriedade dos Registros. Você vai notar que nesta seção, para cada bloco, é indicado a "ocorrência" e a "Obrigatoriedade do Registro". Se a ocorrência de determinado registro de abertura do Bloco for maior que zero e a obrigatoriedade estiver indicada como "O", o bloco será de presença obrigatória no arquivo, mesmo que seja "Sem dados". Por último quanto a menagem do Isaque Pinheiro, Observo o seguinte: [O ACBr Sped não vai gerar registros obrigatórios pelo PVA por padrão] R: Como já mostrado acima, o componente gera blocos em cascata como "sem dados", quando detecta que este ainda não foi gerado. Se "não vai gerar registros obrigatórios pelo PVA por padrão" for o desejo dos administradores do projeto, então o código do componente precisa ser revisto. [se quer que um registro seja gerado por exigência do PVA informe a propriedade com ComDados no seu código] R: Irá notar no Guia prático que "todos" os blocos são de presença obrigatória no arquivo, exceto os blocos I e P. Além disso se você informar o registro de abertura do bloco como "ComDados" e não informar os registros filhos daquele bloco, o PVA irá apontar erros na estrutura do arquivo. Sei que a mensagem ficou enorme, mas espero poder ajudar para melhorar o código do componente. Fico no aguardo para que possam realizar os testes e fazer os devidos ajustes no código, se necessário. Ou então me recomendarem como deverei proceder, pois se eu informar os blocos obrigatórios que não possuem registros filhos como "sem dados", o componente não irá gravar eles no arquivo, a não ser que eu informe o registro 0145. Já se eu informar como "com dados" e o bloco não possuir registros filhos, o PVA irá informar erro na estrutura. Desde já agradeço a todos.

Ok, obrigado pelo retorno, vou verificar na aplicação de demonstração, depois posto o resultado.

Boa tarde, estou tendo o seguinte problema: Na geração do arquivo da EFD contribuições, utilizando a versão mais recente da biblioteca ACBR trunk2, o componente TACBrSPEDPisCofins não está gerando alguns registros que são obrigatórios, quando o campo IND_MOV do registro de abertura daquele registro é definido como sem dados. Aparentemente, se não há dados não é necessária a informação de tal registro, no entanto o PVA da EFD Contribuições reclama da estrutura de esses registros não forem informados ao menos como "sem dados". Além disso no Guia Pratico da EFD Contribuições Versão 1.20 mostra que alguns registros tem que estar obrigatoriamente no arquivo, mesmo que sem dados (neste caso o registro de abertura e de fechamento). Os blocos para os quais essa regra não se aplica são: I e P. O problema está no procedimento SaveFileTXT da unit ACBrSpedPisCofins.pas, cujo trecho destaco abaixo: procedure TACBrSPEDPisCofins.SaveFileTXT; begin try IniciaGeracao; WriteBloco_0; if FBloco_A.RegistroA001.IND_MOV = imComDados then WriteBloco_A( True ); if FBloco_C.RegistroC001.IND_MOV = imComDados then WriteBloco_C( True ); if FBloco_D.RegistroD001.IND_MOV = imComDados then WriteBloco_D; if FBloco_F.RegistroF001.IND_MOV = imComDados then WriteBloco_F; if FBloco_I.RegistroI001.IND_MOV = imComDados then WriteBloco_I; if FBloco_M.RegistroM001.IND_MOV = imComDados then WriteBloco_M; if FBloco_P.RegistroP001.IND_MOV = imComDados then WriteBloco_P; if FBloco_1.Registro1001.IND_MOV = imComDados then WriteBloco_1; WriteBloco_9; finally /// Limpa de todos os Blocos as listas de todos os registros. LimpaRegistros; FACBrTXT.Conteudo.Clear; FInicializado := False ; end; end; Note que as checagens "if FBloco_X.RegistroX001.IND_MOV = imComDados then" impedem que os blocos de informação obrigatória (que forem informados como sem dados) sejam gerados. Segue anexo a screen do PVA versão 2.0.12 alegando erro na estrutura do arquivo. Alguém confirma isso?

Aproveitando a oportunidade, a unit ACBrGNREWebServices.pas, revisão 9129 do regyssilveira (a última que aparece aqui para trunk2), também contém alguns erros que impedem a compilação. Variáveis não declaradas: GNREEnviGNRE: linha 596(Texto := Texto + '<versaoDados>'+GNREEnviGNRE+'</versaoDados>';) ConfAmbiente: linha 710; GNREConsResLote: linha 761(Texto := Texto + '<versaoDados>'+GNREConsResLote+'</versaoDados>';) GNREConsConfigUF: linha 1121(Texto := Texto + '<versaoDados>'+GNREConsConfigUF+'</versaoDados>';) Essas varíaveis não declaradas ainda são usadas nas linhas 875, 947, 1070 e 1239.

O mesmo aqui na trunk2. O problema foi provocado no commit 9950 (Indentação, melhorias e novos blocos no Sped ECFhttp://www.projetoacbr.com.br/forum/topic/23565-sped-ecf-disponibilizado-do-trunk2/?page=6) do juliomar em 11/09 às 16:57, na unit ACBrSpedECF.pas Foi adicionada a propriedade property Conteudo: TStringList read GetConteudo write SetConteudo; No entanto a procedure SetConteudo não foi declarada no arquivo.

Utilize a biblioteca em https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe/ que já está no layout 3.10 e suporta NFCe.

Adicionado

Obrigado arezende pelas suas sugestões. Eu centralizei todos os serviços relacionados à NFe na classe "ServicosNFe", pois desejava que a solução fosse mais próxima possível dos manuais da Nfe, já que nestes o foco são os serviços. Por exemplo, o objeto "nfeRecepcaoLote2" que contém um lote de NFe's é apenas um dos muitos objetos que cabem dentro de nfeDadosMsg, por isso não fiz centralizei as operações na classe NFe. Dessa forma poderás ver, como no exemplo que acompanha a biblioteca que o consumo de qualquer serviço, uma vez que vc já tenha o objeto que será convertido em "nfeDadosMsg" pronto, pode ser feito usando a classe "ServicosNFe" da seguinte forma: Consultar recibo de lote: var servicoNFe = new ServicosNFe(_configuracoes.CfgServico); var retornoRecibo = servicoNFe.NFeRetAutorizacao(recibo); Enviar uma NFe: var servicoNFe = new ServicosNFe(_configuracoes.CfgServico); var retornoEnvio = servicoNFe.NFeAutorizacao(Convert.ToInt32(lote), IndicadorSincronizacao.Assincrono, new List<Classes.NFe> {_nfe}); Mas nada impede que seja criada uma classe como vc sugere para abstrair ainda mais o código e deixá-lo mais próximo de como o ACBR trabalha atualmente, na verdade eu ficaria muito grato em receber sua ajuda. Quanto as outras sugestões, são essenciais. Gostaria de adicioná-lo como colaborador do projeto, por acaso seu git é https://github.com/arezende?

Se for um requisito de seu negócio aceitar certificados A3, você pode distribuir um web-service que deverá ser instalado na cpu do cliente. Este receberá o xml e o devolverá assinado para sua aplicação web.

Gleyson, junto a biblioteca já se encontra um aplicativo com a demonstração de uso, semelhante ao ACBrNFe_demo. Baixe em https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe

Ok, de acordo. Quando quiser acesso ao repositório, só pedir.

arezende, em breve estarei adicionando a impressão do DANFE para NFe e NFce, mas muito provavelmente farei isso com o próprio gerador de relatórios do visual studio, para não dependermos de componentes proprietários. Se isso não for possível podemos usar a função do ACBRFramework em Crystal Reports. De toda forma, fique desde já convidado a participar do projeto, o código fonte encontra-se em https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe, e qualquer ajuda será bem vinda.

É isso Mark, temos que acompanhar o que está acontecendo no mercado de software global. Qualquer coisa avisa aqui no fórum.

A biblioteca implementa os serviços de todos os estados, no entanto ainda não testei para o AM e SP. Qualquer dúvida poste aqui.

Por favor divulguem e ficaria grato se alguns se prontificassem para me ajudar a manter a biblioteca atualizada.

Conforme prometido, os fontes da biblioteca foram adicionados no Git. Endereço: https://github.com/adeniltonbs/Zeus.Net.NFe.NFCe

Versão inicial finalizada: Nesta versão a biblioteca terá suporte a todos os recursos da NF-e/NFC-e 2.0 e 3.10, exceto: 1 - Consumo do serviço NfeDownloadNF; 2 - Consumo do serviço NFeDistribuicaoDFe; 3 - Consumo do serviço NfeConsultaDest; 4 - Envio síncrono de NF-e/NFc-e para a versão 3.10; 5 - Envio de NF-e/NFC-e compactada para a versão 3.10; 6 - Impressão de Danfes; 7 - Envio de emails. Irei adicionar a licença no código e estarei disponibilizando logo mais.