Balena

Olá! Como vi que o tópico não teve solução, cá estou eu com o mesmo problema. Alguém teve esse problema e conseguiu resolver? Ou sabe como resolver? Tentei alterar a biblioteca já e afins, mas sem sucesso.

TabEst1.db Anexado. Obrigado!

Posso lhe mandar um dos arquivos que estou tentando abrir ?

Pior que fiz @Juliomar Marchetti O erro dá no passo 12, na hora de abrir o fdTable. Até chutei tentando alterar no driver a sequencia de agrupamento de ASCII para as outras opções e também não tive sucesso. Quanto a ConnectionString, onde que utilizo ela? Hoje no fdConnection eu só seto as propriedades e abro o fdtable. Se eu setar o nome errado do arquivo até tenho a mensagem que o arquivo não foi encontrado, então acho que estou no caminho, porém agora estáo sem ideias de como resolver.

@flexsistemas teve sucesso? Estou tentando acessar uma base paradox e via ibexpert eu consigo acesso aos dados e via sistema só tenho a mensagem: [FireDAC][Phys][ODBC][Microsoft][Driver ODBC para Paradox] A tabela externa não está no formato esperado.. É a primeira vez que acesso paradox, então é bem provável que seja alguma inexeperiência minha mesmo. Alguém poderia ajudar?

É uma forma de pensar, bem como se você não usar a DLL não precisará distribuí-la junto de seu .EXE Enfim, pode fechar o tópico. Obrigado pela ajuda.

Me expressei mal Daniel. Mas penso que é responsabilidade do componente controlar isso. Ele não deve ser responsável por fazer com que em alguns minutos 670mb de arquivos duplicados sejam gerados no servidor. Quanto a melhor opção, aí penso que é opção pessoal, para a nossa situação na empresa foi muito mais simples criar o pré-requisito do usuário ter o windows atualizado. Volta e meia tínhamos problemas com DLL com versão incompatível em cliente, ou então com erros como o citado abaixo: Se não me engano tínhamos um problema com o envio de e-mail também, mas agora a minha memória não ajudou. Depois da migração total para o WinCrypt os processos que o utilizam ficaram bem mais estáveis. Claro que não é perfeito, mas para o nosso caso a experiência com ele foi, sem dúvidas, muito melhor que o OpenSSL. Mas Ok, estou vendo que você não vai querer subir. Vou criar uma versão paralela para nosso sistema e, caso tenhamos problemas, irei voltar aqui para relatar. Obrigado.

Olá! Testamos em variados bancos de dados com variados certificados digitais, todos A1, e resolveu. Até indicamos a nossos clientes que adquiram o A1 ao invés do A3. Nosso caso pode ser um pouco diferente, pois não temos o certificado instalados nos computadores, nem fisicamente nas estações. Armazenamos os dados em banco e passamos ao componente para os DadosPFX, NumeroSerie e Senha. Preferimos assim pois facilita muito o operacional. Das opções de: Voltar para OpenSSL ou apagar manualmente, penso que ambas são (bem) ruins, pois deve ser responsabilidade do componente fechar a store da forma adequada. Para nós resolveu e somente estamos aguardando o parecer de vocês se vão subir para o repositório para por para produção. Se decidirem por não subir iremos manter a alteração no nosso. Obrigado!

Olá! Arquivo em anexo. ACBrDFeWinCrypt.pas

Obrigado! Eu que agradeço

Olá! Depois desta alteração: A linha em vermelho foi incluída nos PrepareReport: Ela quebrou nossas emissões de documentos pois utilizamos o FileName do frxReport que retorna preparado e agora ela está retornando em branco. Todos locais do nosso sistema, desde sempre, é setado o FastFile do ACBrNFeDANFEFR. Realmente não ficou claro o porquê desta linha sendo que o LoadFromFile do componente é feito em cima do FastFile e não do NomeDocumento. (Marcação em verde) Eu corrigi nosso problema com um simples: if NaoEstaVazio(DANFEClassOwner.NomeDocumento) then frxReport.FileName := DANFEClassOwner.NomeDocumento; Mas, como no change-log não tem nada, nem no commit, gostaria de saber se devo passar a informar nas duas propriedades o mesmo valor ou se esta alteração está equivocada. Obrigado a todos! ACBrNFeDANFEFRDM.pas

Olá Outro ponto que gostaria de levantar, ainda no ISS.net (Abrasf V1), ao carregar o XML, todo arquivo RPS está retornando um registro a mais do que ele efetivamente tem, o ultimo, sempre vazio. O arquivo basicamente tem o layout assim: <EnviarLoteRpsEnvio ...> <LoteRps Id="999"> ... <ListaRps> <Rps Id="1"> </Rps> <Rps Id="2"> </Rps> </ListaRps> </LoteRps> </EnviarLoteRpsEnvio> Este deveria retornar 2 registros(ID 1 e 2), porém retorna 3. Este ultimo, todo vazio. A meu ver o problema está no LoadFromString. Ele por sua vez tem o PosRPS que identifica se tem mais alguma tag de RPS para ler. Sendo ele: function PosRPS(AProvedor: TnfseProvedor): Integer; begin TamTAG := 5; if (VersaoNFSe < ve200) and (AProvedor <> proAgili) then begin Result := Pos('</Rps>', AXMLString); // Provedor ISSDSF if Result = 0 then Result := Pos('</RPS>', AXMLString); if Result = 0 then //Equiplano Result := Pos('</rps>', AXMLString); // Provedor Governa if Result = 0 then begin Result := Pos('</LoteRps>', AXMLString); TamTAG := 9; end; end else begin // Se a versão do XML do RPS for 2.00 ou posterior existem 2 TAGs <Rps>, // neste caso devemos buscar a posição da segunda. Result := Pos('</Rps>', AXMLString); Result := PosEx('</Rps>', AXMLString, Result + 1); end; end; Peço atenção ao bloco com o comentário "// Provedor Governa". Este bloco, ao final, vai procurar pelo finalizador do "LoteRPS". Vejam que, ao final, do arquivo exemplo, só restará o "resto" do XML, ou seja: </ListaRps> </LoteRps> </EnviarLoteRpsEnvio> Assim, ele acha que há mais um RPS gerando um registro em branco no ACBrNFSe.NotasFiscais. O correto, já que é apenas para o provedor Governa, seria mudar de: if Result = 0 then begin Result := Pos('</LoteRps>', AXMLString); TamTAG := 9; end; Para: // Provedor Governa if ((Result = 0) and (AProvedor = proGoverna)) then begin Result := Pos('</LoteRps>', AXMLString); TamTAG := 9; end; Aproveitei e anexei o arquivo. Pra mim, que estou mexendo agora ISS.Net resolveu, não sei como serão com os demais provedores. ACBrNFSeNotasFiscais.pas

Olá! Ao ler o XML da ISS.Net também deve considerar o nível anterior de onde podem estar os dados para a tag "IdentificacaoTomador", como é feito com as demais tags. Ex: Tomador. if (Leitor.rExtrai(3, 'Tomador') <> '') or (Leitor.rExtrai(3, 'TomadorServico') <> '') or (Leitor.rExtrai(2, 'Tomador') <> '') or (Leitor.rExtrai(2, 'TomadorServico') <> '') then Portanto, troquei de: if Leitor.rExtrai(4, 'IdentificacaoTomador') <> '') then Para: if (Leitor.rExtrai(4, 'IdentificacaoTomador') <> '') or (Leitor.rExtrai(3, 'IdentificacaoTomador') <> '') then Arquivo em anexo para analise. pnfsNFSeR.pas

Desculpe Italo, atualizei agora e está sendo utilizado a Natureza da Operação. Falando exclusivamente da IPM, este é outro campo que não parece ser o mais adequado, visto que existe o CodigoTributacaoMunicipio. Anexei o atual alterado para analise. Obrigado. pnfsNFSeW_IPM.pas

Olá senhores. A tag "situacao_tributaria" do serviço, para a IPM, é preenchida com o NFSe.RegimeEspecialTributacao, convertido pelo RegimeEspecialTributacaoToStr. Porém os valores não correspondem aos valor previstos pela empresa. (manual https://www.nfs-e.net/datacenter/integrador/Manual Eletron V2.pdf - Página 18). Que são de 0 a 10 ou 15. Enquanto o RegimeEspecialTributacaoToStr vai de 0 a 14, além das descrições não baterem. Sugiro, então, alterar para o campo para o NFSe.Servico.CodigoTributacaoMunicipio. Como NFSe.RegimeEspecialTributacao é do cabeçalho, não vejo problemas em trocar pelo campo indicado. Portanto, alterei o arquivo pnfsNFSeW_IPM.pas de: Gerador.wCampoNFSe(tcStr, '', 'situacao_tributaria', 1, 4, 1, RegimeEspecialTributacaoToStr( NFSe.RegimeEspecialTributacao), ''); Para: Gerador.wCampoNFSe(tcStr, '', 'situacao_tributaria', 1, 4, 1, NFSe.Servico.CodigoTributacaoMunicipio, ''); Obrigado pnfsNFSeW_IPM.pas

Olá senhores. Gostaria de saber se há algum motivo específico para o CST ter o padrão "cst00" e não "cstVazio", ou então sem padrão mesmo, como é feito com o CSOSN. Peço isso pois ao carregar um XML eu não sei se ele está com CST ou CSOSN preenchidos. Aí quando o XML vem com CSOSN o CST também é preenchido como "cst00" por ter este valor como seu padrão. Assim, sempre que vou ler o CST, antes tenho que validar se tem algo no CSOSN, pois posso considerar que foi informado 00 erroneamente.

Dentro do pnfsNFSeR, ao carregar o XML padrão ABRASF v1 está carregando como CodigoMunicipio o campo CodigoTributacaoMunicipio ao invés do MunicipioPrestacaoServico, como é o padrão para este provedor. Alterei de: if FProvedor = proISSNet then NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoTributacaoMunicipio') else NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoMunicipio'); Para: if FProvedor = proISSNet then NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'MunicipioPrestacaoServico') else NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoMunicipio'); Como devo proceder para enviar a minha alteração para avaliação? Arquivo corrigido em anexo. pnfsNFSeR.pas

Opa... Tópico antigo mas é o mesmo problema do amigo que não respondeu mais. Simplesmente se acesso um form que tem o componente da "out of memory". Se tento incluir o componente a um form novo, projeto novo, as vezes da "out of memory", as vezes o delphi para de responde e fecha. Não passei pelo problema do midas, mas para garantir eu registrei ele. Não mudou em nada...

Nós até temos a DLL da Toledo, mas queríamos fazer tudo pelo ACBr mesmo, mas ta complicando assim.

Olá! Estamos com uma situação semelhante aqui na empresa. O cara colocou o carro dele sobre a balança e na "ultima resposta", no meio dos caracteres, apareceu o peso do carro dele, porém no peso deu 0,00 e na mensagem deu "Timeout...". Os parâmetros são aqueles que colocamos no AcbrBalancaTeste mesmo, pois confirmamos no software da balança, com o fabricante e no software antigo, todos estão com esses parâmetros, mas o ACBr não lê peso. Já passaram por algo semelhante?