Data Lider

O código vai ser analisado para verificar se pode ser subido? precisa dessa confirmação caso contrário temos que tirar do nosso componente da acbr e passar para o sistema, porque sempre usamos a versão do svn original do acbr, não mantemos alterações próprias nos fontes. Desculpa o incômodo, obrigado.

Prezados, implementado o fechamento do dia, me deparei com informações importantes aqui do fórum e bem espalhadas sobre a redução Z. Alguns modelos pedem totalizadores depois da redução z (Alguns tópicos confirmam isso, conversei com o regys ele também afirmou). O ideal é utilizar tanto o DadosReducaoZ como UltimoDadosReducaoZ como em alguns tópicos. Na chamada da redução Z é interessante uma configuração de timeout para evitar problemas (blog do regys). Em algum tópico o Daniel posta um código para mesclar arquivos INI para permitir utilizar de forma mais simplificada as funções DadosReducaoZ e UltimoDadosReducaoZ. Diante dessas informações nós iniciamos uma solução para as questões acima, e tentamos inserir ela dentro da classe ACBrECFClass. Vou tentar explicar de forma simples. type TACBrECFDadosRZ = class public procedure CarregaINIReducaoZ(const DadosReducaoINI: TMemIniFile); procedure CarregaMesclandoINIReducoesZ(const Origem, Destino: string); end; TACBrECFClass public function ReducaoZ_Otimizada( DataHora : TDateTime = 0 ): TACBrECFDadosRZ; end; O procedimento CarregaINIReducaoZ foi implementada para fazer a leitura do arquivo INI gerado pela própria classe TACBrECFDadosRZ e se auto alimentar as informações, recuperando alíquotas e totalizadores, auto alimentando a classe, no meu ponto de vista a implementação ficou bem segura e respeitando os critérios do procedimento responsável pela geração MontaDadosReducaoZ. O procedimento CarregaMesclandoINIReducoesZ foi criado do zero mas usando a ideia da função já postada aqui no fórum, ela sempre tenta permanecer o valor do destino caso o valor da redução de origem seja nula, zero ou etc... A função ReducaoZ_Otimizada, realiza o procedimento de aumento de TimeOut postado pelo Regys além de armazenar o INI da função DadosReducaoZ, armazenar o INI da função DadosUltimaReducaoZ, mesclar os dois e carregar para o retorno da função a redução Z completo e acessível por pela classe TACBrECFDadosTZ, combinando as implementações anterior. Vantagens Utilizando a leitura pela classe e não pelo INI resultante do processo de mesclagem, as futuras alterações realizadas na classe são sentidas no momento da compilação (quando alterado no svn e atualizado), diferente da leitura pelo INI dentro do seus sistema, que somente depois que ser executado que uma alteração de tipo ou objeto seria identificada. Simplifica o processo da redução Z para quem não conhece os problemas de compatibilidade das impressoras. Evita o problema com TimeOut nas reduções Z. Função ReducaoZ Otimizada: function TACBrECFClass.ReducaoZ_Otimizada(DataHora: TDateTime): TACBrECFDadosRZ; var OldTimeOut: integer; ReducaoAntes, ReducaoDepois: string; begin ReducaoAntes := DadosReducaoZ; OldTimeOut := TimeOut; try TimeOut := 600; // 10 minutos ReducaoZ( DataHora ); finally TimeOut := OldTimeOut; end; ReducaoDepois := DadosUltimaReducaoZ; Result := TACBrECFDadosRZ.Create; Result.CarregaMesclandoINIReducoesZ(ReducaoAntes, ReducaoDepois); end; Como Utilizar: procedure TForm3.Button1Click(Sender: TObject); var Reducao: TACBrECFDadosRZ; begin Reducao := ACBrECF1.ECF.ReducaoZ_Otimizada(Now); try //Leitura das variáveis desejadas aqui. finally Reducao.Free; end; end; Estou anexando as units, e um demo que sem realizar a redução z, alimenta 3 memos e compara o arquivo ini Antes da Redução, Depois da Redução e o Arquivo Final Mesclado. (Demo em firemonkey²) ACBrSerial.zip DemoUtilizaçãoReducaoMesclagem.zip

Foi no Trunk 2? Aqui não chegou o update.

Isaque, durante uma inicialização hoje no desenvolvimento, o nosso aplicativo não identificou a ECF, porém no ACBr demo para o firemonkey estava identificando, investigando o componente, tinha mais uma linha com o MainForm sem a verificação de NIL, então adicionei, se puder subir novamente. Obrigado. Result := (ExibeMensagem or BloqueiaMouseTeclado) and (AguardaImpressao or ((TimeOut - TempoInicioMsg) > 1) ) and FormMsgControla and {$IFDEF FMX} Assigned(Application.MainForm) and Application.MainForm.Visible{$ELSE} Application.ShowMainForm{$ENDIF} ; Eu verifiquei o resto do arquivo e o ACBrECF.pas e não existe outra chamada do tipo, era para eu ter adicionado em todas as outras chamadas quando eu corrigi esse erro anteriormente, falha minha. ACBrECFClass.pas

Obrigado pelo esclarecimento. Esse fechamento, como disse no nosso caso, é porque a versão estava levando algumas units VCL, mas o exemplo não foi o caso da ACBr, e sim uma unit que veio de outro projeto, ai nossa unit scope era em Tools Options, ai acabou acontecendo isso. Bom ficou tudo claro, acho que da até para fechar o tópico.

O Firemonkey pode ser dividido em duas fases, XE2 até XE6 e XE7 até XE8, a criação foi realizada para a segunda geração. Como dito no tópico, nem todos os eventos foram vinculados ao TMainMenu, seria muito interessante se você que dispõe da versão XE5 cria-se outra variante do projeto para a primeira geração do Firemonkey além de vincular os restantes dos eventos, seria de grande ajuda, toda colaboração é bem vinda. Sem contar que é mais simples descer uma versão FMX2 para FMX1 do que fazer VCL toda para FMX. O XE7 foi um divisor de aguas em termos de dispositivo móvel, grandes alterações em classes que não eram alteradas desde o XE2, além da adição da propriedade "FMX.Edit.TEdit.ControlType" que trouxe mais competitividade para aplicativos no ANDROID e IOS criados no Delphi, que antes sofriam com desempenho. Isso é um assunto grande, mas contamos com sua colaboração.

Só confirmando, então basicamente quando definindo o conjunto completo, em vez de esperar a compatibilização por parte a IDE já toma a decisão correta? Versão Correta (Sua Implementação) {$IFNDEF NOGUI} {$IF DEFINED(VisualCLX)} ,QDialogs {$ELSEIF DEFINED(FMX)} ,FMX.Dialogs, System.UITypes {$ELSE} ,Dialogs {$IFEND} {$ENDIF}; Versão Indecisa ,Dialogs {$IFDEF FMX} System.UITypes //Sem adicionar o dialog para o FMX, o código fica sem saber quando é vcl ou fmx {$ENDIF}

Atenção para XE2+ Bom, essa semana estamos com necessidade de utilização de dois projetos em ambos ambientes VCL e FMX, enfrentamos alguns problemas de compilação das Unit ACBR, e principalmente versões geradas incorretas porque a SCOPE estava invertida no momento da compilação, então vou adicionar algumas informações para registro e pesquisa de usuários. Projeto 1 - VCL Projeto 2 - FMX Problema 1 - A ACBr.INC é unificada dentro da pasta de fontes do componente ACBrCupom, sempre quando necessário compilar um projeto de cada framework era necessário a troca. Solução - Excluído o arquivo, e adicionado na pasta dos projetos, cada um com sua definação VCL ou FMX. ------------------------ Problema 2 - Mesmo adicionado essas definições, existe o conflito de Units, eu posso ter "Dialog" para VCL (VCL.Dialog) como também para FMX (FMX.Dialog). Em quanto essa dúvida não for respondida não é possível compilar o projeto, para não ter que alterar todas as units do projeto, é necessário ir em Tools -> Options -> Delphi Options -> Libary e então preencher o campo "Unit scope names:" com o valor padrão, seja ele VCL ou FMX, assim é possível saber de qual dialogo será compilado. Isso gera problemas como compilar units VCL dentro do Firemonkey (sim é isso é possível) e trazer problemas futuros para o projeto, principalmente de você trabalhar como OSX que é o nosso caso, nos enfrentamos fechamento de janelas inexplicáveis por esse motivo. Solução - Deixar o campo em branco, e definir a Unit scope names no projeto, basta ir em "Project > Options > Delphi Compiler > Unit Scope Names" e então clicar em "..." e adicionar. (Lembrando que isso é armazenado por configuração, o use seja você precisa configurar tanto em Debug como Release).

Prezado, quando fiz a compilação do meu PAF, me deparei com os seguintes arquivo sem conversão para firemonkey, no caso os diálogos. ACBrBase (ACBrComum). ACBrECFNaoFiscal (ACBrSerial). ACBrECFSchalter (ACBrSerial). ACBrECFSweda (ACBrSerial). Os arquivos foram alterados e estão compilando normalmente agora. Já utilizando Trunk 2. ACBrComum e ACBrSerial.zip

Não pelo contrário, se for bem testado e funcional podemos deixar. Foi meio trabalhoso porque o aplicativo parece pequeno, mas não é, são muitas abas para desenhar e tudo mais. Porém conforme sugerido, eu tirei a madrugada de hoje para fazer a conversão, pouca coisa foi testada, mas o básico já foi testado. Estou postando o anexo logo, para caso alguém queira prosseguir, eu somente vou poder dar continuidade da aqui 1 ou 2 semanas. O que falta ? (Já está funcionando, e operando, são apenas pendências). Adicionar os eventos já convertidos aos seus respectivos itens do TMainMenu (20 minutos). Testar todas as rotinas. O código do TWebBrowser foi comentado, a pesar de existir o componente para o firemonkey, o código precisa ser atualizado. O que foi testado ? Comunicação Mensagens (PopUp Msg). Relatórios (Leitura X etc..) obs: Quem for testar, lembrar que a ACBr.INC tem que ser modificada para testar no firemonkey. Projeto completo em anexo. Firemonkey.zip

O meu deu a mesma coisa, fiz a instalação manual, e está tudo ok agora. (Windows 10).

Durante os testes achei um problema que a primeira vista parece ser na conexão, porém é na seguinte linha de código: {$IFDEF FMX} Application.MainForm.BringToFront ; {$ELSE} Application.BringToFront ; {$ENDIF} Quando é utilizada formulários que são exibidos antes do principal, como splash, configuração de conexão etc.. a variável MainForm ainda não foi contemplada com o formulário, a correção foi: {$IFDEF FMX} if Assigned(Application.MainForm) then Application.MainForm.BringToFront ; {$ELSE} Application.BringToFront ; {$ENDIF} Arquivo completo com a alteração em anexo. ACBrECFClass.pas

21/08/2015 - 13:12 - Atualização Boa tarde Isaque, conforme sugerido, eu fiz as alterações, porém mantive também o padrão VCL no FMX. Uma observação é que visando mantar poucas alterações para chegar ao resultado, e evitar vazamento de memória, mantive a linha que libera o formulário após a utilização, portanto o formulário que será enviado pelo usuário será estanciado no momento da utilização. Para sua sugestão foram criados dois eventos: OnCriarFormMsg - Utilizado para anexar o formulário que o usuário quiser ao componente no momento da chamada do procedimento FormMsgDoProcedure. OnDrawFormMsg - Utilizado no momento que a mensagem é enviada para ser desenhada, FormMsgPinta. O exemplo de utilização é: TForm1 = class(TForm) ACBrECF1: TACBrECF; Button1: TButton; procedure Button1Click(Sender: TObject); procedure ACBrECF1CriarFormMsg(var CustomForm: TForm); procedure ACBrECF1DrawFormMsg(const Mensagem: string); private { Private declarations } public { Public declarations } Msg: TForm2; //O tipo é do meu formulário personalizado. end; //############################################################# procedure TForm1.ACBrECF1CriarFormMsg(var CustomForm: TForm); begin Msg := TForm2.Create(Self); //Essa variável será liberada após uso CustomForm := Msg; end; procedure TForm1.ACBrECF1DrawFormMsg(const Mensagem: string); begin {Posso enviar para um TText ou TLabel, Canvas ou mesmo chamar um procedimento próprio que trata a mensagem. } Msg.Text1.Text := Mensagem; end; procedure TForm1.Button1Click(Sender: TObject); begin if not ACBrECF1.AcharPorta then ShowMessage('Falha') else ShowMessage(ACBrECF1.Porta); end; Os dois modos foram testados e estão funcionando corretamente, por padrão o funcionamento é utilizando o formulário igual o da VCL, se o usuário quiser ativar o recurso de formulário personalizado basta utilizar os eventos, ficou muito simples. Para ver um formulário personalizado com o logo da ACBr piscando clique no link https://youtu.be/hvHZnLyM9vE Qualquer dúvida estou a disposição, os novos arquivos estão em anexo. ACBrECFClass.pas ACBrECF.pas

Bom Dia, bom, de qualquer maneira fica o exemplo para quem não quiser criar o próprio formulário. Porque na VCL não permite criar o próprio formulário também? Eu penso no seguinte, fica mais simples para o usuário ter um componente que pode ser testado sem intervenção, se ele quiser personalizar a mensagem, então ele utiliza o recurso (que tem que ser implementado ainda), mas seria interessante mantar o código alterado para quem não quer se preocupar com esses detalhes. Até para quem está migrando da VCL e já está acostumado com o tipo de mensagem trabalhada pela ACBr. Você realmente acha um problema mantar os dois modos ?

Bom, depois de muitas horas, consegui colocar para funcionar a função de procurar porta no Firemonkey. Não tive a oportunidade de testar todo o componente, mas pelo que pude verificar a única coisa que impedia ele de funcionar como deveria era o formulário de diálogo do ACBrECF. Então venho aqui trazer as modificações e suas justificativas. Observações Todas as alterações foram testadas em uma impressora DARUMA MACH 2. A versão do Delphi foi XE8 Trial, muito provável alguma coisa ou outra não vá funcionar em XE5-XE2 sem alguma alteração muito pequena.(talvez apenas tipos). Foi adicionado um IFDEF VER290(XE8) , cabe a alguém testar em versões anterior e verificar o funcionamento. Novas USES (Somente FMX) System.Character - Utilizada para conversão em variáveis do tipo CHAR. System.Types - Utilizada para utilização em run-time de variáveis do tipo TRectF em canvas do Firemonkey. System.UIConsts - Utilizada para conversão de variáveis do tipo cor do Firemonkey (TAlphaColor). Problemas Encontrados Não era possível exibir formulários em run-time no firemonkey, apresentava erro de resource, a solução foi utilizar o CreateNew: {$IFNDEF FMX} fsFormMsg := TForm.create( Application ) ; {$ELSE} fsFormMsg := TForm.CreateNew( Application ) ; {$ENDIF} A cor de fundo do formulário não era alterada: fsFormMsg.Fill.Kind := TBrushKind.Solid; As propriedades da fonte como também sua cor não era possível de serem alteradas (foi adicionado uma tarefa por vocês para futuro). Uma observação é que a propriedade "TagStr",é presente em todos os componentes Firemonkey. <b>ACBrECF.pas</b> - Adicionado nova propriedade para cor de fonte apenas para o firemonkey property FormMsgColorFont : TAlphaColor read fsFormMsgColorFont write fsFormMsgColorFont ; //Realiza composição das 3 informações em apenas 1 tag fsFormMsg.TagString := ECF.FormMsgFonte.Size.ToString + ';' + ECF.FormMsgFonte.Family + ';' + AlphaColorToString(ECF.FormMsgColorFont); <b>ACBrECFClass.pas</b> - Depois é desmontada para leitura das informações //Carregando informações da fonte, family e cor with TStringList.Create do try StrictDelimiter := True; Delimiter := ';'; DelimitedText := fsFormMsg.TagString; fsFormMsg.Canvas.Font.Size := Strings[0].ToSingle; fsFormMsg.Canvas.Font.Family := Strings[1]; fsFormMsg.Canvas.Fill.Kind := TBrushKind.None; fsFormMsg.Canvas.Fill.Color := StringToAlphaColor(Strings[2]); finally Free; end; A rotina de desenho não estava adequada para o Firemonkey. fsFormMsg.Width := Round(fsFormMsg.Canvas.TextWidth(Texto)) + 25; fsFormMsg.Height := Round(fsFormMsg.Canvas.TextHeight(Texto))+ 15; Application.ProcessMessages; //Se não adicionar essa linha, o firemonkey não faz a pintura o texto. fsFormMsg.Canvas.BeginScene; //Todo canvas no firemonkey é necessário este bloco de proteção. try fsFormMsg.Canvas.StrokeThickness := 1; //Espessura do pincel. fsFormMsg.Canvas.FillText(TRectF.Create(0, 0, fsFormMsg.Width, fsFormMsg.Height), Texto, True, 100, [], TTextAlign.Center, TTextAlign.Center); finally fsFormMsg.Canvas.EndScene; end; Por ultimo, e não menos importante, a rotina de pressionar a tecla para cancelar o dialogo não estava funcionando, o código informado não atende a situações diversas que o Firemonkey apresenta no OnKeyDown. O Firemonkey quando pressionado por uma tecla que não é dita como especial, a variável KeyChar é preenchida, porem se você utilizar uma tecla como F1 ou ENTER o KeyChar fica em branco, então o Key é preenchido. if (fsFormMsgTeclaParaFechar <> 0) and (fsFormMsgEstado <> fmsAbortado) then begin if (KeyChar <> #0) and (Integer(KeyChar.ToUpper) = fsFormMsgTeclaParaFechar) then fsFormMsgEstado := fmsAbortado else if (Key > 0) and (Key = fsFormMsgTeclaParaFechar) then fsFormMsgEstado := fmsAbortado else begin Key := 0; KeyChar := #0; end; end; ACBrECFClass.pas ACBrECF.pas

Eu estou usando o componente para unificar dois sped de filiais diferentes, tem gente que usa para alimentar tabelas (para softwares de contabilidade é bem útil). No caso de software de contabilidade portar este componente para sped fiscal também seria interessante. Não estou participando muito da conversa, porque estamos produzindo PAF-ECF então estou mais distante.

Alguém que tem controle do SVN poderia por favor subir as alterações atuais, porque está acumulando, e pode ficar difícil depois para diferenciar, no momento temos a alteração de data, de um tipo de um determinado campo e ainda da forma como o arquivo é lido em outras IDEs.

Você pode utilizar o arquivo que anexei por ultimo, nele tem a correção que será subida para o SVN.

O código acima é suportado tanto pelo delphi 7, quanto pelo Lazarus ou superior, sem necessidade de diretiva de compilação, o que o torna melhor. E a diretiva de compilação no Delphi 7 ele consideraria os espaços, o que tornaria uma solução para todos menos para o Delphi 7.

Rodrigo, verifica se você está de acordo com o código abaixo na imagem acredito essa ser a solução mais simples possível Porém não sei se o Lazarus tem a constante "sLineBreak", mas se não tiver é só utilizar uma própria que já existe nos arquivos da acbr que não lembro o nome do arquivo. (LineBreak = '#10#13'); Arquivo em anexo. ACBrEPCImportar.pas

Talvez se alterar para um código nativo em pascal, sem usar a classe TStringList para a quebra de colunas.

Isso é bem estranho, pois já usei StrictDelimiter no Delphi 7, talvez é devido a versão do delphi ou update, o lazarus mesmo entende essa propriedade perfeitamente.

Verifique neste fórum, tem um tópico recente sobre a atualização dos links do webservice. Verifique no site da sefaz qual será o dia que o webservice de download direto de nfe deixara de funcionar.

Algumas notas que estou manifestando, mesmo depois de 5 horas, não está vindo o xml, acredito que seja algum problema com o ES.

Prezados, só a título de conhecimento, qual o tempo médio para receber as NFe completas após o manifesto ? Alguns clientes estão tendo que aguardar mais de 60 minutos, outros não mais que 5. Nos casos de demora o cliente acaba requisitando o ultimo NSU várias vezes pelo fato da demora. Existe algum motivo específico ?