adenilton

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.

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.

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.

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

Obrigado pela rapidez @EliasCesar

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;

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.

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?

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.

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?

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.

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

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.

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?

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?