daSilva

Resposta da sefaz de GO: Me deram essa resposta após uma captura de dados feita em um computador que apresentava o problema. Quando o erro 12175 ocorre com A1, basta usar OpenSSL que resolve, só que estou tendo problemas com A3 e não encontrei nenhuma solução até o momento.

Tive problemas com o FireDac no Tokyo relacionados com as Transações linkadas ao FDConnection. Antes, quando você usava estas transações, bastava setar AutoCommit, AutoStart e AutoStop para true em TxOptions que ao dar um "DataSet.Post;" a informação era "commitada" no banco. No Tokyo, o AutoCommit para de funcionar após abrir uma Query que necessita de fetch parcial e só volta quando todos os registros são trazidos, nesse intervalo nada é "commitado" pelo Connection.Transaction . O Resultado disso são inúmeros dead locks e informações que só são salvas no fechamento do sistema. Eu resolvi isso setando um FDTransaction em Connection.UpdateTransaction para controlar os updates e inserts, deixando as consultas / fetchs para a Connection.Transaction.

Sim, utilizo há anos para enviar e receber arquivos e nunca tive problemas, exceto agora com as últimas atualizações. Sobre o manual, a contradição existe sim, veja abaixo como é calculado o DV do nosso número usando apenas 07 dígitos. Sobre colocar para ler 9 dígitos no retorno, (38~9) também é possível, mas isto apenas aumentará 02 dígitos à esquerda. Se o objetivo é trazer o DV do retorno, isto deveria ser (38~10), o que não acho uma boa ideia, já que o normal é vir sem o DV.

O Nosso Número SICOOB CNAB240 segundo o manual é 10 Dígitos: 09 + 01 DV. Posição Inicial 38 Antes funcionava normal por que lia na posição (40~7) ou seja, os 7 dígitos finais do nosso número. embora iniciasse na posição errada, finalizava na posição correta. então enquanto o nosso número fosse menor que 7 dígitos, tudo ok. 7560001300013T 0603059000000001603770000001750505014... Copy(Linha,40,7) = 0001750 O problema surgiu quando, para pegar a posição inicial correta, mudou-se a leitura de 40~7 para 38~7, mas dessa forma o final do nosso número ficou fora. 7560001300013T 0603059000000001603770000001750505014... Copy(Linha,38,7) = 0000017 Sugestões 1 ) Não alterar fpTamanhoMaximoNossoNum que está fixada em 7 pois o manual indica que nos cálculos de dígito verificador apenas 07 dígitos do nosso numero são utilizados, da direita para a esquerda, inclusive na montagem do campo livre são 8 dígitos (7 do nosso número + 1 DV). 2) No método "LerRetorno240", linha 537 deixar como estava, lendo na posição 40~7, pois se continuar em 38~7, cortará dois dígitos do nosso número. Obrigado.

Boa tarde Segue em anexo o arquivo com ajustes para reconhecer o retorno "10-BAIXA SOLICITADA" Funções Alteradas: "TACBrBancoob.CodOcorrenciaToTipo" linha 1059 "TACBrBancoob.TipoOCorrenciaToCod" linha 1100 Se alguém puder realizar o commit, obrigado. @Juliana Tamizou @Daniel Simoes ACBrBancoBancoob.pas

Estou tentando obter os Dados da Última Redução Z de um ECF DataRegis 3202DT, utilizando o protocolo FiscNet, no entanto algumas informações não são retornadas, por Exemplo "SubstituicaoTributariaICMS", "DataMovimento", "NumCOO" entre outros. Estou utilizando as dlls atualizadas, mas já testei com as dlls que veem no ACBR. Ao que me parece, as posições (337,14) do texto de retorno estão vindo zerados. Todos os itens vendidos foram Subst. Trib. (F1). ValorTexto="000000000001672196300000000000740000000000000000000000000000000000000000000000000000011100000003000700120017002500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000TTTTTTTTTTTTTTTT00000000003700000000000000000000000000000000000000000001007196000877051114";488 Segue em anexo o log e o arquivo .ini com os dados da última redução. LogAcbrECF.Txt UltimaReducaoZ.ini

Atualizei aqui e também está dando este mesmo problema, a unit AnsiStrings não existe no D2007. Essa unit não seria do Delphi 2009 ou superior ?