Everton Garcia

Juliomar, Pelo menos em relação a layout, não estou tendo mais problemas com o PVA. []´s Everton Garcia

Bom dia pessoal! Implementei o contador dos blocos E311, E312 e E313. []´s Everton Garcia ACBrSpedFiscal.pas

Bom dia pessoal! Como ninguém se manifestou sobre os registros acima citados, implementei-os. Segue anexo as units para análise. Implementados os registros E300, E310, E311, E312, E313, E316; Adicionado em ACBrEFDBlocos.pas o tipo TACBrMovimentoDIFAL; []´s Everton Garcia ACBrEFDBloco_E_Class.pas ACBrEFDBlocos.pas ACBrEFDBloco_E.pas

Olá DenerBuzato! Sim, já tentei debugar. O erro ocorre na linha 346 da unit ACBrBoletoFCFR. Result := DmBoleto.frxReport.PrepareReport Como não tenho os fontes do Fast, não tenho como debugar este método. []´s Everton Garcia

Olá pessoal! Estou tentando imprimir um boleto ou gerar um arquivo PDF utilizando o Fast e estou recebendo o erro que consta na imagem anexa. Estou usando o ACBrBoletoDemo. Apenas modifiquei o ACBrBoletoFC para utilizar o Fast. Ao clicar em imprimir ou Gerar PDF ocorre a mensagem anexa. Alguém que utiliza Fast poderia me dar um auxílio? As versões instaladas do Fast são as disponibilizadas no site da Embarcadero para usuários registrados, e a versão do Delphi é a Seattle. []´s Everton Garcia

Olá pessoal! Gostaria de saber se já estão sendo implementados os registros definidos no Ato COTEPE/ICMS 44. https://www.confaz.fazenda.gov.br/legislacao/atos/atos_cotepe/2015/ato-cotepe-icms-44-15 []´s Everton Garcia

Olá Daniel. Apaguei a pasta Serial e baixei novamente. Agora deu certo. Estranho. Não havia nenhuma alteração na pasta. O importante é que eu estava enganado e que está resolvido. Obrigado pela dica.

Bom dia! Observei que a propriedade "TagsNaoSuportadas" (inserida na revisão 10303) não consta na revisão 10333, ocasionando erro ao instalar o pacote ACBrSAT (unit ACBrSATExtratoESCPOS, linha 438). Fontes atualizados com a revisão 10539. Windows 10. Delphi Seattle. []´s Everton Garcia

Olá Daniel e Regys. A demora ocorre ao tentar capturar o CNPJ de um certificado A3 Token. Não testei fora de domínio como citado no tópico que mencionei acima. Porém, não quis arriscar em liberar uma versão do sistema com essa possibilidade de demora. Por isso, resolvi remover a rotina que extraia o CNPJ do certificado e também a validação que era feita entre o CNPJ do emissor e do certificado. Vou tentar fazer o teste em um ambiente sem domínio para ver se o problema ocorre. []´s Everton Garcia

Boa noite. A minha intenção foi reportar um erro no código, independente da propriedade ser preenchida ou não, de forma correta. Att.

Segue a unit alterada. []´s Everton Garcia ACBrBancoSantander.pas

Olá pessoal! Enviamos um arquivo de remessa (240) contendo Data de Protesto, e o banco recusou, acusando erro nos dados informados nas posições 222-223 (Dias Protesto), 224-224 (Código de Baixa/Devolução) e 228-229 (Código da Moeda). Analisando a rotina do ACBrSantander, no método GerarRegistroTransacao240, identifiquei que a variável Instrucao1, responsável por receber a instrução de protesto, não estava sendo alimentada, ficando vazia e consequentemente mexendo nos campos posteriores. A rotina estava verificando a variável Instrucao2 (conforme código abaixo): {Instruções} if (DataProtesto <> 0) and (DataProtesto > Vencimento) then begin if (Trim(Instrucao2) = '') then {*********************** AQUI ********************} Instrucao2 := '1' // Protestar Dias Corridos {*********************** AQUI ********************} else begin if not MatchText(Instrucao2, ['0', '1', '2', '3', '9']) then {*********************** AQUI ********************} raise Exception.Create('Código de protesto informado incorretamente!'); end; // Calcular os dias para protesto sDiasProtesto := PadLeft(IntToStr(Trunc(DataProtesto) - Trunc(Vencimento)), 2, '0'); end else begin Instrucao1 := '0'; // Não protestar SDiasProtesto := '00'; end; Pra resolver, bastou trocarmos Instrucao2 por Instrucao1 nas linhas marcadas com {*********************** AQUI ********************}. []´s Everton Garcia

Olá Juliana! Caso o endereço do sacado não esteja completo (UF vazia), o arquivo será invalidado por não conter 240 ou 400 caracteres. Todos os demais campos de endereçamento possuem este tratamento nos métodos citados. Por isso a minha sugestão. []´s Everton.

Boa tarde pessoal! Gostaria de sugerir a seguinte alteração nos métodos GerarRegistroTransacao240 e GerarRegistroTransacao400 da unit ACBrBancoSantander: Substituir: Sacado.UF Por: PadRight(Sacado.UF, 2) []´s Everton.

Olá Professor! Este erro ocorreu em alguns clientes nossos também. Porém, de forma esporádica. O cliente reportou e pedimos que ele tentasse transmitir a nota fiscal minutos mais tarde. Dez minutos depois entramos em contato com ele e ele havia conseguido transmitir. P.S: A versão instalada foi compilada com Trunk2. []´s Everton Garcia

Olá Filippe! Tive este mesmo problema de quebra de linha no campo "Informações Adicionais". Resolvi substituindo a quebra de linha por ";" na hora de transmitir. Abs. Everton

Ao abrir o tópico pesquisei apenas pelo nome do método e por CAPICOM, e não encontrei o que desejava. Pesquisando agora pelo método que está demorando, observei a existência de tópicos antigos, de junho e setembro de 2014. O fato é que o problema que reportei persiste, e que a solução alternativa foi a mesma adotada em um dos tópicos anteriores: comentar o procedimento. Abs. Everton.

Boa tarde pessoal. Estou tentando transmitir uma NFe utilizando a libCapicom (devidamente registrada), e observei uma demora enorme ao assinar o XML. Debugando, identifiquei que a demora ocorre na hora de fazer a busca pelo CNPJ (método CarregarCertificado da classe TACBrDFeCapicom) - linha: Propriedades := Extension.EncodedData.Format(True); A demora dura cerca de quase um minuto, e isso não estava acontecendo antes. Estou usando a revisão 9667 (de hoje). Alguém já teve esse problema? Obrigado. Everton.

Obrigado Daniel. Everton Garcia

Pessoal, Estava tendo problemas com uma MP 4200 TH FI, que estava retornando "Erro Específico do Fabricante - Motivo 40". Analisando o LOG, identifiquei que o problema estava no método AbreNaoFiscal. Na linha 2319 da unit ACBrECFEscECF, inicia-se o seguinte código: if Trim(CPF_CNPJ) <> '' then Consumidor.AtribuiConsumidor(CPF_CNPJ,Nome,Endereco); EscECFComando.CMD := 16; Aparentemente não há nada de errado. Porém, se o CPF_CNPJ enviado for inválido, o comando será enviado à impressora e o erro descrito acima será retornado. Neste caso, bastaria que o sistema alertasse o usuário e o mesmo fizesse a correção. Ok. O problema é que, caso o CPF_CNPJ enviado seja VAZIO, o erro continua ocorrendo. E o motivo é que o conteúdo das variáveis da classe Consumidor ainda permanecem com os valores antigos. Para reproduzir o problema no ACBrTeste basta realizar os seguintes passos: - Selecionar o modelo ecfEscECF; - Abre Não Fiscal - Deixar em branco os dados do consumidor (ou informar um CPF valido) e OK; - Fechar Não Fiscal; O "Não Fiscal" será impresso corretamente. - Abre Não Fiscal - Informe 123 (simulando CPF inválido) - Observar a mensagem de Erro - Fechar Não Fiscal - Abre Não Fiscal - Deixar em branco os dados do consumidor (ou informar um CPF valido) e OK; - Observar a mensagem de Erro - Fechar Não Fiscal A minha sugestão é modificar o código para: if Trim(CPF_CNPJ) <> '' then Consumidor.AtribuiConsumidor(CPF_CNPJ,Nome,Endereco) else Consumidor.Zera; EscECFComando.CMD := 16; []´s Everton Garcia

Olá Daniel, Reproduzir o problema é outro problema rsrs. O cliente me mandou um print da mensagem de erro durante a emissão de um relatório gerencial no sistema. A partir daí comecei a emitir RG até que conseguisse reproduzir o erro. Não consegui identificar um padrão de ações que levassem ao erro e nem um padrão de conteúdo impresso. Quanto à correção de algo relacionado, vi algo relacionado ao método PularLinhas e a espaço em branco. De fato, em alguns relatórios há a impressão de "Linha em branco", mas pelo que observei não parece ser este o problema. Quanto aos fontes, acabo de ver que tem a revisão 9459 (de hoje), com uma alteração na constante cEscECFMaxBuffer. Vou atualizar e fazer novos testes. Obrigado. Everton.

Boa tarde pessoal! Estou tendo problemas com uma Bematech MP4200 TH TI. Em algumas emissões de Relatório Gerencial, dá a seguinte mensagem: "Categoria: 15-Protocolo Motivo: 2-Checksum inválido no comando recebido pelo ECF" Depois de vários relatórios gerenciais emitidos, também consegui reproduzir a mensagem de erro no emulador da MP4200. Alguém já teve este problema? Anexei três trechos do LOG onde constam a mensagem de retorno com a categoria 15. Ambiente: Delphi 2010 Fontes: Trunk2 - Revisão 9457 []´s Everton logBematech.txt

Olá gss200610! Qual foi a solução dada pelo Regys?

Olá, você conseguiu identificar o problema? Estou com problemas em uma FS700M também.Volta e meia ocorre o erro 024.

Pelo parágrafo abaixo, as homologações realizadas a partir do dia 17 de junho serão feitas na versão 2.01. § 2º A versão da Especificação de Requisitos do PAF-ECF (ER-PAF-ECF) a ser aplicada na análise funcional será a última, desde que publicada no Diário Oficial da União no mínimo 90 (noventa) dias antes da data do início da análise.