Painel de líderes

Olá pessoal, A seguir colocamos os tópicos deste workshop do Dia do ACBr 2023 e um resumo do que foi abordado. 1. Documentação, Manuais e NTs Sempre indicamos a leitura dos Manuais e NTs, pois são as fontes de onde o ACBr extrai informações para o desenvolvimento dos componentes 1.1. Todos os documentos relacionados ao Reinf https://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ 1.2. Manual de Orientação ao Desenvolvedor: Leitura essencial para entender como funciona o Reinf e seus métodos https://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ManDesenvolvedor/ManualOrientacaoDesenvolvedor-REINF-v2.3.pdf 2. Sequência lógica: Consta no Manual de Orientação ao Desenvolvedor (item 1.2) 3. TLS 1.2 A partir de janeiro de 2024 a comunicação será exclusiva com TLS 1.2 Isso seria implementado em outubro de 2023, mas foi postergado Existem relatos de certificados A3 que não estão funcionando com o TLS 1.2 e isso é um problema recorrente com alguns DFes e alguns certificados 4. Qual a diferença entre as versões? A versão 1.5 é Síncrona e SOAP, a 2.1 é Assíncrona e REST Ambas trabalham com envio e retorno via XML A versão 1.5 seguirá ativa por 6 meses após o início da versão 2.1, que foi em 09/2023 A versão 1.5, por ser síncrona, recebe o retorno do processamento automaticamente ao enviar os eventos e a versão 2.1, por ser assíncrona, devolve o número do protocolo para ser consultado posteriormente e obter o resultado do processamento A consulta de protocolo já existia na versão 1.5 para o registro R2099, que era o único assíncrono nesta versão 5. Registros 4000 São exclusivos da versão 2.1, não sendo possível o envio na versão 1.5 6. Consulta de Recibo O número do recibo, além de um comprovante do processamento, será necessário para a retificação ou exclusão de um evento Ao consultar o protocolo, o número do recibo e devolvido e se for armazenado neste momento, não será necessária a utilização da Consulta de Recibo para este fim O método possui diversos parâmetros, pois para cada tipo de registro são necessários dados específicos. No Manual de Orientação ao Desenvolvedor (item 1.2) é possível iedntificar os parâmetros para cada tipo de registro 7. Processo padrão Na versão o processo é dividido em: Preenchimento do Componente, Envio e Consulta do Protocolo 7.1. Preenchimento do componente Pode ser feito via código alimentando as propriedades do componente, através de leitura de arquivo INI seguindo o padrão ACBr ou de XML seguindo o leiaute do Reinf O preenchimento através de arquivo INI, suporta o limite de 50 eventos por lote e o preenchimento lendo XML no leiaute do Reinf exige que seja lote de apenas 1 evento 7.2. Envio Quando o componente estiver preenchido com uma das opções do item 7.1 o lote deverá ser enviado Ao enviar o lote, será recebido o número do protocolo para que seja feita a consulta, que retornará o resultado do processamento 7.3. Consulta do Protocolo Ao consultar o protocolo recebido no item 7.2 será recebido o retorno do processamento Caso ocorram erros, será retornada uma lista contendo 1 ou mais erros identificados pelo serviço Caso o lote tenha sido processado com sucesso, será retornado o número do recibo e demais informações relacionadas a cada tipo de evento 8. Método de Limpeza da base de Produção Restrita (Homologação) Lembrando que este método só é possível ser utilizado na base de testes, conforme destacado no item Enviar o Registro R1000 Como evento de Alteração IdeEvento.VerProc = 'RemoverContribuinte' ClassTrib = ct00 // ct00 é um enumerado utilizado somente para este fim 9. Informações adicionais Existe um limite estipulado pelo serviço de 50 eventos por lote A RFB recomenda que os Registros R2099 e R4099, de fechamento, sejam enviados em lotes isolados, após a consulta e confirmação de processamento de todos os demais registros

Recepção dos Cupons Fiscais Eletrônicos (CFes) emitidos com o leiaute da versão 0.07 8 de novembro de 2023 - 16:11 A Secretaria da Fazenda do Ceará (Sefaz-Ce) informa que, continuará a recepcionar os Cupons Fiscais Eletrônicos (CFes) emitidos com o leiaute da versão 0.07 até 31 de dezembro de 2024. Esclarece ainda que, no decorrer de 2024, os leiautes nas versões 0.07 , 0.08 e 0.09 do CFe poderão ser utilizados pelos aplicativos comerciais dos contribuintes. O órgão destaca que os fabricantes do equipamento Módulo Fiscal Eletrônico (MFE) já estão realizando os processos de homologação dos softwares básicos com a versão mais atual. A Sefaz alerta que é imprescindível o planejamento por parte das softwares houses para a realização de todas as adaptações técnicas exigidas pela Especificação Técnica de Requisitos SAT 2.30.03 ou posteriores, que se encontram disponíveis no PortalCFe. Para mais informações, os contribuintes podem entrar em contato pelo email [email protected]. https://cfe.sefaz.ce.gov.br/mfe#/

@CrasH, @Tiago Domingues Carneiro, @Dor_poa, e outros Subi no SVN uma correção. Deve estar tudo ok agora.

Boa tarde Pessoal! Aquem interessar possa, segue a Tabela CEST (Código Especificador da Substituição Tributária) retirada do Convenio 142/18 (Incluido as alterações até o Convenio 53/2023) Fonte: https://www.confaz.fazenda.gov.br/legislacao/convenios/2018/CV142_18 (09/10/2023) Att, Luciano CEST Convenio 142-18 - 2023 10.csv

Alo pessoal, é com muito orgulho que trago o primeiro esboço do exemplo de Flutter com ACBrLIB NFE! billbarsch/flutteracbrlib: Exemplo de uso das DLL's do projeto ACBR no Flutter (github.com) Todas as funções da dll de NFE foram implementadas, ainda nao testei tudo mas ja é 99% do caminho andado! Acredito que em breve com ajuda de outros possamos ter aplicações flutter emitindo notas, conectando com balanças, abrindo gavetas registradoras, o céu é o limite! Meus agradecimentos ao ACBr pelo magnífico trabalho sempre. Agora vou testar emissao, leitura de certificados etc e os proximos passos serão rodar no linux e talvez porque nao android??? e implementar mais dll's do projeto

Olá Pessoal, O nosso amigo @gabriel.hilbig, descobriu como resolver o erro E0536. Vamos a dica dele: Fazendo o DPS direto no PORTAL preenchimento automático <regApTribSN>1</regApTribSN> //-> 1 – Regime de apuração dos tributos federais e municipal pelo SN; Fazendo pelo Aplicativo , usando REST API é necessário preencher <regApTribSN>2</regApTribSN> //->2 – Regime de apuração dos tributos federais pelo SN e ISSQN por fora do SN conforme respectiva legislação municipal do tributo; Solução para PORTO ALEGRE , não sei outras cidades A mensagem de erro não ajuda nada para resolver o problema Não existe nenhuma documentação a respeito nem Federal e nem municipal O desenvolvedor precisa resolver na TENTATIVA E ERRO Esta solução acaba por criar um imposto pendente. Sugiro a todos os prestadores de serviços e desenvolvedores que protocolem na prefeitura uma reclamação sobre o problema. Não sei se é questão de configuração errada no ambiente de produção, pois tenho relatos que em ambiente de homologação (Produção Restrita com a RFB o chama) esta funcionando ou se o problema é na API desenvolvida pelo SERPRO. Quanto mais pessoas protocolarem o problema as chances de resolver mais rápido aumenta, pois a prefeitura talvez nem saiba que isso esta ocorrendo.

@Jamil Araujo Enviamos para o SVN algumas alterações. Solicitamos uma compilação da lib acredito que dentro de alguns minutos estará disponível para download. Então na próxima compilação vai estar inclusa a alteração. favor testar e nos dar um feedback. Abr !

Conseguimos chegar até esse ponto também.... fiz o cadastro pro login, mas o resto não funciona nada na página infelizmente. Não tem informação e o "cadastro de parceiro", acho que era esse o nome, dá erro.

@Jamil Araujo boa tarde ! ainda não foi concluida a tarefa. Assim que concluida reportamos aqui.

@tryideas sistemas EndPoints da V2: C_URL_HOM = 'https://api-parceiro.sicredi.com.br/sb/cobranca/boleto/v1'; C_URL_OAUTH_HOM = 'https://api-parceiro.sicredi.com.br/sb/auth/openapi/token'; ECOMM: C_URL_HOM = 'https://cobrancaonline.sicredi.com.br/sicredi-cobranca-ws-ecomm-api/ecomm/v1/boleto'; C_URL_OAUTH_HOM = 'https://cobrancaonline.sicredi.com.br/sicredi-cobranca-ws-ecomm-api/ecomm/v1/boleto/autenticacao'; https://developers.sicoob.com.br/portal/apis

Boa tarde Dercide, O provedor GovDigital segue a versão 2 do layout da ABRASF e consta na unit GovDigital.Provider os seguintes serviços: TACBrNFSeXWebserviceGovDigital200 = class(TACBrNFSeXWebserviceSoap11) public function Recepcionar(ACabecalho, AMSG: String): string; override; function RecepcionarSincrono(ACabecalho, AMSG: String): string; override; function GerarNFSe(ACabecalho, AMSG: String): string; override; function ConsultarLote(ACabecalho, AMSG: String): string; override; function ConsultarNFSePorRps(ACabecalho, AMSG: String): string; override; function ConsultarNFSePorFaixa(ACabecalho, AMSG: String): string; override; function ConsultarNFSeServicoPrestado(ACabecalho, AMSG: String): string; override; function ConsultarNFSeServicoTomado(ACabecalho, AMSG: String): string; override; function Cancelar(ACabecalho, AMSG: String): string; override; function SubstituirNFSe(ACabecalho, AMSG: String): string; override; function TratarXmlRetornado(const aXML: string): string; override; end; Note que temos o serviço Recepcionar (que funciona no modo assíncrono), o RecepcionarSincrono e o GerarNFSe (envio unitário). Por padrão o componente define envio em lote modo síncrono para os provedores que seguem a versão 2 do layout da ABRASF, pois desta forma permite um envio em lote (até 50 RPS) e no retorno já temos o resultado do processamento. Agora se o provedor, apesar de disponibilizar todos os serviços, alguns deles não funcionam a contento devemos através do método Emitir selecionar o modo de envio mais adequado.

Boa tarde Willian, Já inclui na minha lista de tarefas para analise. TK-4723

bom dia, Sim está correta, acontece que parece que houve mudanças no componente e fazia um certo tempo que não mexia com boletos. Mas atualizei os componentes como de costume e agora estou fazendo as devidas alterações na aplicação. Pode fechar o tópico. Obrigado.

Bom dia Criada a TK-4719 para avaliação. Obrigado pela contribuição.

Bom dia Pessoal. Renomeei os arquivos aqui e deu certo, ficou muito mais rápido. Arquivos renomeados: - LOG.TXT - ACBrSAT.log Muito obrigado.

Bom dia pessoal! Ao consultar na página do Sobre o SAT, consta uma aviso informando que haverá uma manutenção na AC do sistema SAT no dia 03/12 com previsão de inicio às 08h00 e término às 12h00. É recomendado que às ativações de equipamentos SAT sejam realizadas fora do período da janela de manutenção.

Bom dia pessoal! Conferindo no dia 13/11/2023, às 08h01 no Portal da NFe, é possível observar que a Sefaz de Minas Gerais está com contingência ativada desde às 07h42 e com previsão de permanecer ativa até às 10h00. Um agradecimento ao membro @Jonas_Farsoft por compartilhar a informação em nosso Discord.

Ainda não... No momento apenas com Delphi FMX

Poste mais informações sobre o seu problema e o que já tentou fazer para resolver. Já fez isso? Já testou as outras opções de SSLType? Tente também: * Reinstalar o certificado * Trocar de porta * Atualizar driver * Atualizar cadeias de certificados

Sim, ChaveCTE:= frmPrincipal.ACBrCTe1.Conhecimentos.Items[0].CTe.procCTe.chCTe;

Exato... por CNAB a sequencia de operações é exatamente essa. Caso vc precise da impressão de uma forma mais "rápida" normalmente é melhor fazer por webservice/API (Caso o banco tenha o serviço disponível) porque aí o retorno com o EMV é imediato.

Boa tarde @Gr@c@, Vários provedores tem problemas nos ambientes de homologação e alguns não tem mesmo. Chegou a tentar emitir em produção? Algumas vezes a rotina é emitir em produção com um valor baixo e depois cancelar se possível.

Olá pessoal! O colega @josemarciossoares, que estava recebendo está rejeição ao emitir CT-e, mesmo com o cadastro do emitente em ordem na Sefaz respectiva também compartilhou uma dica. Ele conseguiu resolver o problema depois de descobrir que, além de estar cadastrado na Sefaz da UF, o emitente precisa também estar cadastrado no CCC, tanto em produção quanto em homologação.

[TEMPORARIAMENTE DESABILITADO] 2.13. PSP Mercado Pago Ambiente de Homologação O PSP Mercado pago não possui um ambiente específico de homologação, porém é possível sim testar com credenciais de teste mesmo em ambiente de produção. Para conseguir essas credencias, siga os passos à abaixo: - Utilizar uma conta já existente ou criar uma nova conta no Portal de Desenvolvedores do MercadoPago: https://www.mercadopago.com.br/developers - Entrar na opção "Suas integrações" e criar uma nova aplicação, como na imagem a seguir: - Após entrar na sua aplicação, selecione a opção "Credenciais de Teste" - Basta preencher os dados Public Key e Access Token no componente ACBrPSPMercadoPago e vc conseguirá efetuar testes. (OBS: Como foi citado acima, o Mercado Pago NÃO POSSUI ambiente próprio para testes. Então o componente deverá estar configurado para ambiente de PRODUÇÃO, mas com credenciais de TESTE). Ambiente de Produção - Para utilizar o ambiente de produção, basta entrar na sua aplicação já criada no portal de desenvolvedores na opção "Credenciais de Produção" - Preenchendo os dados no componente ACBrPSPMercadoPago já será possível gerar cobranças em ambiente de produção.

Olá Pessoal, O nosso amigo @Fabiano Oliveira de Castro incluiu o código abaixo na procedure que alimenta o componente com os dados do serviço prestado e com isso resolveu esse erro. if OptanteSN = osnOptanteMEEPP then begin Servico.Valores.totTrib.indTotTrib := indSim; Servico.Valores.totTrib.pTotTribSN := 2.01; end; O valor atribuído em pTotTribSN pode ser diferente de uma cidade para outra.

Olá pessoal, O nosso amigo @gabriel.hilbig, descobriu como resolver o erro E0330. Vamos a dica dele: Erro E0330-É obrigatório prestar informações de todos os campos relativos ao comércio exterior Necessário entrar no PORTAL NFSE e finalizar configuração e fazer uma nota de teste O Cadastro da empresa fica sem definição de ME/EPP no inicio.

Atualização do tópico... Na Adquirente VERO, o cartão Alelo Alimentação é tratado como uma transação de DÉBITO Isso é uma característica dessa adquirente, e se você tentar transacionar cartões da Alelo Alimentação, como Voucher, receberá um erro: -2436 NAO EXISTEM PRODUTOS COMPATIVEIS Sendo assim, para usar Alelo na VERO, informe ou escolha a opção Debito na transação No ACBr, uma chamada de comandos para sempre usar Débito seria algo como: ACBrTEFAPI1.EfetuarPagamento( NumDocVenda, AValor, [], [teftcDebito]); ou ainda, sem especificar parâmetros, e escolher a opção 2-Débito, quando for solicitada pelo TEF ACBrTEFAPI1.EfetuarPagamento( NumDocVenda, AValor );

Olá Pessoal, Recentemente foi publicado a Nota Técnica 2023/002 que trata sobre a alteração do retorno da Consulta a Situação do MDF-e. No retorno passamos a ter o grupo <procInfraSA> com os campos: nProtDTe e dhProt. O que vem a ser? Trata-se do grupo de informações do compartilhamento do MDF-e com InfraSA para a geração do DTe. Para quem não sabe houve uma tentativa de se criar um novo documento fiscal chamado DTe - Documento Eletrônico de Transporte criado pelo Ministério da Infraestrutura através da Medida Provisória numero 1051 de 18/05/2021. Que segundo o Ministério se tratava de uma conquista dos caminhoneiros e que iria revolucionar o setor de Transporte de Carga no Brasil. Mas na verdade o DT-e nada mais era do que o nosso velho conhecido e consolidado MDF-e e tem mais, o DT-e teria um custo para as transportadoras sendo que o MDF-e é gratuito. Depois de muita briga a SEFAZ, mais precisamente a do Rio Grande do Sul uma vez que é ela que recepciona todos os MDF-e de todas as UF, entrou em um acordo com o Ministério da Infraestrutura. Esse acordo visa o compartilhamento de dados do MDF-e com a InfraSA, desta forma o DTe passa a ser apenas um portal e não mais um documento. Como é que a coisa vai funcionar? A Transportadora envia o MDF-e para a SEFAZ Virtual do RS (responsável pela recepção), se todas informações estiverem corretas será retornado o numero do protocolo de autorização do MDF-e. Em seguida a SEFAZ Virtual do RS compartilha os dados do MDF-e com a InfraSA e esta retornará o numero do protocolo bem como a data e hora da geração do protocolo acusando que o DT-e foi gerado com sucesso pela InfraSA. Na Nota Técnica não fica claro se o compartilhamento é imediato ou não, mas deixa claro que essas duas informações (protocolo e data/hora) só vão estar disponíveis após o compartilhamento e para os modais ferroviário e rodoviário. Portanto se logo após obter o protocolo de autorização do MDF-e, se você consultar a situação do mesmo não constar essas informações isso significa que o MDF-e ainda não foi compartilhado com a InfraSA, neste caso devemos aguardar um tempo e tentar novamente. E qual a finalidade para nós desenvolvedores? Na Nota Técnica não deixa claro se devemos armazenar essas informações ou não, e se elas vão ser necessárias para uma consulta posterior via portal ou webservice. Caso você decida em guardar, lembre-se que são dois campos: o Numero do Protocolo de Geração do DTe e a Data e Hora de Geração do Protocolo. Vincule essas duas informações ao MDF-e, uma vez que para cada MDF-e emitido teremos o protocolo e a data/hora de geração do DTe. Espero ter esclarecido o que vem a ser e o que fazer com essas duas novas informações.

Versão incorreta da OpenSSL Experimente copiar as DLLs na versão especifcida abaixo para dentro da pasta que se encontra o executável da sua aplicação/projeto . ACBr\DLLs\OpenSSL\1.1.1.10\X86 ou ACBr\DLLs\OpenSSL\1.1.1.10\X64 dependendo da compilação da sua aplicação. Elas podem ser encontradas na pasta do ACBr baixada pelo SVN, ou pelo link abaixo: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/

Olá pessoal! Aqueles que fazem uso dos componentes do ACBr se deparam rotineiramente com duas propriedades que a princípio parecem ser redundantes. Estou falando de: //Configuração no componente ACBrDFe.Configuracoes.Geral.VersaoDF //Preenchimento do DFe no componente ListaDFes.Items[Indice].MeuDFe.InfDFe.Versao No entanto, apesar de parecerem se tratar da mesma informação, cada uma das propriedades tem funções diferentes. ACBrDFe.Configuracoes.Geral.VersaoDF: está configuração no componente, define para qual web service será encaminhado o XML. Ela também afeta algumas configurações do arquivo de envelope da requisição, que é o arquivo XML acrescido de mais informações para ser enviado a Sefaz. ListaDFes.Items[Indice].MeuDFe.InfDFe.Versao: está propriedade define qual é a versão do XML. Está é uma informação importante, necessária e obrigatória nos layouts dos DFes. Mas então você pode perguntar: Ou se você já abriu os fontes do ACBr para analisar: O ACBr faz isso como uma tentativa de ajudar os desenvolvedores, mas isso não deve ser confundido. Atualmente, a versão do XML deve coincidir com a versão do web service. Imagine uma situação em que é carregado/preenchido um NF-e com a versão 4.00, mas a versão DF configurada no componente é a 3.00? Vai ocorrer erro. Por isso o ACBr faz essa distinção para ajudar. Não. Como já foi dito, as propriedades tem funções distintas, uma é a versão do web service e a outra é a versão do XML. Imagine uma possibilidade no futuro de que a Sefaz crie uma nova versão do web service que permita receber XMLs de diferentes versões? Se uníssemos essas propriedades agora, não seria possível enviar versões diferentes usando componente.

Bom dia Devs ! Agora você pode enviar o comando para alterar o TimeZone do ACBrMonitor Plus. Comando: NFe.SetTimeZone(nModo, cTimeZone) Parâmetros: nModo = Inteiro; cTimeZone = String; (obrigatório quando o nMODO for tzManual) Tabela nTIPO: 0 = tzSistema 1 = tzPCN 2 = tzManual Exemplos: Para configurar TimeZone padrão do Sistema: NFe.SetTimeZone(0) Para configurar TimeZone padrão do PCN: NFe.SetTimeZone(1) Para configurar TimeZone padrão do Manual (Brasilia DF) NFe.SetTimeZone(2,-03:00)

Olá pessoal, neste tópico vamos falar sobre o uso dos cartões Banrisul no TEF PayGo. É importante lembrar que: Banricompras à Vista = É uma transação de Débito à Vista na Bandeira Banricompras. Banricompras Pré-Datado = É uma transação de Débito Pré-Datado na Bandeira Banricompras. Não é um parcelamento e sim um único débito agendado para um prazo definido que pode variar entre 5 até 60 dias (parcela única). Banricompras Parcelado = É uma transação de Débito em 2 ou mais parcelas, na Bandeira Banricompras. Normalmente é usado entre 2 a 12 parcelas com débito a cada 30 dias. É semelhante ao Pré-Datado, só que é mais de 1 débito agendado. Mas é importante lembrar que não é uma transação de Crédito. Devido grande demanda dos pedidos de TEF no Estado Rio Grande do Sul... muitos estabelecimentos utilizam o cartão Banrisul e este tipo de cartão é bem especifico na região... Para que a automação possa utilizar este tipo de cartão nas transações TEF pela PayGo, precisamos seguir alguns passos, como por exemplo: 1 - Transacionar apenas na opção débito.. 2 - Essa transação débito, ela pode ser à vista ou pré-datado. E como vamos fazer isso utilizando os componentes ACBrTEFD e ACBrTEFAPI ? Começando pelo componente ACBrTEFD: Exemplo Débito à vista: procedure InformarParametrosCartaoDebito; begin // Instruindo CRT a apenas transações de Débito if (ACBrTEFD1.GPAtual = gpPayGoWeb) then begin ACBrTEFD1.TEFPayGoWeb.ParametrosAdicionais.ValueInfo[PWINFO_CARDTYPE]:='02'; //02: débito ACBrTEFD1.TEFPayGoWeb.ParametrosAdicionais.ValueInfo[PWINFO_FINTYPE]:='01'; //01: à vista end else if (ACBrTEFD1.GPAtual = gpCliSiTef) then ACBrTEFD1.TEFCliSiTef.OperacaoCRT := 2; end; Exemplo Débito Pré-datado: procedure InformarParametrosCartaoDebito; begin // Instruindo CRT a apenas transações de Débito if (ACBrTEFD1.GPAtual = gpPayGoWeb) then begin ACBrTEFD1.TEFPayGoWeb.ParametrosAdicionais.ValueInfo[PWINFO_CARDTYPE]:='02'; //02: débito ACBrTEFD1.TEFPayGoWeb.ParametrosAdicionais.ValueInfo[PWINFO_FINTYPE]:='08'; //08: pré-datado end else if (ACBrTEFD1.GPAtual = gpCliSiTef) then ACBrTEFD1.TEFCliSiTef.OperacaoCRT := 2; end; Agora utilizando o componente ACBrTEFAPI, temos duas formas de informar os parâmetros, uma opção é usar a Function EfetuarPagamento: Exemplo Débito à vista: ACBrTEFAPI1.EfetuarPagamento( IntToStr(Venda.NumOperacao), AValor, tefmpCartao, teftcDebito, tefmfAVista); Exemplo Débito Pré-datado: ACBrTEFAPI1.EfetuarPagamento( IntToStr(Venda.NumOperacao), AValor, tefmpCartao, teftcDebito, tefmfPredatado); Outra opção é usar um TypeCast e inserir as propriedades diretamente na classe de TEF: Exemplo Débito à vista: if ACBrTEFAPI1.TEF is TACBrTEFAPIClassPayGoWeb then begin with TACBrTEFAPIClassPayGoWeb(ACBrTEFAPI1.TEF) do begin TEFPayGoAPI.ParametrosAdicionais.ValueInfo[PWINFO_CARDTYPE] := '2'; // Tipo Cartão: Débito TEFPayGoAPI.ParametrosAdicionais.ValueInfo[PWINFO_FINTYPE] := '1'; // Modalidade de financiamento da transação: À vista end; end; Exemplo Débito Pré-datado: if ACBrTEFAPI1.TEF is TACBrTEFAPIClassPayGoWeb then begin with TACBrTEFAPIClassPayGoWeb(ACBrTEFAPI1.TEF) do begin TEFPayGoAPI.ParametrosAdicionais.ValueInfo[PWINFO_CARDTYPE] := '2'; // Tipo Cartão: Débito TEFPayGoAPI.ParametrosAdicionais.ValueInfo[PWINFO_FINTYPE] := '8'; // Modalidade de financiamento da transação: Pré-datado end; end; Qualquer dúvida nos procure nos canais do Discord.. Até a próxima

Olá Pessoal, Foi feita uma alteração no componente ACBrNFSeX no que se refere a obter a Descrição do Item de Serviço. A função CodItemServToDesc que se encontrava na unit ACBrNFSeXConversao foi removida. Porque isso foi feito? Para evitar alteração no código do componente caso amanhã tivéssemos que acrescentar novos códigos e suas respectivas descrições. Como ficou agora? Foi criado o arquivo TabServicos.ini e o Compila_RES foi alterado para criar/atualizar o TabServicos.res Como vai funcionar agora? A sua aplicação a principio vai procurar o código e usar a descrição que consta no arquivo TabServicos.res que esta incorporado ao EXE da da aplicação. Mas, se você desejar poderá usar o arquivo TabServicos.ini alterado para contemplar descrições diferentes usadas pela cidade em questão, mas para isso você vai ter que copiar o arquivo INI para dentro da pasta do seu EXE ou na propriedade de configuração: Configuracoes.Arquivos.IniTabServicos informar path onde se encontra o arquivo TabServicos.ini Existe ainda uma outra opção que é copiar para dentro da pasta do EXE o arquivo TabServicos.txt alterado para contemplar descrições diferentes e configurar a propriedade de configuração: Configuracoes.Arquivos.TabServicosExt com o valor True. Observações importantes: 1. O arquivo TabServicos.txt tem que ficar dentro da pasta do seu EXE e não podemos alterar o seu nome. 2. O arquivo TabServicos.ini pode ficar em qualquer pasta que você desejar e podemos alterar o seu nome. Caso o seu nome venha a ser alterado na propriedade de configuração IniTabServicos devemos informar além do Path o nome do arquivo INI. 3. O uso do arquivo INI da forma que foi implementado deixa o componente mais versátil, pois vai nos permitir a ter uma tabela de códigos e suas respectivas descrições de serviços para cada provedor ou cidade se assim for necessário.

Boa tarde! O provedor SoftPlan faz uso de informações de autenticação para que as requisições possam ser feitas com sucesso. Por causa disso, ao emitir NFS-e para as cidades atendidas por este provedor, o primeiro método a ser usado é o GerarToken, para conseguir um Token de acesso que deve ser fornecido nos métodos posteriores. Para a correta geração do Token, as seguintes informações devem ser fornecidas: Um membro de nossa comunidade, em contato com o provedor conseguiu a seguinte correlação: client_id e client_secret são fornecidos por desenvolvedor pelo provedor. username é a inscrição municipal do prestador. password é o MD5 da senha usada para acessar o portal em maísculo.

Boa tarde pessoal ! Alguns bancos utilizam certificados crt, pem e key na sua autenticação. Vou mostrar como exportar a partir de um certificado A1 (.pfx)! OBS. Essa operação é possível apenas com o certificado do tipo A1. Com o A3 não é possível! Primeiramente você vai precisar ter em seu computador o executável do OpenSSL, ou seja, o OpenSSL.exe. Uma dica para download é https://gnuwin32.sourceforge.net/packages/openssl.htm baixe o arquivo binaries.zip e descompacte em uma pasta de sua preferência. O Executável (OpenSSL.exe) vai estar dentro da pasta que você criou em uma pasta chamada “bin” Você precisa entrar no prompt de comando acessar esta pasta para executar os comandos, ou adicionar ela no path do windows. Eu descompactei o arquivo zip em c:\openssl e vou abrir o prompt de comando, e acessar a pasta bin com o comando: cd\openssl\bin Meu certificado está na pasta c:\certificado Gerar o arquivo PEM: openssl pkcs12 -in c:\certificado\Certificado.pfx -nokeys -out c:\certificado\Certificado.pem Gerar o arquivo CRT: openssl pkcs12 -in c:\certificado\Certificado.pfx -clcerts -nokeys -out c:\certificado\Certificado.crt Gerar o arquivo KEY: openssl pkcs12 -in c:\certificado\Certificado.pfx -nocerts -nodes -out c:\certificado\Certificado.key Prontinho ! Todos seus certificados estão na pasta c:\Certificado !

Na função de gerar código de barras, você pode informar diretamente uma String ao invés de enviar um TACBrTipoCodBarra. Abaixo segue a String correspondente ao TACBrTipoCodBarra para cada Linguagem da Etiquetadora: Etiquetadora na Linguagem PPLA: ...\trunk2\Fontes\ACBrSerial\ACBrETQPpla.pas 'A' = barCODE39; 'E' = barCODE128; 'F' = barEAN13; 'G' = barEAN8; 'O' = barCODE93; Etiquetadora na PPLB: ...\trunk2\Fontes\ACBrSerial\ACBrETQEpl2.pas '3' = barCODE39; '1' = barCODE128; 'E30' = barEAN13; 'E80' = barEAN8; 'B9' = barCODE93; Etiquetadora na PPLZ: ...\trunk2\Fontes\ACBrSerial\ACBrETQZplII.pas 'B3' = barCODE39 'C' = barCODE128; 'E' = barEAN13; 'B8' = barEAN8; 'A' = barCODE93; Para realizar os testes utilizei o Exemplo: ...trunk2\Exemplos\ACBrSerial\ACBrETQ\Delphi\ETQTeste.dpr E criei um campo para informar manualmente os dígitos do código de barras, e no evento bEtqCarreirasClick fiz os ajustes: ImprimirTexto(orNormal, 2, 1, 2, 2, 1, 'TESTE barEAN13'); ImprimirTexto(orNormal, 2, 1, 1, 6, 1, 'COD:'+strCod); ImprimirBarras(orNormal, barEAN13, 2, 2, 8, 1, strCod, 10); ImprimirTexto(orNormal, 2, 1, 2, 2, 36, 'TESTE barCODE93'); ImprimirTexto(orNormal, 2, 1, 1, 6, 36, 'COD:'+strCod); ImprimirBarras(orNormal, barCODE93, 2, 2, 8, 36, strCod, 10); ImprimirTexto(orNormal, 2, 1, 2, 2, 72, 'TESTE barCODE128'); ImprimirTexto(orNormal, 2, 1, 1, 6, 72, 'COD:'+strCod); ImprimirBarras(orNormal, barCODE128, 2, 2, 8, 72, strCod, 10); Fui realizando a troca do bloco de 3 linhas com todos os tipos e desta forma consegui chegar nesta conclusão. Nos testes que realizei em etiquetas de 3 colunas, observei que: - Para códigos de barras entre 3 e 9 dígitos é melhor utilizar o barCODE93 - Para códigos de barras com 13 dígitos é melhor utilizar o barEAN13 (Com a ressalva de que é feita uma validação se o o digito verificar está de acordo, podendo mudar os dígitos do código). - Não deve-se usar código de barras com menos de 3 dígitos, nem entre 10 e 12 e nem maior que 13. Espero ter ajudado!

A situação: Está ocorrendo um problema no cliente, você decide usar um dos exemplos disponibilizados pelo ACBr para testar se o problema está no seu software. Então, você copia o executável para a máquina do cliente, inicia-o e, ao tentar emitir um DFe, recebe a mensagem " XML Node não pode ser nulo". Ou então, seu próprio software funciona corretamente em sua máquina, mas ao instalá-lo na máquina de um cliente e tentar emitir um DFe, a mensagem "XMLNode não pode ser nulo" é exibida na tela. A causa e a solução: Os componentes do ACBr fazem uso de algumas DLLs para diversas funções, incluindo a assinatura de XMLs. A configuração que determina qual mecanismo será usado para isso pode ser definida na configuração ACBrDFe.Configuracoes.Geral.SSLXmlSignLib, que pode ter os valores xsXmlSec, xsMsXml, xsMsXmlCapicom¹ e xsLibXml2². ¹ Capicom foi descontinuada e, por isso, não recomendamos o seu uso. Veja mais detalhes AQUI. ² Apesar das outras opções, recomendamos fortemente a utilização do LibXML2. Mais detalhes AQUI. Quando você recebe a mensagem de Xml Node não pode ser nulo, na maioria das vezes, ela está relacionada a esta configuração. Portanto, o primeiro passo a ser tomado é verificar se uma das opções possíveis foi configurada na configuração SSLXmlSignLib (lembrando que xsNone equivale a não ter nada configurado). Se uma das opções foi definida, o próximo passo é verificar se a DLL³ foi distribuída corretamente e se está disponível. Uma forma de certificar-se disso é escolher as DLLs de acordo com a arquitetura com a qual sua aplicação foi compilada, encontrando-as neste link e colocá-las no mesmo diretório da sua aplicação. ³ As dlls referidas são da LibXML2

EXEMPLO DE CONFIGURAÇÃO DO COMPONENTE ACBR BOLETO Santander Site para solicitar credenciais(SandBox/Produção) Santader: https://developer.santander.com.br/ Você não precisa alterar nada nos seus fontes, apenas solicitar credenciais para o ambiente de homologação com o seu especialista Cash. ACBrBoleto.Cedente.CedenteWS.ClientID := client_id informado pelo banco via link acima ACBrBoleto.Cedente.CedenteWS.ClientSecret := client_secret informado pelo banco via link acima ACBrBoleto.Cedente.CedenteWS.KeyUser := Informar o WorkSpace favor utilizar manual do link acima e procurar por workspaces (criado uma única vez) ACBrBoleto.WebServices.Ambiente := Homologação e Produção em funcionamento Caso utilize arquivos PFX, KEY, CRT ou PEM certificado, marque a opção: ACBrBoleto.Configuracoes.WebService.UseCertificateHTTP := true; ACBRBoleto.Configuracoes.WebService.ArquivoCRT := Caminho e nome do arquivo CRT ou PEM ('C:\Certificado.crt';) //Extrair do certificado do cliente ACBRBoleto.Configuracoes.WebService.ArquivoKEY := Caminho e arquivo Key ('C:\Chave.key';) //Extrair do certificado do cliente ACBrBoleto.Configuracoes.WebService.VersaoDF := 'V1'; ACBRBoleto.Configuracoes.WebService.SSLType := LT_TLSv1_2; ACBRBoleto.Configuracoes.WebService.TimeOut := 20000; Atenção para o EndPoint de Testes do Santander API, leia o tópico abaixo: