Edmilson Santin

Bom dia pessoal, tudo bem? Conseguem incorporar isso no repositório? Já tenho essa alteração há um bom tempo e está estável. Desde já agradeço!

Bom dia pessoal, tudo bem? Conseguem incorporar isso no repositório? Já tenho essa alteração há um bom tempo e está estável. Desde já agradeço!

Olá pessoal, tudo bem? Ao enviar notas de exportação, onde é montado o grupo "Det.Prod.detExport", caso não seja informada a tag "nRE" é gerado o alerta "Campo nRE (Número do Registro de Exportação): Nenhum valor informado.". Esse campo não é obrigatório ao transmitir a nota, tanto é que dentro da função "ValidaRE" de "ACBrDFeUtil.pas" é retornado válido quando o mesmo está em branco, tendo como base o link http://normas.receita.fazenda.gov.br/sijut2consulta/link.action?idAto=81446&visao=anotado Essa situação passou a ocorrer no momento em que começamos usar o "ACBrNFe.XMLWriter.pas", pois o tamanho mínimo dessa tag foi definida com 12. Ao consultar o "pcnNFeW.pas", o campo era definido com tamanho mínimo de 0, e por isso não gerava o alerta: Diante disso, ajustei o "ACBrNFe.XMLWriter.pas" para que defina o tamanho mínimo com 0 também, onde dessa forma a nota foi autorizada sem problemas. Deixei em anexo a unit com a correção. Além da correção reportada nesse tópico, tem também os ajustes mencionados no seguinte tópico: Poderiam avaliar as modificações e subir para o SVN por gentileza? Obrigado! ACBrNFe.XmlWriter.pas

Segue em anexo. Ressalto que nessa versão eu sobrescrevi o que o Italo fez no último commit na montagem da tag pDif, então só precisa confirmar se fica OK dessa maneira que eu fiz. ACBrNFe.XmlWriter.pas

Olá Juliomar! Sim, alterei o tamanho dos campos conforme o tamanho máximo que o manual permite. Com isso deixou de exibir os alertas e a nota foi autorizada. Porém, percebi que foi feita uma modificação hoje mesmo pelo Ítalo, que corrige uma das tags (pDif). Então vou deixar aqui o trecho que código que modifiquei para que possa ser validado qual a melhor alternativa: case NFe.Det[i].Imposto.ICMS.CST of cst02 : begin xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'qBCMono', 01, 15, 1, NFe.Det[i].Imposto.ICMS.qBCMono, DSC_QBCMONO)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'adRemICMS', 01, 07, 1, NFe.Det[i].Imposto.ICMS.adRemICMS, DSC_ADREMICMS)); xmlNode.AppendChild(AddNode(tcDe2, 'N17', 'vICMSMono', 01, 15, 1, NFe.Det[i].Imposto.ICMS.vICMSMono, DSC_VICMSMONO)); end; cst15 : begin xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'qBCMono', 01, 15, 1, NFe.Det[i].Imposto.ICMS.qBCMono, DSC_QBCMONO)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'adRemICMS', 01, 07, 1, NFe.Det[i].Imposto.ICMS.adRemICMS, DSC_ADREMICMS)); xmlNode.AppendChild(AddNode(tcDe2, 'N17', 'vICMSMono', 01, 15, 1, NFe.Det[i].Imposto.ICMS.vICMSMono, DSC_VICMSMONO)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'qBCMonoReten', 01, 15, 1, NFe.Det[i].Imposto.ICMS.qBCMonoReten, DSC_QBCMONORETEN)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'adRemICMSReten', 01, 07, 1, NFe.Det[i].Imposto.ICMS.adRemICMSReten, DSC_ADREMICMSRETEN)); xmlNode.AppendChild(AddNode(tcDe2, 'N17', 'vICMSMonoReten', 01, 15, 1, NFe.Det[i].Imposto.ICMS.vICMSMonoReten, DSC_VICMSMONORETEN)); if NFe.Det[i].Imposto.ICMS.qBCMono <> 0 then begin xmlNode.AppendChild(AddNode(tcDe2, 'N15', 'pRedAdRem', 01, 05, 1, NFe.Det[i].Imposto.ICMS.pRedAdRem, DSC_PREDADREM)); xmlNode.AppendChild(AddNode(tcStr, 'N33b', 'motRedAdRem', 01, 01, 1, motRedAdRemToStr(nfe.Det[i].Imposto.ICMS.motRedAdRem), DSC_MOTREDADREM)); end; end; cst53 : begin xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'qBCMono', 01, 15, 1, NFe.Det[i].Imposto.ICMS.qBCMono, DSC_QBCMONO)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'adRemICMS', 01, 07, 0, NFe.Det[i].Imposto.ICMS.adRemICMS, DSC_ADREMICMS)); xmlNode.AppendChild(AddNode(tcDe2, 'N15', 'vICMSMonoOp', 01, 15, 0, NFe.Det[i].Imposto.ICMS.vICMSMonoOp, DSC_VICMSMONOOP)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'pDif', 01, 07, 0, NFe.Det[i].Imposto.ICMS.pDif, DSC_PDIF)); xmlNode.AppendChild(AddNode(tcDe2, 'N43', 'vICMSMonoDif', 01, 15, 0, NFe.Det[i].Imposto.ICMS.vICMSMonoDif, DSC_VICMSMONODIF)); xmlNode.AppendChild(AddNode(tcDe2, 'N39', 'vICMSMono', 01, 15, 0, NFe.Det[i].Imposto.ICMS.vICMSMono, DSC_VICMSMONO)); end; cst61 : begin xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'qBCMonoRet', 01, 15, 1, NFe.Det[i].Imposto.ICMS.qBCMonoRet, DSC_QBCMONORET)); xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'adRemICMSRet', 01, 07, 1, NFe.Det[i].Imposto.ICMS.adRemICMSRet, DSC_ADREMICMSRET)); xmlNode.AppendChild(AddNode(tcDe2, 'N17', 'vICMSMonoRet', 01, 15, 1, NFe.Det[i].Imposto.ICMS.vICMSMonoRet, DSC_VICMSMONORET)); end; end; Qualquer dúvida estou à disposição!

Olá pessoal, tudo bem? Depois que atualizei o ACBR para a revisão 42300 do dia 20/10/2025 começaram a ser apresentados alertas na validação de notas com ICMS monofásico. Ao avaliar o problema, peguei como base a montagem da tag "pDIF" do grupo ICMS53. No meu sistema, configurei com 90, sendo que no XML monta "90.0000". Com isso, está tendo um alerta de que o campo tem o tamanho maior do que o preenchido. Lá no ACBrNFe.XmlWriter.pas temos o trecho que monta a tag "pDif" no grupo do ICMS53 (Monofásico): xmlNode.AppendChild(AddNode(tcDe4, 'N15', 'pDif', 01, 5, 0, NFe.Det[i].Imposto.ICMS.pDif, DSC_PDIF)); Nesse caso, o ACBr vai validar que o tamanho máximo do valor desse campo seja 5. Mas lá na NT, o tamanho do campo é "3v2-4", onde eu entendo que sejam 3 inteiros e de 2 a 4 decimais, podendo o tamanho do campo chegar até 7, e não 5. Nesse caso, não teria que fazer o mesmo tratamento que temos na montagem da tag "pICMS" por exemplo? Onde o tipo do campo é "FormatoValor4ou2" e o tamanho é montado dinamicamente: xmlNode.AppendChild(AddNode(FormatoValor4ou2, 'N16', 'pICMS', 01, IfThen(FpUsar_tcDe4, 07, 05), 1, NFe.Det[i].Imposto.ICMS.pICMS, DSC_PICMS)); Ou ainda na montagem da tag "pIBSUF"? Onde o tipo continua sendo "tcDe4" mas o tamanho está fixo em 7, permitindo 3 inteiras e 4 decimais: Result.AppendChild(AddNode(tcDe4, 'UB18', 'pIBSUF', 1, 7, 1, IBSUF.pIBSUF, DSC_PIBSUF)); Me parece que isso resolveria. Só que não vi nenhuma modificação nisso recentemente, mas após atualizar o ACBr começou a apresentar essa validação de alerta quando tenho um pDif de 10% ou maior. Aí não estou entendendo como antes não estava apresentando esse alerta. Alguém consegue me dizer se minha análise está errada e o que preciso fazer pra validar corretamente uma nota com pDif maior ou igual a 10%? Vale lembrar que o pDif é só um exemplo, mas temos outros campos das 4 CST's do ICMS monofásico que também estão assim. Estou anexando um XML que não consigo autorizar e também a NT em que me baseei para a análise. Desde já agradeço pela ajuda. NT2023.001v1.60-Tributação monofásica dos combustíveis.pdf 41251113284396000198550020000003121381083205-nfe.xml

Maravilha! Muito obrigado pelas informações e correção!

Entendi. Vou me organizar para efetuar a troca. Até lá, segue em anexo o arquivo com a modificação sugerida. Se puder subir no SVN por favor, agradeço muito! ACBrECFVirtual.pas

Bom dia Juliomar, obrigado pela resposta. Você fala de usar o TACBrNFe, certo? Se sim, vou avaliar aqui pra que possamos fazer essa migração no futuro. Mas até que eu não faça essa migração eu precisaria dessa correção mesmo, seria possível seguir com as sugestões que dei? Obrigado!

Olá pessoal, tudo bem? Estou investigando uma situação no meu PDV e encontrei um trecho de código que imagino que possa ser melhorado no ACBR, e que de quebra resolve meu problema. O trecho de código em questão é no fonte ACBrECFVirtual.pas, no método TACBrECFVirtualClassCupom.SetDescAcresSubtotal. Logo no início deste método, há uma validação comparando se wDescAcresSubtotal é igual ao que veio no parâmetro AValue, e se for, cai fora do método. No entanto, a propriedade wDescAcresSubtotal é Double e variável AValue é Currency, causando problemas na comparação mesmo que os valores sejam idênticos, conforme imagem: Uma solução que se mostrou eficaz pra mim foi usar o método ComparaValor da unit ACBrUtil.pas para essa comparação, onde assim a comparação retorna o resultado correto: No código, ficaria assim: Diante disso, concordam em alterar a forma da comparação? Ou talvez têm alguma outra sugestão sobre como fazer essa comparação bater? Até pensei em trocar a variável wDescAcresSubtotal pra Currency, mas aí pode causar problemas nos outros cálculos da procedure, então a alteração com menos impacto na minha visão é a que sugeri. Desde já agradeço!

Olá pessoal! Somente para dar retorno aqui, há algum tempo não temos mais reclamação sobre esse problema. O que identificamos aqui é que tínhamos uma personalização para o cliente em questão onde era criado um formulário que implementava uma interface para busca de algumas informações personalizadas da venda. Esse formulário era apresentado como modal, e aparentemente em algumas situações ele ficava por traz da aplicação, dando a impressão de que o PDV estava travado. Dentro do nosso processamento do TEF usávamos vários Application.ProcessMessages e também algumas exibições de mensagens com MessageDlg. Imagino que em algum momento, o uso em conjunto de tudo isso acabava causando o travamento. As ações que tomamos aqui foram: - Ajuste na destruição do formulário modal e remoção do uso da interface. - Remoção do Application.ProcessMessages no processamento do TEF. - Substituição da apresentação de mensagens com MessageDlg por mensagens internas nossas, que no final das contas usam o Application.MessageBox. - Remoção de um gauge que tínhamos para apresentar informações do andamento da transação, sendo que agora estamos apresentando em um TLabel no formulário principal do PDV. Não sei dizer o que exatamente eliminou nosso problema, mas após esses ajustes não tivemos mais relatos. Diante disso, deixo aqui essas informações para que, caso mais alguém tenha um problema parecido possa usar como base para correção. Agradeço a ajuda de todos. O tópico pode ser finalizado.

Olá Thiago. Pelo que sei, a SEFAZ-SP não está mais atualizando aquele emulador. Foi orientado pra gente comprar um aparelho físico para realizar os testes, mas até onde entendi vai depender que os fabricantes dos aparelhos disponibilizem alterações para que possamos enviar esses novos meios de pagamento. Deixei nosso sistema preparado pra enviar quando os aparelhos estiverem aptos, mas até o momento não fizemos nenhum envio com essas novas formas de pagamento.

Show, muito obrigado!

Boa tarde, tudo bem? Estamos fazendo os testes para a homologação do PAF-ECF utilizando a impressora Bematech MP 4000 TH FI e encontramos uma inconsistência na leitura do estado da impressora. Encontrei esse tópico: Pelo que pude entender, foi solicitado que sejam tratados os casos em que a impressora só entra em estado de redução Z às 02:00. Entretanto, em ACBrECFBematech.pas, método TACBrECFBematech.GetEstado temos o seguinte trecho: fpEstado := estLivre ; DataMov := Self.GetDataMovimento; if (DataMov > 0) then begin DataHora := Self.GetDataHora; Data := DateOf(DataHora); if (DataMov < Data) and ((HoursBetween(Data, DataHora) > 2)) then fpEstado := estRequerZ ; end; Com esse código, a função vai retornar o estado "estRequerZ" somente às 03:00, pois ele valida se a diferença entre as duas datas é maior do que 2 horas. Diante disso, solicito alteração para que seja considerado a diferença maior ou igual a 2, fazendo com que às 02:00 a impressora já entre no estado "estRequerZ". A alteração deixaria o código assim: fpEstado := estLivre ; DataMov := Self.GetDataMovimento; if (DataMov > 0) then begin DataHora := Self.GetDataHora; Data := DateOf(DataHora); if (DataMov < Data) and ((HoursBetween(Data, DataHora) >= 2)) then fpEstado := estRequerZ ; end; Se puderem avaliar por favor, agradeço.

Boa tarde Italo, Perfeito, muito obrigado!