Ir para conteúdo
  • Cadastre-se

adenilton

Membros
  • Total de ítens

    67
  • Registro em

  • Última visita

  • Days Won

    1

Tudo que adenilton postou

  1. Bom dia, como nenhum dos mantenedores se manifestaram, gostaria de saber se alguém irá analisar esse problema, se vai resolver o problema usando a abordagem proposta ou ainda outra abordagem? Desde já grato pelo atendimento voluntário a esta demanda.
  2. Problema: O XML da NFe está sendo montado de forma incorreta, para produtos com tributação de ICMS com CST 90 - Outros (com partilha do ICMS entre a UF de origem e a UF de destino ou a UF definida ma legislação). Por conta desse problema, durante a validação contra o schema, o seguinte erro é apresentado: 1871 - Element '{http://www.portalfiscal.inf.br/nfe}pBCOp': This element is not expected. Expected is ( {http://www.portalfiscal.inf.br/nfe}modBCST ) Por que ocorre: No arquivo "pcnNFeW.pas", no método TNFeW.GerarDetImpostoICMS, na linha 1641, há uma verificação que só permite a montagem dos campos modBCST, pMVAST, pRedBCST, vBCST, pICMSST e vICMSST, para a CST 90 - Outros e para a CST 90 - Outros com partilha..., caso o valor do campo vBCST ou do campo vICMSST seja maior que zero. Acontece no manual de orientação 6.0, na NT 2016.002, versão 1.61 e no schema de validação, os campos acima mencionados são obrigatórios para a CST 90 - Outros com partilha, com exceção dos campos pMVAST e pRedBCST. Portanto, esses campos devem constar no XML, ainda que zerados. A regra colocada no método, aplica-se perfeitamente a CST 90 - Outros, já que para essa CST, há grupos (sequência XML) opcionais no schema de validação, segundo o manual. Segue recorte da NT 2016.002, v1.61, mostrando a diferença entre as CST's 90 - Outros e 90 - Outros com partilha...: CST 90 - Outros: CST 90 - Outros com partilha: Solução: Alterar o conteúdo do método TNFeW.GerarDetImpostoICMS, do arquivo pcnNFeW.pas, linha 1641 de: if (nfe.Det[i].Imposto.ICMS.vBCST > 0) or (nfe.Det[i].Imposto.ICMS.vICMSST > 0) then para: if (nfe.Det[i].Imposto.ICMS.vBCST > 0) or (nfe.Det[i].Imposto.ICMS.vICMSST > 0) or (nfe.Det[i].Imposto.ICMS.CST = cstPart90) then Essa alteração fará com que os campos modBCST, vBCST, pICMSST e vICMSST sejam informados no XML, para a CST 90 - Outros com partilha..., ainda que os vBCST e vICMSST sejam zerados, conforme NT 2016.002, v1.61.
  3. Fica aqui a solução para quem passou por esse problema: O que ocorre é que o componente ACBrNFe retornava o XML "procEventoNFe" da carta de correção por meio da propriedade WebServices.EnvEvento.RetWS. Em algum momento essa mesma propriedade passou a retornar apenas o XML "retEnvEvento". Se tentar carregar no componente apenas o XML "retEnvEvento", a exceção "campo cOrgao não informado" é lançada. Para sanar o problema, observei que o XML "procEventoNFe" pode ser obtido atualmente através da propriedade EventoNFe.Evento.Items[0].RetInfEvento.XML.
  4. Na versão mais recente do ACBR (revisão 13837), ao tentar imprimir uma carta de correção está ocorrendo o erro "Campo cOrgao não informado". Testado também na aplicação de demonstração de uso (ACBrNFe - Demonstração). Abaixo segue gif demonstrando o problema e os XMLs utilizados estão em anexo. 28170907703290000189550010000016471003172774-NFe.xml 28170907703290000189550010000016471003172774_1_1-procEventoNfe.xml
  5. Balança: Toledo. Versão dos fontes: Atualizado até a revisão 12865 de 26/01/2017. Descrição do problema: Se configurar o componente TACBrBAL para monitorar a balança (ACBrBAL1.MonitorarBalanca := True;) o componente fica monitorando a balança, mas para de fazê-lo se o método TACBrBAL.LePeso for chamado. Ex: ACBrBAL1.LePeso( TimeOut ); O problema está no método abaixo: function TACBrBAL.LePeso( MillisecTimeOut : Integer) : Double; Var Ativado, Monitorando : Boolean ; begin Ativado := Ativo ; Monitorando := MonitorarBalanca ; try Monitorando := False ; if not Ativado then { Ativa caso não tenha sido ativado antes } Ativar ; Result := fsBAL.LePeso( MillisecTimeOut ) ; if Assigned( fsOnLePeso ) then fsOnLePeso( UltimoPesoLido, UltimaResposta ) ; finally Ativo := Ativado ; MonitorarBalanca := Monitorando ; end ; end; Note que a variável Monitorando está recebendo o valor da propriedade MonitorarBalanca(linha 6) e em seguida, dentro do bloco try, recebe false. Portanto quando o método LePeso for chamado, a propriedade MonitorarBalanca sempre será definida como false. Correção: Alterar método para: function TACBrBAL.LePeso( MillisecTimeOut : Integer) : Double; Var Ativado, Monitorando : Boolean ; begin Ativado := Ativo ; Monitorando := MonitorarBalanca ; try MonitorarBalanca := False ; if not Ativado then { Ativa caso não tenha sido ativado antes } Ativar ; Result := fsBAL.LePeso( MillisecTimeOut ) ; if Assigned( fsOnLePeso ) then fsOnLePeso( UltimoPesoLido, UltimaResposta ) ; finally Ativo := Ativado ; MonitorarBalanca := Monitorando ; end ; end;
  6. Alguém já implementou? Ou tentou? Sim, @RobertoRP. Uso em produção com ECF e NFCe Existe possibilidades de funcionar? Está funcionando. O componente de TEF trabalha com eventos, não está acoplado ao código do componente de ECF. Para funcionar com NFCe basta adaptar os eventos para seu cenário. Só tive problemas com a homologação do SITEF, e para o mesmo tive que fazer algumas alterações no código em delphi do componente. Essas alterações ainda não foram enviadas para o pessoal.
  7. Percebi só mais uma coisa. Quando desligo o PC exatamente no ponto indicado na sequência 16, "quando receber o retorno de aprovação e ainda com o cartão no pinpad", após reiniciar o PC e inicializar o TEF, este nem cancela nem confirma a transação que ficou pendente. Isso é normal?
  8. Conversei com um técnico da SW, ele entendeu a situação e disse que pode ser que o novo roteiro esteja errado. Pedi pra ele me mandar uma confirmação disso por e-mail. Quando ele responder o e-mail, posto aqui. Desde já obrigado.
  9. Ok, entendi. Nesse caso o cupom fiscal estará somente subtotalizado. Daí, acredito que quer chegar no seguinte: Se o ECF deu problemas e não pode finalizar a impressão do cupom (que está no meio - subtotalizado apenas), será que deve confirmar a transação mesmo assim? É isso? Achas que devo consultar a SW sobre essa sequência?
  10. EMBarbosa, desde já obrigado por responder prontamente. Acredito ser isso mesmo, pois pelo roteiro anterior que estava usando vi que o componente estava pronto. Neste caso, após a queda de energia, a confirmação deve ser enviada mesmo que o comprovante TEF não tenha sido impresso e o ECF esteja desligado. O que mudou nesse novo roteiro é que a aplicação terá que confirmar a transação, se antes da queda de energia houve aprovação da transação. Isso deve ser feito mesmo que o comprovante TEF não tenha começado a imprimir. Será que quando a dll envia para a aplicação a mensagem "Transacao OK", ela também não informa que a transação foi aprovada? Se sim, acredito que o componente deve ser alterado para fazer o backup dos dados da transação neste ponto e não no início da impressão do comprovante TEF.
  11. Esse manual que estou seguindo é a versão 14, intitulado "Roteiro de Pré - Homologação CliSiTef v.14", com data de 14/07/2016. Não. Nesta sequência pede pra desligar o PC(reset) ainda com o cartão no pinpad. Quando o cartão ainda está no pinpad, imediatamente após a aprovação, a impressão ainda NÃO começou, apenas uma mensagem "Retire o cartao da leitora", é apresentada. Logs anexados. Log_Tef.zip
  12. Bom dia, Seguindo sua sugestão, EMBarbosa, , implementei o uso do SiTef pela dll, usando o ACBrTefD. Solicitei novamente o processo de homologação à Software Express e eles me enviaram um roteiro diferente daquele usado para homologação com o Cliente Modular. Comecei o processo de homologação, mas me deparei com a seq. 16 abaixo: Note o trecho onde diz: Isso é um pouco diferente da seq. 20 da minha primeira mensagem, onde eu devia resetar o computador quando começasse a imprimir a primeira via. O problema que estou tendo é o seguinte: Não consigo passar dessa etapa, nem na minha aplicação nem no TEFDDemo, usando a versão mais recente do repositório. Obs: Debugando a biblioteca, percebi que o componente, corretamente, chega até o método ConfirmarESolicitarImpressaoTransacoesPendentes da unit ACBrTEFDClass.pas. Mas, pelo que vi, o componente não consegue passar nessa seq. 16 por que, no método ConfirmarESolicitarImpressaoTransacoesPendentes ele procura por um arquivo de backup no diretório configurado na propriedade PathBackup do componente, que ainda não existe neste ponto. Poderia me indicar se estou a deixar passar algo ou o que devo fazer para passar nessa sequência? Desde já grato.
  13. Obrigado por responderem. O cliente modular do sitef funciona como um Gerenciador Padrão com troca de arquivos. O tipo de rede configurado do ACBrTefD é, nesse caso, TEFDIAL. O comentário do Juliomar e seu, Embarbosa, acredito que esteja relacionado ao uso do sitef com a dll, configurando o componente para Clisitef, é isso? No caso do TEFDIAL, percebi que o método Inicializar não dispara o evento oninfoecf. E além disso, já vai cancelando as transações pendentes. Será que alguém já conseguiu homologar o sitef com cliente modular usando o ACBR?
  14. Boa tarde, De antemão gostaria de agradecer-vos por compartilhar vosso esforço e experiência por meio dos componentes ACBR e deste fórum. Estou fazendo o processo de homologação do SITEF utilizando o cliente modular. Tudo certo até a seq. 20, abaixo: Note que eles pedem para que, ao entrar na aplicação, se houver transações pendentes, confirmá-las. O problema que estou tendo é que o ACBRTefd sempre cancela as transações pendentes quando inicializo-o e não encontrei propriedade para mudar esse comportamento. Alguém pode me dar uma luz do que posso fazer para passar nessa seq. 20?
  15. Informo no ACBR o grupo ICMSUFDest, conforme o exemplo a seguir: with ICMSUFDest do begin vBCUFDest := 0; pFCPUFDest := 0; pICMSUFDest := 0; pICMSInter := 0; pICMSInterPart := 0; vFCPUFDest := 0; vICMSUFDest := 0; vICMSUFRemet := 0; end; Quando ele gera o XML percebo que a tag ICMSUFDest não está lá. Pergunta: Como faço pra enviar esses valores zerados?
  16. Adicionalmente, no demo em .net, após escolher que a impressão continue (na primeira pergunta que é exibida), se não ligar o ECF a aplicação fica em loop no evento OnInfoECF.
  17. Primeiramente gostaria de agradecer a todos que colaboraram com este projeto tão útil para os desenvolvedores .net. Estava testando a seq. 4 de pré-homologação do Sitef, onde orienta desligar o ECF após começar a impressão do vinculado e percebi o seguinte: No demo do TEF para o Delphi, se o ECF ainda estiver desligado após escolhermos que queremos continuar a impressão (ver imagem 01), o demo exibe novamente a pergunta. Imagem 01: A pergunta é reexibida até que o usuário ligue o ECF e a impressão seja efetuada com sucesso ou então o usuário selecionar que não deseja continuar a impressão. Já no demo em .net essa pergunta só é exibida na primeira vez. Após isso, se o ECF não for ligado, a aplicação devolve uma exceção e não exibe a pergunta novamente. Devo configurar algo pra ter esse comportamento no demo do .net?
  18. Obrigado EMBarbosa. Era aí que eu estava errando ao consumir a aplicação de demonstração. Eu NÃO estava utilizando o botão "FinalizarCupom" e SIM o botão "Fechar". Dessa forma eu também enviava cada pagamento manualmente para o ECF, por meio do botão "Pagamento". Agora funcionou.
  19. Obs 3: Se eu não executar o passo 3 desse segundo roteiro e ajustar OnInfoEcf da aplicação de demonstração, para que o componente não devolva a exceção " Operação TEF deve ser limitada ao Saldo restante a Pagar", daí o componente dá o problema citado na primeira mensagem. Tenta imprimir 8 vias. EMBarbosa, se puder, teste a aplicação demo sem marcar as duas opções: AutoEfetuarPagamento e AutoFinalizarCupom e tente vender em múltiplos cartões informando separadamente, no ECF, os meios de pagamentos. Gastei um bom tempo analisando o componente e ainda não descobri por que quando deixo marcada a opção "AutoEfetuarPagamento", as coisas funcionam normalmente. Mas quando desmarco essa opção e faço o pagamento manualmente enfrento problemas. Estou certo de que estou fazendo algo errado. Grato desde já pela ajuda.
  20. Obs: No demo, nesse segundo roteiro, se eu não executar o passo 3, quando tento enviar a segunda CRT, o componente devolve o erro: Operação TEF deve ser limitada ao Saldo restante a Pagar. Obs 2: Esses testes foram feitos na aplicação demo com as opções AutoEfetuarPagamento e AutoFinalizarCupom desmarcadas.
  21. EMBarbosa, obrigado por testar. Realmente foi de grande ajuda. Eu consegui fazer aqui. Mas somente com as opções AutoEfetuarPagamento e AutoFinalizarCupom marcadas. Se não for pedir demais, poderia fazer o teste com essas opções DESMARCADAS? Se der tudo certo, poderia me passar o roteiro que utilizou? Na minha primeira mensagem eu estava usando o seguinte roteiro: 1º CRT para o primeiro meio de pagamento; 2º outro CRT para o segundo meio de pagamento; 3º Enviava o primeiro pagamento para o ECF; 4º Enviava o segundo pagamento para o ECF; 5º Fechava o cupom; 6º Enviava o comando "ImprimirTransacoesPendentes" para o TEF. Daí ocorria o erro. Realmente com esse roteiro, eu confirmei que o componente tenta imprimir 8 vias. Dei uma olhada no log, no que o componente fazia quando as duas opções acima estavam marcadas e mudei o fluxo para: 1º CRT para o primeiro meio de pagamento; 2º Enviar o primeiro pagamento para o ECF; 3º Enviar o comando ConfirmarTransacoesPendentes para o TEF, para confirmar as transações pendentes (conferi no manual de especificação técnica do Pay&Go e vi que tem que mandar um CNF antes do segundo cartão) 4º Enviar o CRT para o segundo meio de pagamento; 4º Enviar o segundo pagamento para o ECF; 5º Fechar o cupom; 6º Enviar o comando "ImprimirTransacoesPendentes" para o TEF. O resultado desse fluxo é que o componente somente imprimiu a última via. Desde já grato por sua ajuda.
  22. Obrigado mesmo por fazer os testes. Vou refazê-los aqui e postar o resultado mais detalhadamente. Pergunta: Você registrou tudo em uma única forma de pagamento no ECF ou informou-as separadamente (Exemplo: Visa = 1,00; Mastercard = 2,00)?
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.