Painel de líderes

O TEF por API/DLL, PayGoWeb, é muito rápido e simples de instalar... Mas você deve tomar alguns cuidados para que ele funcione corretamente nos seus clientes Finais Se você está recebendo alguma das msgs de erro abaixo: SEQUENCIA INVALIDA DO NUMERO DE SOLICITACAO ERRO DE AUTENTICACAO DO PONTO DE CAPTURA A causa desse problema, pode ser o Fato de sua aplicação, que carrega a DLL da PayGoWeb, estar sendo executada em várias instâncias, ao mesmo tempo, na mesma máquina... Ou seja, o Operador executou a aplicação duas ou mais vezes, e está operando o TEF em várias janelas da sua mesma aplicação... Isso gera uma série de problemas, e deve ser evitado... O PinPad não poderá ser acessado em modo compartilhado, por várias instâncias da DLL da PayGoWeb, ao mesmo tempo, e você pode receber erros de acesso ao PinPad As tabelas internas da PayGoWeb, que ela cria em sua Pasta de Trabalho podem perder o sincronismo, pois agora temos várias instâncias da DLL da PayGoWeb gravando nas mesmas tabelas... Portanto, devemos evitar que a aplicação de Frente de Caixa, possa ser aberta várias vezes, na mesma máquina... Uma das técnica para fazer isso, é usar a API do Windows, com o método CreateMutex Veja um exemplo, abaixo, usando Delphi. program SeuPrograma; uses Interfaces, sysutils, IniFiles, Windows, Dialogs, Forms, .... ; {$R *.res} var Ini : TIniFile; UmaInstancia : Boolean; begin Ini := TIniFile.Create( ExtractFilePath(Application.ExeName)+ 'Config.ini' ) ; try UmaInstancia := Ini.ReadBool('Config', 'Uma_Instancia', false); finally Ini.Free; end; Application.Initialize; if UmaInstancia then begin CreateMutex(nil, True, 'NomeDoSeuPrograma'); // <--------------- AQUI ------------- if GetLastError = ERROR_ALREADY_EXISTS then begin MessageDlg('NomeDoSeuPrograma','O programa já está em execução', mtError, [mbOK], 0); Application.Terminate; exit ; end; end; Application.CreateForm(TFrmMain, FrmMain) ; Application.Run; end. Ou Seja, o Primeiro Mutex será criado com sucesso... Mas quando a segunda aplicação for executada, haverá um erro na criação do Mutex, e isso forçará a entrada no IF que aborta a execução do programa, fechando a segunda instância...

ÁLVARO ANTÔNIO DA SILVA BAHIA - COORDENADOR TÉCNICO DO ENCAT 11/06/2021 MDF-e: Lastro Digital Viabilizador do Mercado de Recebíveis de Transportes Você venderia seu carro para um desconhecido recebendo como pagamento um cheque pré-datado para ser liquidado em 30 dias? É evidente que não! Na era do PIX e da Duplicata Escritural, um recebível futuro que não esteja conectado “em tempo real” com seu respectivo lastro, no caso o saldo da conta, não apresenta a segurança necessária exigida pela atual sociedade conectada, muito menos pelo mercado financeiro. Atenta as atuais dificuldades enfrentadas por operadores do mercado de antecipações de recebíveis e a necessidade de ampliação da disponibilização de capital de giro para o segmento de transportes de cargas, em uma modelagem open banking e disruptiva, a Plataforma de Consultas para Antecipações de Recebíveis do Estados (www.placsvba.ba.gov.br), apoiada pelo ENCAT, o CONFAZ e o Ministério da Economia, juntamente com empresas dos segmentos de Registros de Duplicatas Escriturais, Transportadoras e instituições do segmento financeiro, estão desenvolvendo um portfólio de recebíveis de transportes lastreados a partir do Manifesto Eletrônico de Documentos Fiscais (MDF-e). Esta capacidade do MDF-e ser um lastro digital que registra uma operação de transporte devidamente vinculada à confirmação da existência e autenticidade da NF-e que originou a contratação da operação de transporte, conferem ao MDF-e uma condição única e de grande diferencial competitivo em relação a qualquer outro documento que se propõe a atuar como lastro de operações vinculadas aos serviços de transportes. São lastros que consideramos similares a cheques sem fundos, não vinculados aos seus saldos em conta, no caso a NF-e, que possibilitam a emissão de “lastros fictos” de transportes não vinculados aos processos comercias de vendas de mercadorias. Quando nos referimos ao MDF-e não estamos falando de um projeto futuro a ser desenvolvido nos próximos anos e sem escala, nos referimos a um dos melhores ecossistema de documentos fiscais do mundo, onde o MDF-e já é uma realidade implantada há mais de 10 anos, sendo sua utilização e emissão realizada de forma gratuita e sem a cobrança de tarifas para seus usuários, o que já disponibiliza, de imediato, um imenso estoque de recebíveis, sejam estes emitidos por autônomos (caminhoneiros) ou empresas do segmento de transportes, com segurança e atendimento aos requisitos impostos pelo sigilo fiscal das empresas. Toda essa infraestrutura disponibilizada pelas Secretarias de Fazenda dos Estados, trará uma grande oportunidade para financiadores que operam com antecipações de recebíveis, que terão seu raio de atuação ampliado para um gigantesco segmento atualmente inexplorado e com baixo nível de acesso a crédito. Para as Empresas de Transportes, esta nova linha de financiamento disponibilizará um fluxo de capital de giro que suprirá o desencaixe atual entre seus fluxos de recebimentos junto a seus embarcadores e os fluxos de pagamentos realizados para os Transportadores Autônomos contratados, que geralmente recebem a maior parte do frete a vista. Esta grande oportunidade de alavancagem financeira do segmento também trará vantagens para os caminhoneiros, que terão seu mercado de atuação ampliado a partir da capacidade de emissão de seus próprios documentos de transportes (MDF-e e CT-e), o que facilita a contratação direta dos seus serviços, eliminando a necessidade de intermediadores que diminuem suas receitas. Para isto, as Secretarias de Fazenda aprovaram legislação simplificando os documentos de transportes (Ajuste SINIEF 37/2019) e desenvolveram o App da Nota Fiscal Fácil, que já pode ser baixado através das plataformas IOS e Android. Os documentos de transportes emitidos a partir do Aplicativo da Nota Fiscal Fácil (MDF-e e o CT-e), diretamente do smartphone do caminhoneiro, também permitem aos seus contratantes a utilização do crédito do ICMS pago sobre o frete, vantagem tributária que não pode ser disponibilizada por outros tipos de documentos de transportes que venham a operar de forma paralela aos documentos fiscais. Por todas essas vantagens competitivas únicas, o MDF-e se consolida como um lastro digital que opera dentro de um ecossistema de negócios conectados, como o exemplo já citado do PIX. Quanto aos processos desconectados, como o exemplo dos cheques pré-datados, ou outros documentos não vinculados às suas NF-e e créditos do ICMS sobre o frete, já nascem obsoletos, duplicam obrigações, aumentam custos do segmento de transportes e, pior, são incapazes de atender as necessidades dos seus usuários e do implacável “Senhor Mercado”, que sabe fazer conta e julgar as melhores alternativas para manutenção de sua competitividade. ENCAT: Fazer acontecer e inovação são a nossa marca. Se você não viu nossos posts anteriores sobre este tema, publicados nas redes sociais do ENCAT e Portal de DF-e, não deixe de acessar nossas publicações nos canais descritos abaixo: 1) MDF-e: O Suporte Digital da Transformação dos Serviços de Transporte no Brasil (01/04/2021) Twitter: http://www.encat.org/?p=1760 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/2298 2) MDF-e: O Documento que Integra a Venda e a Entrega da Mercadoria (06/04/2021) Twitter: http://www.encat.org/?p=17686 Facebook: Encat Brasil Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/MDFE/Noticias/2302 3) MDF-e e NFF Lançam Inovador Conceito de ICMS Pré-pago Portal ENCAT: http://www.encat.org/?p=1824 Portal DF-e SVRS: https://dfe-portal.svrs.rs.gov.br/Mdfe/Noticias/2398

Olá, Recentemente diversas empresas estão emitindo boletos com QrCode para pagamento via PIX (Boleto Híbrido), ficando a critério do pagador escolher a forma de pagamento através da ficha de compensação "Código de Barras / Linha Digitável' ou com o PIX "QRCode". Mas até então isso não estava formalizado pelo Banco em si, ou seja, o controle de Baixa do título caso seja pago por PIX ficaria a cargo da própria empresa, como ocorre no fluxo de várias API hoje disponíveis no mercado... Porém, o Banco do Brasil foi o pioneiro em disponibilizar esse tipo de integração em sua própria API, assim ao registrar um Título pode ser definido se será gerado também uma chave PIX dinâmica referente aquele título, com isso o controle da forma de pagamento fica com o Banco, independente se for pago via PIX ou Boleto. Isso facilita muito o controle por parte da empresa beneficiária e viabilizou a implementação desse tipo de integração via API também no componente ACBrBoleto. No componente ACBrBoleto já existia a possibilidade de Registro Online de Boletos para alguns Bancos, inclusive o Banco do Brasil via WebService, mas essa API se trata de um novo Serviço, portanto são configurações e funcionalidades distintas no componente ACBrBoleto. Neste tópico vamos descrever como realizar a homologação e utilizar a API do Banco do Brasil através do componente ACBrBoleto. 1- Primeiro passo é realizar o Cadastro do seu Aplicativo no ambiente Sandbox BB, com isso será fornecido as credenciais para autenticação da API em ambiente de homologação. Utilize o Serviço API Cobrança: https://developers.bb.com.br/home Documentação da API e como utilizar o ambiente Sandbox para cadastrar a aplicação: https://apoio.developers.bb.com.br/referency/post/5ffc477c3b02bd0012ecaa1a 2- Após o Cadastro poderá obter o ClientID e ClientSecret que precisará configurar no componente ACBrBoleto, cada emitente terá seu próprio ClientID e ClientSecret. No componente ACBrBoleto configure em: Banco / TipoCobranca=cobBancoBrasilAPI No componente ACBrBoleto configure em: Cedente / CedenteWS ClientID=Informe o ClientID gerado no Ambiente Sandbox BB ClientSecret=Informe o ClientSecret gerado no Ambiente Sandbox BB Scope=cobrancas.boletos-info cobrancas.boletos-requisicao KeyUser=developer_application_key IndicadorPix=True //Para utilização do PIX pela API - Banco do Brasil é necessário que o emitente tenha chave PIX cadastrada no BB, caso for utilizar somente a emissão tradicional pela API enviar False nesse parâmetro. Em Configurações / WebService - Configure da seguinte Forma: Na opção de Ambiente escolher de acordo com a operação que esteja fazendo (Homologação ou Produção) necessário coerência com as chaves contratuais junto ao BB. As operações homologadas para a API BB são de Inclusão e Consulta [tpInclui, tpConsulta, tpBaixa, tpAltera] SSLHttpLib utilizar cryOpenSSL SSLType utilizar LT_TLSv1_2 3 - Com essas configurações já é possível realizar o registro de um título no BB via API. O Título deve ser incluso normalmente como no processo tradicional do componente, mas ao invés de gerar uma remessa, utiliza-se o o método "EnviarBoleto" - (botão no Aplicativo ACBrBoleto Demo: [Registrar Boleto On-Line]) . Este botão possui exemplos de como obter o Retorno da API. Se o título foi registrado sem nenhuma rejeição, automaticamente será atualizado a chave PIX junto ao Título. Particularidades BB via API: obs: API possui envio Síncrono Carteira=17 EspecieDoc=DM Modalidade=35 CodigoCedente=Informar Código Cedente Convenio=Informar o Convenio 4- Para imprimir o Boleto: Obs: Quando utilizado PIX, é necessário que além das informações tradicionais, sejam informadas no título o retorno do registro "QrCode" na propriedade "EMV", esse campo corresponde a String de geração do QRCode PIX gerada pelo Banco. ex: Titulo.qrcode.emv := FRetornoConteudoEMV; Impressão em FortesReport: Utilize o Layout "PadraoPIX" Impressão em FastReport: Selecione o arquivo "BoletoPIX.fr3" no diretório "Report" junto ao ACBrBoleto Demo. Segue o Modelo de Boleto Híbrido Impresso: 5- Consulta de Títulos via API Na aplicação ACBrBoletoDemo temos o botão "Consultar Boleto" com código exemplo de como passar os parâmetros para realizar uma consulta na API, o retorno será gerado em uma lista para posterior validação de cada Título. Obs: A homologação deve ser feita também junto ao Banco, inclusive enviando os modelos das Fichas de Compensação emitidas para validação. Todos os testes foram realizados em ambiente de homologação, então é importante a validação completa antes de emitir em ambiente de produção.

Eu consegui resolver....pode encerrar o topico. infEvento.detEvento.cOrgaoAutor := 43 //--------Aqui passei o codigo da UF emitente

Unit blcksock

Ola, Boa tarde Juliomar. Boa observação, deixo aqui registrado para se alguem passar pelo mesmo, No meu caso o que faltava era configurar a Ordenação dos Paths, em : Configuracoes - Arquivos - OrdenacaoPath - Coloquei como Primeiro Parametro "CNPJ" e em seguida "Data" e ficou como estava precisando.

Boa tarde. Depois do meu primeiro tópico aqui no fórum, onde eu buscava uma solução para a importação do BLOCO_G gerado por empresa terceirizada, Agora venho lhes trazer a aplicação que desenvolvi para tal função. Essa aplicação não só importa o Bloco G, mas também insere o crédito no Registro E110, calcula o valor do ICMS apurado e atualiza o valor do ICMS a ser pago no Registro E110 e no E116, também insere o código de Ajuste RS... no Registro E111 (Vale lembrar que este código varia de UF para UF). De quebra, como o ERP que usamos não zera as DANFEs REFERENCIADAS de cupons fiscais ao exportar o arquivo do SPED, então criei uma rotina para zerar as Danfes com CFOP 5929. Registros C100 e C190 de saída. Estou deixando aqui a minha contribuição para com esta comunidade que me foi muito útil, deixo os fontes (COMENTADOS) da aplicação e a atualização do ACBrEFDBloco_G_Importar. ACBrEFDBloco_G_Importar.pas Ciap.dpr Ciap.dproj Ciap.dproj.local Ciap.identcache Ciap.res Ciap_Icon.ico Principal.dfm Principal.pas

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Boa tarde. Lembrando que é altamente recomendado se utilizar o ACBrNFSeX, já que o antigo ACBrNFSe não receberá mais atualizações. Att.

Muito obrigado meu amigo, reinstalei o Acbr e deu certo, ainda bem que tem pessoas pra ajudar a gente, obrigado....

Bom dia Sim é possível mas lembrando que é provável que vá precisar de liberações por parte deles até mesmo para tu testar com a dll. deixa ver se faço e subo

Está sendo gerado o item vlrSenarSusp no lugar de vlrSenarNRet, causando erro ao gerar xml. Erro retornado: Falha na validação dos dados do evento: evtAquisicaoProdRural-v1_05_01 1871 - Element '{http://www.reinf.esocial.gov.br/schemas/evt2055AquisicaoProdRural/v1_05_01}vlrSenarSusp': This element is not expected. Expected is ( {http://www.reinf.esocial.gov.br/schemas/evt2055AquisicaoProdRural/v1_05_01}vlrSenarNRet ). Linha que causa o problema: Gerador.wCampo(tcDe2, '', 'vlrSenarSusp', 1, 14, 0, item.vlrSenarNRet); Agradeço desde já! Segue em anexo arquivo com a correção. pcnReinfR2055.pas

Correção já no svn. obrigado.

Provavelmente esse é o problema. Você está usando uma rotina que encontra portas do componente Esc/Pos pra alimentar a propriedade impressora do DANFE em Fast, que não são compatíveis. Código que tenho na minha tela de configuração: // Para o componente DANFE em Fast cmbImpressoraGraficoINF.Items.Assign(Printer.Printers); cmbImpressoraGraficoINF.Items.Insert(0, ''); // Para o componente DANFE em Esc/Pos cmbDriverUSBINF.Items.Clear; Device := TACBrDevice.Create(nil); try Device.WinUSB.FindUSBPrinters; for K := 0 to Device.WinUSB.DeviceList.Count - 1 do cmbDriverUSBINF.Items.Add(Device.WinUSB.DeviceList.Items[K].DeviceName); finally Device.Free; end; cmbDriverUSBINF.Items.Insert(0, '(automático)');

Pra essa propriedade deve passar o nome da impressora no Windows, não o caminho. Não é o mesmo que a propriedade Porta do componente Esc/Pos.

Boa tarde, eu também ja reparei neste detalhe, ja me perguntaram tambem, se dava pra definir um caminho/pasta padrão pra salvar o pdf, mas ainda não consegui estudar os fontes pra ver... acho q faz sentido, por exemplo, poderia ter essa opção/propriedade no componente RLPreviewSetup... Atr Ricardo

Eu vou tentar fazer aqui , no meu aplicativo utilizar o arquuivo sai.txt , deve dar certo , obrigado. amanha te dou retorno, muito obrigado pela dica.

Italo, muito obrigado. Vocês são incríveis. Mais uma vez obrigado. Agora, bora implementar !!!!!

Olá, Para quem utiliza a ACBrLibBoleto será necessário pequenos ajustes nas chamadas de alguns métodos dessa biblioteca. Essas melhorias foram realizados por questões de Padronização de performance. As alterações se fazem necessárias a partir da versão 0.2.0.101 da ACBrLibBoleto Essas alterações já estão atualizadas no manual da ACBrLib: https://acbr.sourceforge.io/ACBrLib/MetodosBoleto.html Basicamente as mudanças estão em alguns métodos que NÃO necessitam de respostas, então o retorno passa a ser o código padrão da biblioteca. Ou quando a resposta é apenas um valor "Inteiro" . Exemplos: Antes: Boleto_IncluirTitulos(eArquivoIni, [eTipoSaida], sResposta, esTamanho); Atual: Boleto_IncluirTitulos(eArquivoIni, [eTipoSaida]); Retorno Atual: 0 Indica que a função foi executada corretamente. -10 Indica que houve falhas na execução do método Retorno com Valor Inteiro: Antes: Boleto_TotalTitulosLista(sResposta, esTamanho) Depois: Boleto_TotalTitulosLista() Retorno Atual: 15 Indica o Total de Títulos Incluídos na Lista -10 Indica que houve falhas na execução do método Segue abaixo todos os Métodos Atualizados (removendo os parâmetro "sResposta", "esTamanho") Boleto_ConfigurarDados(eArquivoIni) Boleto_IncluirTitulos(eArquivoIni, [eTipoSaida]) Boleto_TotalTitulosLista() Boleto_SetDiretorioArquivo(sDiretorio, [sArquivo]) Boleto_TamNossoNumero(sCarteira, sNossoNumero, sConvenio) Boleto_SelecionaBanco(CodBanco) Os exemplos estarão disponíveis nos aplicativos demonstração da ACBrLibBoleto.

Boa noite Rômulo, Já esta no SVN.

Olá pessoal, Abaixo temos a lista de todos os provedores implementados no novo componente. // Provedores que seguem a versão 1 do layout da ABRASF: BHISS, CIGA, DBSeller, DSFSJC, FISSLex, geNFe, Ginfes, GovBr, ISSCuritiba, ISSFortaleza, ISSIntel, ISSNet, Lexsom, MetropolisWeb, Natal, NFSeBrasil, Publica, Recife, RJ, Salvador, SJP, SpeedGov, Thema, Tinus. // Provedores que seguem a versão 2 do layout da ABRASF: ABase, Actcon, Adm, ADPM, AEG, Asten, Centi, Coplan, DataSmart, DeISS, Desenvolve, Digifred, DSF, EloTech, eReceita, fintelISS, Fiorilli, Futurize, Giss, Goiania, GovDigital, iiBrasil, ISSDigital, ISSe, ISSJoinville, Link3, MegaSoft, Mitra, ModernizacaoPublica, NEAInformatica, NotaInteligente, Prodata, PVH, RLZ, Saatri, SafeWeb, SH3, Siam, SiapNet, SiapSistemas, SigCorp, Sigep, SisPMJP, Sistemas4R, SystemPro, TcheInfo, Tecnos, Tributus, VersaTecnologia, Virtual, Vitoria. // Provedores que seguem a versão 1 e 2 do layout da ABRASF: Abaco, Betha, Pronim, SilTecnologia, SimplISS, Tiplan, WebISS. // Provedores que tem layout próprio e também seguem a versão 1 ou 2 do layout da ABRASF: EL, Infisc, SmarAPD. // Provedores que tem layout próprio: Agili, AssessorPublico, Conam, eGoverneISS, Equiplano, GeisWeb, Giap, Governa, IPM, ISSDSF, Lencois, Siat, SigISS, SP, WebFisco.

Na verdade estava vacilando aqui. Tava gerando o protocolo sim. O problema é que o evento de fechamento não estava sendo aceito pois com a versão 1.05.01 do Rein, se a empresa não comprar direto do produtor, o sistema tem que especificar que não faz compra de produto para que o R-2055 seja obrigatório o envio.

Não. É usuário windows com direito de administrador. Mas resolveram o problema. O Certificado recém comprado, estava com problema e ocasionava isso. Cliente adquiriu um novo certificado, excluiu novo que estava com problema e voltou a funcionar normalmente. Problema resolvido