Túlio de Pádua

Pessoal, tenho um clientdataset com uma coluna numérica (BCD), e preciso filtrar apenas os registros onde os valores sejam maiores que zero. Para isso uso o filter, e sempre funcionou. Mas apareceu um cliente onde um relatório parou de funcionar, e analisando descobri que o problema era nessa filtragem. Na empresa, um outro único computador também apresenta esse problema. Imagine os seguintes registros num cds: MEUCAMPO (ftBCD) 15 20 35 84 108 18 56 65 -86 14 Quando eu aplico "Filter := MEUCAMPO > 0", nesses PCs nenhum registro sobra no cds. É como se ele não encontrasse nada maior que zero. Além de ser um filtro extremamente simples e funcionar corretamente na maioria dos PCs que testei, não consigo imaginar o motivo disso dar errado. Campos do tipo inteiro, float, string etc estão funcionando corretamente. Se eu fazer um loop nos registros contando os que possuem esse campo com valor maior que zero também funciona, o problema é realmente no filter. Anexei um exe de exemplo que fiz. Ao rodar no meu pc, tudo certo. Ao rodar nesse outro pc, não retorna nenhum registro. Se alguém já viu algo parecido ou se tiver alguma ideia do que pode ser. Teste.zip

Eu fiz um teste agora, e consegui autorizar uma nota em MG. Parece que resolveram meu problema inicial, que eram as novas tags dessa NT.

Realmente está retornando esse erro aí. Estava funcionando, provavelmente o pessoal deve estar mexendo alguma coisa no servidor de MG de novo.

Bom dia, estou enfrentando um problema com a implementação da NT 2021.001 (CTe/CTe-OS/GTVe), em relação à alteração do campo de UF do CTe-OS (rodoOS->veic->UF). Esse campo passou a ser de preenchimento opcional, mas ao tentar transmitir um CTe-OS sem informá-lo o XML não é validado: A tag que deveria não ser criada, está sendo criada vazia: Na consulta de schema dá pra ver que esse campo já não é mais obrigatório: Fiz um teste, alterando no arquivo pcteCTeW.pas o seguinte trecho: Disso: Gerador.wCampo(tcStr, '#16', 'UF', 02, 02, 1, CTe.infCTeNorm.rodoOS.veic.UF, DSC_CUF); Para: Gerador.wCampo(tcStr, '#16', 'UF', 02, 02, 0, CTe.infCTeNorm.rodoOS.veic.UF, DSC_CUF); Assim não foi mais gerado erro de schema e o documento foi autorizado corretamente.

Acho que isso está errado, se olhar no schema o campo existe corretamente para esse CST, e a nota não seria autorizada em SVC. Talvez esse site esteja validando para produção, não sei. Vou ver se realmente tem algo de errado ou aguardar MG dar uma estabilizada.

Tu tá em MG? Tá conseguindo autorizar essas notas?

Acabaram de responder, segundo eles já está implementado.

Qualquer das novas tags geram a rejeição, sem elas não dá problema. O XML anexado contém as tags de ST desonerado (vICMSSTDeson e motDesICMSST), detalhe que trocando para o ambiente SVC esse mesmo XML foi autorizado sem problemas. Os schemas estão corretos sim, até porque senão poderia dar erro de validação local, e a rejeição é recebida do servidor. Eu abri um chamado questionando isso, pra saber se está ou não tudo certo no servidor, aguardando eles responderem. 31210905405941000129550010000050381690456253-nfe.xml

Boa tarde, estou implementando as alterações da NT 2020.005, mas ao tentar autorizar em homologação uma NFe com as novas tags, a Sefaz rejeita: 215 - Rejeicao: Falha no esquema XML Estou testando em MG, se eu usar a contingência SVC dá tudo certo. será que MG ainda não implementou essa NT? Mais alguém passando por esse problema aqui no estado?

O artigo aprofunda bastante, e cita num ponto algo que pode resolver parte no meu problema: "If space or speed are not as important as accuracy, use the Extended type throughout, because Delphi also uses it internally in most system functions." Usar o tipo extended realmente fornece uma precisão melhor: procedure TForm1.Button4Click(Sender: TObject); var val1: Double; val2: Extended; begin val1 := 1114313.68; val2 := 1114313.68; Memo1.Lines.Clear; Memo1.Lines.Add(FormatFloat('###,###,##0.00########', val1)); Memo1.Lines.Add(FormatFloat('###,###,##0.00########', val2)); end; O resultado da formatação acima seria: 1.114.313,6799999999 1.114.313,68 Com algum trabalho eu poderia alterar para que esse campo em tela mostrasse o valor a partir de uma variável extended, mas no ACBr como as variáveis são double, no DANFe o valor ainda sairia com a distorção. Ou seja, sem resolução total. Isso é para o valor unitário do produto em NFes, e sim, alguns usuários necessitam de toda essa quantidade de casas decimais, o que não me permite então fazer o uso de currency. E o outro problema é tentar fazer usuário leigo entender como um tipo flutuante funciona, e assim o valor que ele digita não é exibido fielmente na tela e no DANFe. De qualquer forma obrigado, eu vou manter isso assim mesmo.

Tudo certo Italo.

Bom dia Italo, eu anexei o do CTe OS e o do CTe assíncrono. CTe síncrono eu não tenho, pois consigo fazer emissão de CTe apenas para MG, que não tem webservice para síncrono ainda. 1-pro-lot ----- CTeOS.xml 311000131383853-pro-rec ----- CTe Assíncrono.xml

ACBrCTeWebServices.pas

Pessoal, fui fazer um teste com o CT-e OS, e percebi que ao transmitir a rotina de envio do ACBr está gerando uma exceção, mesmo o conhecimento sendo autorizado. Testei com o programa de exemplo e o resultado também acontece: Veja que mesmo o retorno estando correto (uso autorizado), o log trata como se houve erro de transmissão. Debugando cheguei ao trecho abaixo, na rotina TratarResposta (TCTeRecepcao.TratarResposta) // Verificar se a GTV-e foi autorizado com sucesso Result := (FCTeRetornoSincrono.cStat = 100) and (TACBrCTe(FPDFeOwner).CstatProcessado(FCTeRetornoSincrono.protCTe.cStat)); O problema é que esse result aí está ficando como falso, pois o cStat que está sendo verificado é o do lote, e o seu valor é 104. Para verificar o do CTe OS, deveria pegar o cStat do protCTe, algo assim: // Verificar se a GTV-e foi autorizado com sucesso Result := (FCTeRetornoSincrono.protCTe.cStat = 100) and (TACBrCTe(FPDFeOwner).CstatProcessado(FCTeRetornoSincrono.protCTe.cStat)); Se concordarem faço as alterações e anexo aqui, mas realmente parece um erro.

Sim, aparentemente tudo certo. Obrigado.

Não, na verdade não foram informados esses decimais, o valor digitado foi "1.114.313,68", apenas com dois decimais. O problema é que ao digitar o valor no campo, ele é alterado para esse número com mias decimais aí. Eu atribuo isso ao problema de precisão que o float possui, mas queria ver se tem alguma maneira de contornar mesmo.

No banco de dados ele está delimitado (15,10) como numérico. Isso aí é do clientdataset mesmo.

Pessoal, tenho um campo para informação de preço que possui 10 casas decimais. Isso no clientdataset gera um campo do tipo float. Nesse campo eu uso a máscara "###,###,##0.00########", ou seja, para a parte dos decimais exibe sempre duas casas, e quantas mais existirem até 10. Entretanto alguns valores quando digitados acabam sendo alterados numa tentativa de arredondamento pelo cds. Por exemplo, ao se digitar "1.114.313,68" ele aparece como "1.114.313,6799999999": Isso vai se repetir também no DANFe: Eu sei que valores de ponto flutuante podem gerar distorção nos valores, mas será que não existe algum outro tipo de máscara, algum componente que consegue tratar isso melhor, sei lá, pra evitar esse tipo de situação?

Pessoal, o DACTE para um CTE OS estava exibindo o título DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico). Alterei para exibir DACTE OS (Documento Auxiliar do Conhecimento de Transporte Eletrônico para Outros Serviços), caso seja esse o modelo. Um ajuste pequeno, mas um cliente exigiu isso. O modelo em Fast já está correto. ACBrCTeDACTeRLRetrato.pas

Configuração para o Indy: Params := TIdMultiPartFormDataStream.Create; Params.AddFile('file[]', 'C:\Desenvolvimento\Teste_Indy\31200305405941000129550010008979891610757381-nfe.xml', 'application/xml'); Params.AddFormField('query', '{"boxe/File":true}', 'UTF-8', 'application/json'); IdHTTP1.Request.CustomHeaders.Clear; IdHTTP1.Request.CustomHeaders.Values['Authorization'] := 'Bearer ' + token; IdHTTP1.Request.Accept := 'application/json'; IdHTTP1.Request.ContentType := 'multipart/form-data'; Assim deverá funcionar.

Cara, eu também estou tentando fazer essa parte da implementação dessa API durante essa semana, e a mesma coisa, sempre tenho o retorno 500. Já testei com Indy, RestClient, e outros componentes como o ICS. Nada funciona, apenas ao testar pelo Postman.

Resolvido, encontrei o problema, era algo na minha aplicação mesmo.

Criei um exe onde eu posso gerar ambos os comprovantes, e, deu certo, Vou continuar revisando meus códigos aqui.

Não Juliana. Mas não é a mesma coisa, pois são dois exes diferentes. Seria o mesmo que eu executar minha aplicação por duas vezes diferentes para testar os comprovantes, e isso me daria um teste positivo. O problema é quando dois tipos são gerados em sequência, o segundo sai estragado. Vou tentar gerar um exe com apenas a geração dos comprovantes e ver se ocorre o problema.

Olá, há algumas semanas após atualizar os fontes do ACBr, meu sistema passou a gerar Invalid Barcode onde deveria ser impresso o código de barras do DAMDFe em Fast Report, e também no DACTe em Fast. Se após a abertura do sistema, for gerado um DAMDFe, ele é gerado corretamente, e vai dar problema com os DACTes. Se após a abertura do sistema, for gerado um DACTe, ele é gerado corretamente, e vai dar problema com os DAMDFes. Ou seja, o segundo modelo de comprovante é o que vai ser gerado com problemas. O que já fiz: removi e reinstalei os fontes do ACBr; removi e instalei os fontes mais novos do ACBr; removi e reinstalei meu Fast Report. Nada deu certo. Não consigo achar uma lógica para isso ocorrer, se alguém já passou por algo assim, ou tenha alguma ideia.