elton.barbosa

Olá. Não ficou muito claro. Pode especificar quais valores não passam? O que precisa ser corrigido?

Olá. Você pode anexar também o log gerado pela LIB por favor?

Claro. Criei um chamado no nosso backlog, a saber, ACBR-8545. @Fernando Schuch, Muito obrigado pela contribuição. Assim que possível te dou um retorno aqui mesmo.

Criei um chamado no nosso backlog, a saber, ACBR-8540. Obrigado pela contribuição. Assim que possível vamos dar um retorno aqui mesmo.

Isso mesmo. A validação não passou por conta da letra "A" no meio da chave. Veja:

Olá jeffersonjunglaus, Conseguiu algum retorno do provedor?

Tópico fechado por falta de retorno do usuário

Você precisa verificar o manual e passar a configuração de fonte para o componente. No programa exemplo ilustra como fazer isso. O segundo parâmetro da função `ImprimirTexto` é a fonte. Veja a imagem abaixo:

Me parece fazer sentido a correção. Na verdade o FastStringReplace foi implementado pelo Alexandre Machado e tem vários testes unitários e de performance. Seria interessante verificar novamente se temos alterações locais e, em caso positivo, os motivos. https://bitbucket.org/alex7691/delphi/src/master/FastStringReplace/ Não consegui reproduzir no momento, posso tentar verificar depois.

Atualização: As units relacionadas ao ACBrDI foram adicionadas no pacote "ACBr_NFe". Isso permite colocar esse pacote como dependência no Lazarus para especificar o uso dessas units. Também faz com que a geração do arquivo DCU seja feito pelo ACBrInstall.

Subi suas alterações para o SVN na Revisão 42927. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema. Obrigado.

Subi suas alterações para o SVN na Revisão 42926. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema. Obrigado.

Precisamos fazer aqui na pcnConversaoNFe, o mesmo que fizemos com a ACBrDFe.Conversao. Ou seja, fazer os tipos da pcnConversaoNFe apontar para os tipos da ACBrNFe.Conversao. Por conta do evento do Dia do ACBr e dos esforços para a Reforma Tributária, não conseguimos terminar isso antes. Vamos verificar, mas toda ajuda é bem vinda.

Criei um chamado no nosso backlog, a saber, ACBR-8382. Obrigado pela contribuição. Assim que possível vamos dar um retorno aqui mesmo.

Criei um chamado no nosso backlog, a saber, ACBR-8381. Obrigado pela contribuição. Assim que possível vamos dar um retorno aqui mesmo.

Olá pessoal, Temos o prazer de informar um novo componente: ACBrSmartTEF. O componente ACBrSmartTEF foi desenvolvido para facilitar a integração com o SmartTEF. Ele permite, entre outras coisas, criar, consultar e cancelar ordens de pagamento. Veja mais sobre a parceria com a POS Controle nesse link aqui. Ouça mais sobre o POS Controle e o SmartTEF clicando AQUI Para saber como utilizar o componente ACBrSmartTEF, veja o tópico abaixo:

Muito obrigado pelo relato. Enviamos uma correção para o problema ao SVN.

Olá pessoal, Por favor deem atenção. Como sabem estamos aos poucos saindo das units "pcn". E um dos passos para fazermos isso foi criar uma unit chamada ACBrDFe.Conversao.pas (Veja aqui sobre). Mas essa unit tinha alguns problemas e mudanças de comportamento indesejados então precisamos refazê-la. Isso pode quebrar o seu código e por isso precisamos de sua atenção. TL/DR: A unit ACBrDFe.Conversao.pas não é uma cópia da pcnConversao.pas com outro nome. A pcnConversao.pas ainda funciona, mas quando você for utilizar a ACBrDFe.Conversao.pas, vai precisar fazer ajustes! Ainda está aí? Beleza, agora vamos aos detalhes. Em primeiro lugar queremos deixar claro que ela vai continuar sendo parte da migração para fora das units "pcn*" em especial a pcnConversao.pas. Vamos resumir aqui no entanto algumas alterações que foram feitas: A constante LineBreak foi removida. Se você precisa dela no seu código, use a constante que já vem no Delphi/Lazarus SLineBreak. Diversos tipos foram renomeados. Listamos abaixo alguns: TpcnTipoCampo = TACBrTipoCampo; TpcnTagAssinatura = TACBrTagAssinatura; TpcnTipoImpressao = TACBrTipoImpressao; TpcnTipoEmissao = TACBrTipoEmissao; TpcnTipoAmbiente = TACBrTipoAmbiente; TpcnProcessoEmissao = TACBrProcessoEmissao; TpcnTpEvento = TACBrTipoEvento; TpcteModal = TModal; TpcnTipoNFe = TTipoNFe; TpcnOrigemMercadoria = TOrigemMercadoria; TpcnCSTIcms = TCSTIcms; TpcnCSOSNIcms = TCSOSNIcms; TpcnCstPis = TCSTPis; TpcnCstCofins = TCSTCofins; TpcteTipoRodado = TTipoRodado; TpcteTipoCarroceria = TTipoCarroceria; TpcnUnidTransp = TUnidTransp; TpcnUnidCarga = TUnidCarga; TpcteProp = TtpProp; TpcnindIEDest = TindIEDest; TpcnRegTribISSQN = TRegTribISSQN; TpcnindIncentivo = TindIncentivo; TpcnRegTrib = TRegTrib; TpcnindRatISSQN = TindRatISSQN; TpcnindRegra = TindRegra; TpcnCodigoMP = TCodigoMP; As funções de conversões de tipos enumerados foram refeitas para seguir o padrão "Try-Parse". Esse é um padrão comum em linguagens de programação (incluindo o Delphi com as funções TryStrToDate e StrToDate). A função que tem no nome o prefixo "Try" realiza a verificação de uma possível conversão sem lançar exceções, retornando um booleano para indicar se a conversão foi bem-sucedida e armazenando o resultado, em caso de sucesso, em um parâmetro de saída. A função que não tem esse prefixo, gera uma exception quando o tipo não puder ser convertido. Essa função que inicia com "Try" substitui a função anterior que tinha um parâmetro "ok". Um dos objetivos de usar esse padrão é porque muitas pessoas nem se dão conta que é preciso verificar o parâmetro "ok" antes de usar o resultado da função. Como sabemos disso? Bem, este tipo de uso é frequente em contribuições e até mesmo no código antigo do ACBr... Almejamos assim deixar o código mais claro. Por enquanto o seu código que usa a pcnConversao vai continuar funcionando. Mas vai retornar vários warnings. A ideia é que você possa ir corrigindo no seu tempo. Nós mesmo estamos usando e isso vai aumentar a quantidade de warnings gerados que você vê ao compilar os componentes ACBr ... Por outro lado, vamos modificar o código do ACBr para deixar de utilizar a unit pcnConversao internamente o quanto antes. Os hints/warnings estão sendo ajustados na unit pcnConversao.pas para refletir o que foi delineado aqui. E como sempre, fiquem a vontade para reportar quaisquer problemas, sugestões e melhorias. Obrigado pela atenção pessoal.

Olá pessoal algumas atualizações sobre essa situação foram colocadas no seguinte tópico:

Enquanto a mudança está só no ACBr realmente estaria tranquilo. Mas a ideia é que minimize as quebras também nos softwares. Em primeiro lugar, porque nem todos ainda estão usando a ACBrXMLDocument. Segundo, ao invés de warnings estariam recebendo erros de compilação que não foi possível encontrar o tipo "XXXX".

Criada tarefa ACBR-8212

Criada tarefa ACBR-8211

criada tarefa ACBR-8209

Até onde eu sei, as orientações sobre cessação de uso continuam. Então sim, teria que dar a "baixa" do equipamento. Mas você precisa consultar o responsável fiscal pela empresa (talvez o contador) ou o fisco diretamente. E esse último, na área certa (compare com essa resposta).

Tópico fechado por falta de retorno do usuário