_asseinfo

O código acima, eu utilizei aqui, no código do acbr, para fazer o teste de desempenho, aliás.

Como é permitido somente arquivos de até 2Mb aqui, estou adicionando um link do Drive. https://drive.google.com/file/d/1liob3ntzgUSitKK6EPByo9WJn9U7Dzm0/view?usp=sharing Pelos meus testes, se paginar o replace com algo do tipo: function StringReplacePaginado(const texto, PadraoAntigo: string; PadraoNovo: string; flags: TReplaceFlags): string; const NUMERO_DE_CARACTERES = 131072; var NovoTexto: string; Linha: string; Linhas: Integer; i: Integer; begin Linhas := Length(Texto) div NUMERO_DE_CARACTERES + 1; NovoTexto := ''; for i := 0 to Linhas - 1 do begin Linha := Copy(Texto, 1 + (NUMERO_DE_CARACTERES * i), NUMERO_DE_CARACTERES); Linha := StringReplace(Linha, PadraoAntigo, PadraoNovo, flags); NovoTexto := NovoTexto + Linha; end; Result := NovoTexto; end; E utilizar dessa forma AStr := StringReplacePaginado(AStr, '<', '&lt;' , [rfReplaceAll]); Ele diminui de 34 minutos, no processo inteiro, para 30 segundos, demonstrando ser 68x mais rápido.

Gente, estou tentando fazer o envio do arquivo de estoque do Bolco X, porém o arquivo está meio grande, já que é o que acontecerá em boa parte dos clientes. Ao utilizar o método Executar do ValidarBlocoX, ele demora mais de 30 minutos, para um arquivo de 4Mb. Comecei a inspecionar qual era o problema e descobri que a demora, é devido ao StringReplace que é utilizado para substituir < e > por &lt e &gt. Dei uma pesquisada na internet e inspecionei o próprio código do método StringReplace do SysUtils e o tempo aumenta exponencialmente com o aumento do tamanho do arquivo. Assim, fazendo que a substituição dos caracteres utilizada pelo ParseText do ACBrUtils seja muito lento para os casos dos arquivos de estoque do Bloco X. Como vocês costumam resolver este problema de demora? Ou simplesmente aceitam o tempo e deixam executar assim?

Entrei em contato com a Central de Atendimento Fazendário da SEFAZ-SC e obtive a seguinte resposta: A versão 01.99.01 foi autorizado para uso fiscal apenas em Santa Catarina mediante Tratamento Tributário Diferenciado solicitado pelo fabricante BEMATECH. O CNIEE correto para esta versão é 032306 Em caso de dúvida(s) entre em contato conosco. Este e-mail se propõe a elaborar respostas de caráter meramente informativo, não produzindo os efeitos próprios do instituto denominado CONSULTA, definido pelos artigos 209 a 213 da Lei nº 3.938, de 26 de dezembro de 1966. Agradeço muito pela ajuda do Felipe E. Resende Mesquita

Este foi o documento que recebemos do lacrador (em anexo). A impressora ainda está com eles, aguardando a nossa liberação. Para que você entenda, em Santa Catarina, temos que cadastrar o nº de fabricação e o nº de credenciamento la no S@t da SEFAZ-SC. Feito isso, a impressora é liberada para uso com o nosso aplicativo PAF-ECF. Grato.

Sim, já entramos em contato. Por mais incrível que pareça, o lacrador diz não possuir esta informação. O suporte da Bematech disse que nem sabe o que é CNIEE.

Então, já consultamos também essa tabela, nela consta, deste modelo, as versões 01.00.00, 01.00.01, 01.00.02, 01.00.03, mas não consta a que a empresa lacradora solicitou, que é a 01.99.01

SAT que me refiro é o Sistema onde informamos a SEFAZ-SC quais ECF's são de nossa responsabilidade, não o SAT (Sistema Autenticador e Transmissor de Cupons Fiscais Eletrônicos) que São Paulo usa. E sim, essa impressora é fiscal. Os nomes são iguais mas são coisas diferentes.

A empresa lacradora solicitou a liberação no SAT da impressora Bematech MP-4200 TH FI II versão 01.99.01. Porém não encontramos o CNIEE correspondente a esta versão. Em Santa Catarina precisamos desta informação para o relatório "REGISTROS DO PAF". Já pesquisamos no DOU, e em diversos outras fontes, sem sucesso. Alguém pode nos indicar onde encontramos, de alguma fonte oficial, o CNIEE desta versão 01.99.01 especificamente? Grato antecipadamente pela ajuda.

Olá @BigWings! Existe alguma maneira de parametrizar o ACBr para operar com o arquivo pfx usando o WInCrypt ao invés do certificado instalado no Windows? Muito obrigado.

Olá pessoal! Tudo bem? Eu espero que sim... Nós temos a NF-e implementada em outra linguagem e lá nós não precisamos instalar no sistema operacional o certificado A1 para utilizá-lo. Alguém sabe me dizer se isso é possível de ser feito no Windows? Se o ACBr teria métodos para isso? Será que as mudanças para usar o WinCrypt poderiam levar a isso? Seria perfeito ter um método que a gente desse um .pfx ou .p12 e o ACBr passasse a usar ele ao invés do que está no sistema operacional. Vou da um exemplo prático: na semana passada atendemos um licenciado que nos pediu para instalar o mesmo certificado digital em 12 terminais. Se eu tivesse isso persistido dentro do banco de dados e carregasse ele sob demanda, nosso trabalho de reinstalação de certificados diminuiria abruptamente. Se isso for algo interessante para o projeto, talvez a comunidade pudesse financiar esta modificação. Creio que a galera ajudaria. Aqui, com certeza ajudaríamos! Um abraço

Olá?! Na realidade nós já tivemos problemas com alguns licenciados, atualizamos a cadeia e funcionou. Creio que teremos sim problemas no dia 27. Espero não ter. Como disse acima, agradeço se alguém com experiência em certificados puder responder com um pouco mais de profundidade. Se a gente tivesse só alguma pista dos certificados afetados, já ajudaria em uma ação pró-ativa de suporte. Muito obrigado.

Olá?! 1. Alguém sabe dizer se todos os certificados serão afetados? Será que os emitidos recentemente já não estão com a nova cadeia? Saber essa resposta poderia facilitar o trabalho de atualização. Assim a gente poderia agir direto nos problemáticos ao invés de passar por toda a carteira. 2. Temos uma percepção aqui que esta cadeia de certificados serve como uma garantia ao assinador. Fazendo uma analogia com o SOAP, é como ela fosse os arquivos XSD. Eles auxiliam a você não ter que bater no endpoint da CONFAZ com dados inconsistentes, mas, se você ignorá-los, a CONFAZ fará as validações necessárias. Alguém sabe responder DE VERDADE se essa afirmação é verdadeira? Pergunto isso porque temos outro produto que não utiliza o ACBr e aparentemente não estamos utilizando a cadeia para nada. Aqui na empresa, por exemplo, nós já desabilitamos os arquivos XDSs no ACBr há alguns anos. Isso já nos poupou de uma série de dores de cabeça nas atualizações dos clientes. O chato é que cada vez que pegamos uma nova versão do ACBr, temos que customizar essa pequena parte. Mas mesmo assim vale muito a pena. Peço muito respeitosamente que respondam apenas aqueles que tiverem certeza das respostas. Isso ajudará a gente e os demais a não passar sufoco no próximo dia 27. Muito obrigado.

Olá?! Aqui na ASSEINFO nós já pegamos alguns casos na sexta-feira que precisamos atualizar a cadeia de certificados. Aconteceu em certificados A1 e A3. PERGUNTA: Eu gostaria de saber se alguém sabe se tem alguma pista de que tipo, vencimento ou algo assim que deixará de funcionar no dia 27. Assim, nós poderíamos ser proativos e entrar em contato antes com os possíveis problemáticos. Um abraço.

Era bem isso mesmo BigWings, (: Obrigado!!

De verdade, se tiver um exemplo de XML gerado, válido, para o download do XML da nfe, consultando pela chave, eu acredito que já conseguiria identificar qual o problema. É desta maneira que estou utilizando a função: FNFeACBr.DistribuicaoDFePorChaveNFe(FNFeACBr.Configuracoes.WebServices.UFCodigo, '22379984000104', '32170316590234002543550000005971871538746903');

Essa mensagem é um retorno da Sefaz. Estou com o repositório do ACBR atualizado, no dia de hoje também.

Usando a função da forma que foi informada, porém estou recebendo um retorno de falha no esquema. O XML gerado é o seguinte: <?xml version="1.0" encoding="UTF-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <nfeDistDFeInteresse xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeDistribuicaoDFe"> <nfeDadosMsg> <distDFeInt xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.00"> <tpAmb>1</tpAmb> <cUFAutor>42</cUFAutor> <CNPJ>22379984000104</CNPJ> <consChNFe> <chNFe>32170316590234002543550000005971871538746903</chNFe> </consChNFe> </distDFeInt> </nfeDadosMsg> </nfeDistDFeInteresse> </soap12:Body> </soap12:Envelope>

Boa tarde Daniel, O nome do método está indicando que um arquivo binário está sendo gerado. A minha dúvida é, se eu utilizar o novo método que foi criado, passando duas datas vazias, vai sair o conteúdo da memória toda? Muito obrigado por enquanto.

Então foi criado um novo método que gera os arquivos sem utilizar a data? Pois era o que o método PafMF_ArqMFD fazia anteriormente e este comportamento mudou, correto? Peço desculpas caso não esteja conseguindo ser claro. Posso tentar explicar o que preciso de outra forma, caso ache melhor. Pois até hoje utilizávamos PafMF_ArqMFD. Se existe um substituto que faz o que ele fazia na totalidade, poderia me dizer qual é?

Isso, caso eu mande com as datas zeradas, ele me retornará toda a memória?

Daniel, eu li o changelog, a parte que fala deste método: Entretanto, minha dúvida não é sanada por ele, o comportamento do método sobrecarregado procedure TACBrECF.ArquivoMFD_Binario_DLL(NomeArquivo: AnsiString; DataInicial, DataFinal: TDateTime); seria o mesmo do método procedure TACBrECF.ArquivoMFD_Binario_DLL(NomeArquivo: AnsiString);? No caso o procedure TACBrECF.ArquivoMFD_Binario_DLL(NomeArquivo: AnsiString; DataInicial, DataFinal: TDateTime); com as datas zeradas.

Fui atualizar a versão do ACBR utilizada pelo nosso sistema e me deparei com esta modificação. O metodo PafMF_ArqMFD foi alterado para PafMF_ArqMFD_Binario, além de também passar a pedir dois parâmetros de data, inicial e final de um período. Linhas 912 a 913 do arquivo trunk2/Fontes/ACBrSerial/ACBrECF.pas procedure PafMF_ArqMFD_Binario(const APathArquivo: String; DataInicial: TDateTime = 0; DataFinal: TDateTime = 0; Assinar: Boolean = True); Fui mais a fundo para ver se enviando o valor padrão, o comportamento continuava inalterado, porém ele passa a utilizar um método diferente, uma sobrecarga do método que utiliza os parâmetros de data para todos os casos. Linas 4606 a 4620 do arquivo trunk2/Fontes/ACBrSerial/ACBrECF.pas procedure TACBrECF.ArquivoMFD_Binario_DLL(NomeArquivo: AnsiString; DataInicial, DataFinal: TDateTime); var StrInicial, StrFinal: String; begin TestaSeE_MFD ; StrInicial := FormatDateTime('ddmmyyyy', DataInicial); StrFinal := FormatDateTime('ddmmyyyy', DataFinal); ComandoLOG := 'ArquivoMFD_Binario_DLL( ' + NomeArquivo + ', '+ StrInicial+', '+StrFinal+' ) '; fsECF.ArquivoMFD_Binario_DLL( tdmfdData, NomeArquivo, StrInicial, StrFinal) ; end; A pergunta que faço é: O comportamento se mantem inalterado, caso se coloque a data zerada? Ou o comportamento do método sobrecarregado será diferente?

Boa tarde, O número de reduções o ACBR traz facilmente. Nossa necessidade é especificamente obter a quantidade de memória livre disponível. Temos clientes que a memória fiscal acaba lotando antes de egotarem as reduções Z. Descobrimos que a Bematech possui, via DLL, uma maneira de recuperar esta informação, porém, não são todos os modelos. Impressoras de outras marcas não encontramos alternativa ainda.

Bom dia douglas_k, tudo bem? Eu agradeço o seu auxílio desde já. Vou atualizar o ACBr e atualizar meu cliente para ver se deu certo. Mais uma vez, muito obrigado. Att.