Painel de líderes

Olá Como sabemos o Projeto ACBr foi implementado mantendo a compatibilidade com o Delphi e Lazarus, porém, os arquivos de Formulário no Delphi (.dfm) não é o mesmo utilizado pelo Lazarus, que possui a extensão (.lfm) e utiliza o formato UTF-8. Por esse motivo, quando realizarmos alterações em Formulários do ACBr utilizando o Delphi(.dfm), devemos compatibiliza-lo também no Formulário do Lazarus(.lfm). A forma mais fácil de realizar esta tarefa é Converter o Arquivo alterado, assim não precisamos realizar as mesmas alterações nos dois arquivos. Segue abaixo o procedimento para Conversão. 1- Exclua o arquivo com a extensão .lfm, que já existe no Projeto. ex: ACBrNFeDANFeRLRetrato.lfm 2- Realize uma Cópia do Arquivo .dfm que foi alterado. ex: ACBrNFeDANFeRLRetrato - Copia.dfm 3- Renomeie o Arquivo copiado com o mesmo nome do original, mas altere a extensão para .lfm ex: ACBrNFeDANFeRLRetrato.lfm 4- Abra o arquivo .lfm utilizando o NotePad++ e selecione a opção Converter para UTF-8 (caso ainda não esteja em UTF-8). Salve as alterações... ex: 5- Abra o Formulário Alterado no Lazarus, mova o posição do formulário apenas para poder Salvar as alterações e Compile o Projeto.. Note que ao salvar o formulário utilizando o Lazarus os caracteres acentuados que estavam codificados agora estarão corretos... Basta então testar a Aplicação... Antes: Depois:

Boa tarde, Pessoal Obrigada a todos, pela atenção Consegui resolver passando os parâmetros abaixo no evento ACBrTEFD1AntesFinalizarRequisicao if Req.Header = 'CRT' then begin if FDebito then Req.GravaInformacao(731,0,'3'); // (Venda Debito = 3) if FCredito then begin Req.GravaInformacao(731,0,'1'); // (Venda Credito = 1) Req.GravaInformacao(732,0,'1'); //Tipo Parcelamento a vista = 1 end; Req.GravaInformacao(732,0,'1'); //Venda Credito a vista = 1 Req.GravaInformacao(739,0,'001'); end;

Não há o conceito de alinhamento a direita... use PAD... Exemplo: ACBrMTer1.EnviarTexto(PadLeft('A DIREITA', ACBrMTer1.DisplayColunas)); ACBrMTer1.EnviarTexto(PadSpace('TEXTO ESPACEJADO', ACBrMTer1.DisplayColunas));

Chegamos a marca de 3 webservices distintos para Blumenau, agora SimplISS já pode pedir música no Fantástico. Eu já tenho empresas usando os outros dois webservices(wsblumenau e migracao) e agora vou ter no terceiro(wsblumenau1), porque ainda tenho problemas em 3 clientes referentes a assinatura. ou seja, pessoal se não der certo a emissão em um, bola pra frente e colocamos para enviar no próximo. Desde que não tenha o 4 webservice já estamos de bom tamanho;

Parece algum problema nos próprios arquivos de Schema. Está com a pasta de Schemas atualizada?

Boa tarde Prezados, Em contato com o Suporte da prefeitura me encaminhou os arquivos para continuar com testes no ambiente:https://wsblumenau1.simplissweb.com.br/nfseservice.svc WSDL: https://wsblumenau1.simplissweb.com.br/nfseservice.svc?wsdl Segue informativo do Sr. Pedro referente ao testes que ele realizou nos arquivos: 'Segue o arquivo SOAP_GerarNfse de exemplo. Estou mandando um outro arquivo também que fiz o teste. Neste arquivo, eu peguei o arquivo original que encaminhou para o nosso suporte, alterei somente o CNPJ do prestador e do tomador, fiz a assinatura e enviei. A nota foi registrada normalmente. Por favor, se atente ao seguinte ponto: A tag que deve ser assinada é <InfDeclaracaoPrestacaoServico>. Não sei como é feito o processo de assinatura no sistema de vocês, mas se depois de assinado houver qualquer alteração no arquivo, a assinatura deixa de ser válida. Portanto, se depois de assinar o arquivo é incluído as tags e namespaces do soap e o arquivo é salvo, vai quebrar a assinatura e vai dar erro. Eu faço a emissão manual, através do programa SoapUi. Depois de assinar o arquivo xml puro (arquivo exemplo_simpliss) eu coloco as tags do soap e os namespaces e sem salvar o arquivo, copio e colo no SoapUi e faço o envio. Deste modo, a assinatura não é quebrada.' Realizei os testes com os arquivos porem ainda apresenta assinatura invalida, estou encaminhando para que possam testar, e caso tenham mais sorte que eu, por favor compartilhar. envio_1742_edit_assinado.xml exemplo_simpliss.xml SOAP_GerarNfse (1).xml

Boa tarde André, Favor atualizar os fontes novamente e faça novos testes.

Boa tarde Nilson, Pelo PDF você deve estar usando o DAMDFE feito em Fast Report, correto? Outra coisa, a imagem do QR-Code só vai ser impressa se no XML conter a string do QR-Code. Essa string fica na tag qrCodMDFe, note que o seu XML não tem essa tag. Essa tag só é gerada no XML depois que o mesmo é assinado. Você simplesmente alimentou o componente e mandou gerar o XML e por fim imprimir o DAMDFE. Após alimentar o componente em vez de executar o método GerarXML, execute o método Assinar, desta forma o XML vai conter a string e ao imprimir o DAMDFE vai aparecer o QR-Code.

Caros amigos @Italo Jurisato Junior e @Juliomar Marchetti fico muito feliz em dizer que deu certo o processo que precisava criar. A sugestão do Italo funcionou perfeitamente. Obrigado pela atenção.

Dercide, Muito obrigado. Pessoal por favor utilizem o arquivo INI do provedor SimplISSv2 que acabo de enviar para o repositório. Dercide, como você conseguiu consumir o webservice abrindo o WSDL, faça um teste com esse novo INI. João, você esta usando um certificado digital de uma empresa de Blumenau? Se não estiver, acredito ser esse o problema.

Obrigado @José M. S. Junior Questão resolvida

Olá, @Daniel Simoes, acho que isso já foi implementado nas novas versões do TEF Pay&Go. Eu só não sei quais campos devem ser preenchidos. Veja esse tópico se te ajuda:

Kamilo, Acredito que na próxima versão do Monitor os títulos da lista de documentos originários já vão estar corrigidos.

Assim, entendi. Atualizei já a propriedade e já troquei também o número fixo para a propriedade DisplayColunas. Valeu mais uma vez. Abraços!

Você pode/deve definir o número de Colunas no Componente... assim ele saberá quando acaba a linha... Veja no Demo, os efeitos de animação

Ok, obrigado, ligamos na receita e realmente informaram que esta com problemas, e não sabem informar quando vai estabilizar. Obrigado pelo retorno. Não cheguei abrir, pois o erro era que a NFC-e estava fora do ar, mas vou procurar pegar mais detalhado e vou postar aqui, obrigado pela ajuda.

Já esta disponível no SVN um Exemplo de classe para o ACBrLibBoleto.

Fiz 2 MDFe e resolvi o problema, achei que ele não deixaria gerar 2 MDFe diferente para o mesmo veiculo e motorista, mas autorizou. Então, solucionado.

O componente tem os comandos para bloquear e desbloquear, mas antes de cada um deles você precisa fazer a solicitação de bloqueio e desbloqueio no portal de gerenciamento do sat. https://satsp.fazenda.sp.gov.br/COMSAT/Account/LoginSSL.aspx?ReturnUrl=%2fCOMSAT%2f

Classe completa da NFe enviada ao SVN.

Funcionou o instalador da versão 32 bits corretamente, vou utilizar essa a partir de agora.

Boa tarde, estou em processo de homologação do arquivo de remessa CNAB 400 e boleto do Banco Safra, e na validação o suporte do banco apontou divergências na questão do campo nosso número, onde eles alegam que o conteúdo do campo nosso número informado no arquivo de remessa deve ser o mesmo utilizado na impressão do boleto, ou seja, no arquivo de remessa esta sendo informado com o digito verificador calculado, portanto na impressão do boleto, no cálculo da linha digitável e no código de barras deve ser considerado o mesmo conteúdo do campo nosso número gerado no arquivo de remessa. Em contato por telefone com o suporte, o atendente me disse que não há necessidade de se calcular o digito verificador para o campo nosso número, neste caso uma solução seria apenas remover o digito verificador do campo nosso número no arquivo de remessa, já que nas funções MontarCampoNossoNumero e MontarCodigoBarras já não estão considerando o digito. Fiz o ajuste conforme descrito acima na unit ACBrBancoSafra, e reenviei novamente o arquivo juntamente com os boletos para nova validação, assim que tiver o retorno volto aqui pra dizer se deu certo, e saber se é possível aplicar isso ao SNV.

Olá Pessoal, Já encontra-se disponível no repositório Trunk2 o mais novo componente ACBr - ACBrONE - Operador Nacional dos Estados. "O Operador Nacional dos Estados: ONE é o sistema responsável por integrar os documentos fiscais eletrônicos das Administrações Tributárias com as diversas tecnologias de identificação de veículos nas rodovias brasileiras. O sistema objetiva a geração dos eventos Registro de Passagem nos documentos fiscais transportados por intermédio da informação da placa do veículo e sua respectiva geolocalização, detectada por algum dispositivo ou tecnologia de monitoramento, o que auxilia nas ações de fiscalização de trânsito e de combate à sonegação." O texto acima foi retirado do Portal do Operador Nacional dos Estados - SVRS. Para mais informações visite o Portal. O manual do ONE já baixamos e se encontra em nossa biblioteca. Nas pastas: ...\Exemplos\ACBrDFe\ACBrONE\Delphi ===> temos o programa exemplo do componente. ...\Exemplos\ACBrDFe\Schemas\ONE ===> temos os schemas ...\Fontes\ACBrDFe\ACBrONE ===> temos os fontes ...\Pacotes\Delphi\ACBrDFe\ACBrONE ===> temos o pacote de instalação. Por enquanto o ACBrInstall_Trunk2 não esta preparado para instalar esse componente, logo será necessário a instalação manual através do Pacote. Observação1: apesar dos XMLs a serem enviados não precisam ser assinados digitalmente é preciso de um certificado digital para consumir os Webservices. Observação2: Não é qualquer empresa que pode usar o ONE é preciso que ela esteja cadastrada como uma Operadora.

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

Obrigado pela resposta estava postando agora que foi isso mesmo pasta schemas desatualizada.

Olá pessoal, Queremos informar que na revisão 17943 foi enviada ao SVN as alterações previstas a algumas semanas para padronizar as unidades de medidas e comportamento das margens nas impressões. Caso queira mais informações, veja o tópico de anúncio:

Boa tarde, O valor de nNF tem que ser sequencial independente do que ocorra.

Olá Italo, A principio deu certo, verifiquei que não chamava o ExtrairNotasRetorno no TrataResposta. Agradecido por enquanto. André Diel

Ana, Se você não é assinante no SAC você só vai conseguir baixar o ACBrMonitor Plus - Free que foi atualizado em 3 de setembro, já para que é assinante do SAC tem uma versão do ACBrMonitor Plus disponibilizada a 22 horas ou seja ontem. Pode até ser que a versão Free de 3 de setembro tenha o eSocial e o Reinf para você realizar os seus testes.

Boa tarde Eduardo, O DistribuicaoDFe não faz retornos de documentos referente a um período. Sugiro que leia o artigo: Como obter o XML do Fornecedor No que diz respeito a ler dados retornados pelo DistribuicaoDFe, segue em anexo um exemplo. DistribuicaoDFe.txt

No tópico indicado pelo @EMBarbosa tem um exemplo de como "injetar" campos na requisição... Agora é pesquisar na documentação da PayGo quais são os campos necessários

Boa tarde Junior, Fico feliz em ter mostrado um caminho que resultou em uma solução para o seu problema.

Bom dia Tentamos de tudo no windows, mas sempre voltava a acontecer o problema em um ou outro cliente. A melhor coisa que fizemos para resolver esse problema foi adotar o OpenSSL como padrão nos certificados A1 (que é a maioria dos casos dos nossos clientes), recomendo fazer o mesmo.

Bom dia Lino, Apesar do Windows ser 64 bits o Delphi 7 deve estar compilando em 32 bits, correto? Logo você tem que usar as DLLs de 32 bits. Você instalou os componentes usando o ACBrInstall_Trunk2? A instalação ocorreu com sucesso? A aplicação funciona na sua maquina sem problemas? Ela só não funciona na maquina do seu cliente?

Bom dia, apenas complementando com mais uma informação, vc chegou a ver que agora este campo modBCST tem um novo valor ? 6=Valor da operação... Att Ricardo

Bom dia Qualquer alteração que for realizada no XML vai fazer com que o DigestValue mude, isso é a garantia de que o XML é o original. Se está consultando a chave e o DigestValue do XML da SEFAZ não é o mesmo do seu diretório é por que foi realizado alguma alteração ou realmente o XML foi emitido em duplicidade... O Componente tem um propriedade para ignorar o DigestValue, mas se isso acorre com frequência é importante rever a rotina pois pode estar emitindo em duplicidade no caso de Emissão em contingência. Veja configuração abaixo:

Rafael.. obrigado.. vou baixar....

Foi enviada uma nova versão com a correção, não estava sendo passado corretamente as propriedades do ini para o componente.

@Italo Jurisato Junior Abri as duas URLs normalmente, ambas solicitaram o certificado, selecionei e foi de boa sem erro. Dercide Alvarez

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Entendi Lucianat. Você pode tentar baixar uma versão mais atualizada do GAD no site da SEF MG. Eles disponibilizaram uma nova versão ontem (14/10). Veja esse link: http://www.fazenda.mg.gov.br/empresas/sistemas/sintegra/download.htm Caso não funcione, você pode entrar em contato com a SEFAZ por meio do Fale Conosco deles. Por fim, se não resolver, você realmente vai precisar verificar com a Conta Azul como proceder. Talvez exista alguma outra forma. Por exemplo, se eles não geram o Sintegra, talvez eles gerem o SPED. Daí bastaria você pedir ao contador para enviar o SPED no lugar do SINTEGRA.

ok

Enviado para o repositório, rev. 17924. Obrigado pela contribuição.

Eu encontrei o erro, na verdade o cliente informou o bairro com um ".", porém como ele gera todos esses alertas não mostra o erro, ou mostra abaixo da tela, ajustei o bairro, enviei a nota, mostrou os alertas mas enviou e validou... Obrigado

Bom dia. Isso mesmo. Att.

Boa tarde A princípio o problema foi resolvido. Este Erro Relacionado ao Canal Seguro ocorreu somente entre os dias 03 e 04/10/19 no RS. Pelo meu monitoramento durante a semana, identifiquei que este erro não foi mais registrado do dia 05/10/19 em diante

veja se as dlls q estão na pasta de seu projeto são as mesma q estão no cliente. dentro da pasta do ACBR tem uma pasta DLLs, pegue qual vc esta referenciando e coloque na mesma pasta do seu executável . Seu problema é estar usando DLLs diferente do que esta no seu cliente.

Isso pode ser alguma validação dos dados do próprio emulador... Procure utilizar os mesmos dados de Emitente e SW referenciados no Manual do Emulador. Acompanhe esse vídeo onde é realizado o Cancelamento também, pode ser algum detalhe:

Boa tarde a todos, Para quem utiliza o componente ACBrCTe e estava com dificuldades de gerar o Hash de Entrega, poderá se utiliza de uma das duas funções que acabam de ser disponibilizadas na unit ACBrDFeUtil. São elas: function CalcularHashDados(const ADados: TStream; AChave: String): string; Devemos utilizar a função acima quando a imagem esta armazenada no banco de dados, neste caso o conteúdo da mesma é passado como Stream no primeiro parâmetro da função, já o segundo é a chave do CT-e. A função retorna uma string com 28 caracteres que devemos atribuir ao campo: infEvento.detEvento.hashEntrega Exemplo: infEvento.detEvento.hashEntrega := CalcularHashDados(xStreamImagem, xChaveCTe); e function CalcularHashArquivo(const APathArquivo: String; AChave: String): string; Devemos utilizar a função acima quando a imagem esta salva em disco, neste caso o primeiro parâmetro da função é o path com o nome do arquivo (imagem) e o segundo é a chave do CT-e. A função retorna a string com 28 caracteres que devemos atribuir ao campo: infEvento.detEvento.hashEntrega Exemplo: infEvento.detEvento.hashEntrega := CalcularHashArquivo(xPathImagem, xChaveCTe);

Tente o seguinte: No evento OnAntesFinalizarRequisicao, informar os parâmetros mais ou menos assim procedure TdtmPDV.ACBrTEF1AntesFinalizarRequisicao(Req: TACBrTEFDReq); begin if Req.Header = 'CRT' then Req.GravaInformacao(777, 777, 'TESTE REDECARD'); end;