Painel de líderes

Olá pessoal, É com grande satisfação que informamos que temos um novo PSP disponível para o componente ACBrPIXCD, o ACBrPIXPSPInter! Com esse novo componente, todos agora têm acesso às funcionalidades da API Pix do Banco Inter para a realização de recebimentos através do PIX. Gostaríamos de destacar a importante ajuda de dois usuários que contribuíram com o desenvolvimento desse novo componente: @cristiancarvalhof que nos enviou os fontes através do nosso Discord e @sidnei_alves1 que criou ESSE POST com sua contribuição. Os aplicativos de demonstração(Delphi e Lazarus) já estão atualizados e funcionando com o novo PSP. Até o momento deste post, o PSP Inter não possui ambiente sandbox (homologação), e nós do Projeto ACBr não possuímos credenciais de produção. Portanto, convidamos todos os usuários que possuem essas credenciais a atualizarem seus fontes e ajudarem-nos a testá-lo. Caso encontrem algum problema, dúvida e/ou sugestão, por favor reportem através do fórum ou discord. Agradecemos a Cristian e Sidnei pela contribuição e esperamos que esse novo PSP seja útil para todos os desenvolvedores que utilizam o componente ACBrPIXCD em seus projetos. Caso esteja com dúvidas sobre como conseguir as credenciais desse, ou de outros PSPs, acesse esse post: Abraços!

Agora podemos emitir boletos híbridos (boletos com qrCode para pagamento pix) utilizando CNAB 400. Para isso na inclusão do título, informar a opção OcorrênciaOriginal.Tipo: Titulo.OcorrenciaOriginal.Tipo := toRemessaHibrido; ACBrBoleto.Cedente.PIX.Chave := 'suachavepix'; IMPORTANTE: O tipo de registro 3 (Arquivo de Remessa) é opcional e deve ser utilizado para criação e associação do Boleto ao Pix (QR CODE). O registro deve ser enviado apenas quando o cliente desejar indicar uma chave Pix diferente do CNPJ da conta ou para indicação da location (id da imagem do QR Code) criada previamente. Caso o registro não seja enviado ou o campo “Chave Pix” não seja informado, a Cobrança Pix será gerada com a chave CNPJ da conta enviada na remessa. A location, caso não informada, será gerada automaticamente pelo sistema. Válido somente para a carteira 109 (direta) A conta da cobrança não precisa ser a mesma conta da chave Pix. É checado o CNPJ das duas contas. Se forem o mesmo, o boleto e o Pix serão emitidos. Exemplo: cliente possui cobrança na 2938 99999-9 (não permite criação de chave Pix) e envia a chave Pix na conta 0911 00001-0, ambas as contas possuem o mesmo CNPJ. A emissão do boleto será realizada com sucesso. Agradecemos nosso amigo @antoniojmsjr por participar desta contribuição.

Para melhor identificação do título no retorno, já que dependemos do banco Inter retornar o campo NossoNumero para impressão dos boletos, agora você pode informar no campo SeuNumero para identificar o título no retorno da API.

Boa tarde, Realizando a mesma consulta no cadastro centralizado de contribuinte verifique o ambiente consultado. Percebi pelo XML da nota que a mesma é de homologação e nesse ambiente a consulta do cadastro do cliente não retorna dados. Isso pode acontecer com empresas de cadastro relativamente novos. A sugestão é aguardar para emitir nota para essa empresa em homologação ou entrar em contado diretamente com a secretaria da fazenda do estado para verificar a situação do cadastro.

Agradeço a todos,... Já consegui implementar plenamente a lib POSPRINTER, muito obrigado a todos da Equipe.

Boa tarde Pessoal, Quinta feira (30/03/2023) enviei para o SVN uma atualização dos fontes do ACBrCT-e visando atender a versão 4.00 do CT-e. Já esta tudo no SVN, os novos schemas bem como os fontes atualizados do componente. Por favor atualizem todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes. Lembre-se que agora devemos configurar o componente para a versão 4.00, sendo assim devemos atribuir o valor ve400 a propriedade VersaoDF. Não sei se todas as UF já estão com os seus ambientes de homologação preparados para a versão 4.00, uma vez que nos manuais consta somente 04/2023, conforme postagem anterior. Mas não custa nada tentar. Qualquer problema, favor criar um tópico no fórum para que possamos fazer as devidas correções. Desde já muito obrigado pela colaboração nos testes.

Boa tarde. Foi divulgado no dia 24/03/2023 a NT2023/002 tratando do detalhamento do evento de insucesso na entrega. Resumo da Nota Técnica. Esta Nota Técnica disponibiliza novos eventos de Insucesso da Entrega e seu cancelamento conforme disposto no Ajuste SINIEF 50/2022 de 09 de dezembro de 2022. IMPORTANTE: Os novos eventos serão disponibilizados somente para a versão 4.00 do CTe. Data para Implantação Implantação para Homologação: 05/2023. Implantação para Produção: 07/2023. Evento de Insucesso na Entrega do CTe. Evento EXCLUSIVO da Versão 4.00 do CTe Função: Evento para indicar o insucesso na entrega da carga pelo transportador. Autor do Evento: O autor do evento é o emissor do CTe. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CTe. Modelo: CT-e de Transporte de Cargas (modelo 57) Código do Tipo de Evento: 110190 (Este evento exige CT-e autorizado). Schema XML: evIECTe_v9.99.xsd Final do processamento Se o evento de Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat = 135. Este evento futuramente será propagado nas notas fiscais eletrônicas relacionadas de forma automática. Evento de Cancelamento do Insucesso na Entrega do CTe. Evento EXCLUSIVO da Versão 4.00 do CTe Função: Evento para indicar o cancelamento de um evento de insucesso da entrega da carga pelo transportador nas ocasiões em que ocorrer erro na geração do evento. Autor do Evento: O autor do evento é o emissor do CT-e. A mensagem XML do evento será assinada com o certificado digital que tenha o CNPJ base do Emissor do CT-e. Modelo: CT-e de Transporte de Cargas (modelo 57) Código do Tipo de Evento: 110181 (Este evento exige CT-e autorizado) Schema XML: evCancIECTe_v9.99.xsd Final do Processamento Se o evento de Cancelamento do Insucesso de entrega do CT-e for homologado o status de retorno deverá ser cStat=135. Este evento futuramente será propagado nas notas fiscais eletrônicas informadas no evento Insucesso de Entrega cancelado. Alterações no ACBr. Visto que se trata da criação de um novo evento, será necessário realizar a implementação do mesmo nos fontes, disponibilizando tais alterações dentro do prazo estipulado pela NT. Consequentemente, nova versão do ACBrMonitorPLUS e da Lib deverão ser geradas. Essa e outras Notas Técnicas disponíveis AQUI. Você pode ler esta Nota Técnica na íntegra AQUI.

Boa tarde. Por volta das 12:30 do dia 05/04/2023 membros da nossa comunidade do Discord começaram a relatar no canal #sefaz erro ao Inutlizar NFe na Sefaz MT. A ocorrência comum para todos era receber a rejeição 999 - Erro não catalogado. Em geral, esse tipo de rejeição é um falha não prevista nas validações da Sefaz, e quando é recebida, o curso de ação a ser tomado é entrar em contato com a Sefaz. O membro de nossa comunidade @erlamcastanho compartilhou essa resposta que conseguiu ao abrir um chamado junto a Sefaz evidenciando que eles de fato estão com problema:

Saiu alguma atualização da NT onde informe claramente que NINGUÉM MAIS PODERÁ USAR MAQUININHAS POS, e que todos terão obrigatoriamente implementar TEF em suas aplicações ? e até quando ? Pergunto isso, pois o próprio auditor da Receita, deixa bem claro em suas respostas o contrário disso !

2.11. PSP Banco Inter (Agradecimentos ao usuário @cristiancarvalhof pela descrição do passo-a-passo e imagens cedidas) Ambiente de Homologação - Até o momento desse post o PSP Inter não possui ambiente Sandbox(Homologação). Ambiente de Produção - Para utilização do componente em ambiente de Produção, entre no portal Inter Empresas no menu "Conta Digital" e selecione a opção: "Aplicações": - Crie uma nova aplicação informando os dados solicitados: - Selecione "API Pix" para o escopo da sua aplicação e libere as permissões: - Na aba "Novo" será possível baixar a Chave e Certificado. ATENÇÃO: Esse procedimento pode ser feito apenas UMA vez. Armazene os arquivos em um local seguro. - Na aba "Ativo" você conseguirá ter acesso às demais informações da aplicação (Client ID e Client Secret): - Após esse procedimento, você já terá todas as informações necessárias para configurar o componente, ou então nossa aplicação demo. Como mostram respectivamente as imagens: ACBrPSPInter1.ChavePIX := ''; ACBrPSPInter1.ClientID := ''; ACBrPSPInter1.ClientSecret := ''; ACBrPSPInter1.ArquivoChavePrivada := ''; ACBrPSPInter1.ArquivoCertificado := '';

Informações Extraoficiais sobre os pontos ainda Nebulosos Como muitos vem acompanhando, as questões envolvendo PIX externo ao TEF, uso de POS, operações de pagamento com meios eletrônicos relacionas a pagamento de compras feitas com parcelamento em carne, tem gerado muitas interrogações dentro das SHs. Estive hoje em contato com a AFRAC e até o momento temos as seguintes informações em caráter extraoficial Ainda não há definição de como deve ser informado o PIX feito externo ao TEF, por isso o desencontro de informações vindas pelo Fale Conosco O uso de POS como recebimento das vendas, não está autorizado já que não é possível a integração que não seja inserção manual dos dados Diante deste cenário de pontos a esclarecer, a fiscalização será orientativa Existe a possibilidade que a obrigatoriedade prevista para 01/07 seja postergada. Ainda no mês de abril deve acontecer uma reunião entre o Fisco do RS e os associados da AFRAC, onde o fisco deve voltar a falar sobre as dúvidas que tem recebido. Sendo assim, convidamos a comunidade a continuar a enviar suas dúvidas no tópico a seguir.

Boa tarde pessoal, Estive em contato hj com a AFRAC e as questões envolvendo PIX, POS sem integração com a aplicação ainda estão nebulosos, e diante deste cenário ainda em abril o haverá uma reunião entre o Fisco e os associados da AFRAC para mitigar estes pontos. O FISCO do RS esta ciente que neste momento a implementação das informações do PIX não esta viabilizada, exceto quando passa pelo TEF, mas a questão do uso de POS para o processo de vendas, foi informado que não é permitido. Continuem enviado suas dúvida neste tópico para que possamos direcionar a AFRAC.

Olá, estou implementando o envio de NFCe numa API em C#, eu havia deixado configurado o retorno em frmJson. Notei que após fazer o envio da nota, o objeto de retorno do tipo EnvioRetornoResposta não estava sendo populado corretamente. Debuguei e notei que no EnvioRetornoResposta.LerResposta ele não está tratando paro o tipo json. Percebi porque no demo do PDV há um tratamento após o envio e no meu caso não estava sendo possível porque a prop não estava preenchida corretamente; if (envioRet.Envio.CStat != 100) return ret; Eu uso o ACBR em [memory], configurei para o fmtINI e deu tudo certo, acredito que funcione normalmente, apenas estou relatando essa inconsistência.

Boa tarde, Abrimos o registro na TK-3817 para verificarmos a ocorrência informada. Obrigado pela contribuição!

Criada a TK-3816 para analise da equipe responsável.

Boa tarde, Configure o componente para salvar os arquivos soap (Configuracoes.Webservices.Salvar := True). Faça um novo teste e anexe os XML (soap) gerados para que possamos analisar.

Boa tarde Helius, Já esta no SVN.

Obrigado pelas informações, vou verificar com o cliente.

Realmente, está acontecendo no Lazarus também. Não consegui um tempo pra verificar o que ficou pra trás. Assim que der vamos verificar não só esse mas alguns outros componentes que estão na mesma situação.

@antoniojmsjr Foi enviao ao SNV, se puder fazer o update e reinstalar o ACBr. Quando ler o arquivo de retorno, ele ja alimenta os campos emv automaticamente e basta imprimir boleto pix Obrigado

Olá pessoal, O novo PSP Inter foi implementado com alguns ajustes e liberado. Segue post informando a notícia: Agradecemos muito pela contribuição @sidnei_alves1!

Ola Diego, foi adicionado esta propriedade, pois a programação atual estava passando 29 espaços em branco. não conhecendo a realidade das demais software house, criei a propriedade para ficar "mais coerente" a solução.

Boa tarde Natanael, Já esta no SVN.

Neto, Na verdade o provedor esta retornando apenas uma mensagem e como o componente não encontra os caracteres normalmente encontrados em um XML ele acaba salvando com a extensão JSON. Pela mensagem retornada da entender que o prestador esta sem permissão para emitir as notas.

Boa tarde Rodrigo! Referente a BA, eu estava informando os dados do destinatário, SEFAZ me orientou a não informar. Testei em produção, pois, em homologação não estava funcionando na data. Veja se o XML em anexo te auxilia no preenchimento. É o XML de retorno/final, mas constam ali os dados de envio... GNRE-BA.xml

Boa tarde Willian, Como o assunto do tópico foi resolvido, vamos fecha-lo. Preencha o ResponsavelRetencao com rtNenhum que a tag não será gerada no XML. Caso restem dúvidas, favor abrir um novo tópico a respeito. Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

1-ger-nfse.xml 1-ger-nfse-soap.xml 1-lista-nfse-ger.xml 1-lista-nfse-ger-soap.xml

Bom dia, Você esta com todos os fontes de todas as pastas atualizados? O ACBr foi reinstalado? Não tem nenhum fonte do ACBr com uma bolinha vermelha em seu ícone? Se sim, delete, atualize e reinstale novamente.

Bom dia Paulo, Notei que apesar de ter no inicio do XML o encoding UTF-8 o arquivo em si esta no formato ANSI. Por favor entre em contato com o provedor e expõe essa questão. O Provedor tem que gerar o XML em UTF-8 e incluir no seu inicio o encoding.

No Ubuntu é p funcionar com libssl1.1_1.1.1f-1ubuntu2_amd64 veja este vídeo

Boa noite, Tentando abrir a url no navegador também não abre. Se o problema persistir até amanhã, entrem em contato com o provedor, pois o problema é lá ou houve mudança na url.

Bom dia Natanael, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3811

Boa tarde. Como muitos sabem, a falta de padronização é uma questão que assola a Nota Fiscal de Serviço Eletrônica. Um exemplo disso é o provedor ISSGoiania que é utilizado pela prefeitura de Goiania/GO. Conforme explicado na documentação do provedor disponível aqui: Ou seja, a tag CodigoMunicipio no XML da NFSe para esse provedor vem com um código próprio. No que diz respeito ao envio. Para aqueles que utilizam o ACBrNFSeX (Componente, Lib, Monitor), é importante observar que a Prefeitura de Goiânia espera que a aplicação já informe esse código no campo CodigoMunicipio para sua utilização adequada. Portanto é importante se atentar a esta informação no momento de realizar o preenchimento para emissão da nota. No que diz respeito a leitura do retorno. Como o componente ACBrNFSeX espera receber na tag CodigoMunicipio um código IBGE, a função de conversão que busca o nome da cidade através do código, falha e por isso a informação do município fica em branco na impressão. Para resolver essa questão, foi criada na unit ISSGoiania.LerXML uma função que usa o arquivo disponibilizado pelo provedor para buscar a informação da cidade. (Disponibilizada na Rev-28957) Portanto, basta adicionar o arquivo CidadesISSGoiania.txt(o nome do arquivo deve ser este) dentro da pasta do seu executável para que a busca pelo nome da cidade passe a usar o arquivo e não fique mais em branco no impresso.

Um pouco mais sobre o cStat:105 e mensagem Lote em Processamento. Conferindo no Manual de Orientação do Contribuinte na versão 7.00 disponível para leitura aqui podemos observar que o modelo operacional da NF-e pode ser dividido em serviço síncrono e assíncrono. Para este tópico, vamos focar modelo assíncrono, que de maneira resumida pode ser definido nos seguintes passos: Enviamos a solicitação do serviço. Recebemos como resposta um Número de Recibo confirmando que a solicitação foi recebida pela Sefaz. Consultamos o Número do Recibo para receber o resultado do processamento. Fonte: Manual de Orientação do Contribuinte - Visão Geral, versão 7.00 A mensagem Lote em Processamento pode ser um possível resultado a ser recebido ao consultar o Nº do recibo. O que fazer quando o recebo? No MOC consta a seguinte orientação: Caso opte por permitir que o componente ACBrNFe automatize a consulta as propriedades a serem consideradas são: Aguardar: o tempo que o componente aguarda antes de fazer a primeira tentativa de consulta.(se não definido, por padrão 1 segundo). Tentativas: a quantidade de vezes que o componente vai tentar fazer a consulta.(por padrão 5 tentativas). Intervalo: o tempo que o componente aguarda entre as tentativas de consulta.(se não definido, por padrão 1 segundo). Via código essas propriedades podem ser definidas assim: ACBrNFe.Configuracoes.WebServices.AguardarConsultaRet := 15000; //Valor definido em milissegundos. ACBrNFe.Configuracoes.WebServices.Tentativas := 5; ACBrNFe.Configuracoes.WebServices.IntervaloTentativas := 5000; // Valor definido em milissegundos.

2.10. Fintech PIXPDV IMPORTANTE - Leia atentamente os Termos de Uso disponíveis em: https://pixpdv.com.br/Termos_de_Uso_da_Plataforma_JNP_Software.pdf https://pixpdv.com.br/Politica_de_Privacidade_JNP_Software.pdf Ambiente de Homologação - As credenciais para utilização desse PSP em ambiente de homologação são: CNPJ: 00641418000188 Client ID: tk-ezI0OTgwMzRDLUE1MzctNDM3QS1CQTk0LUZFODlFMEE0MzIyNn0 Client Secret: sk-e0JBNTFGRTY0LTczMkYtNDYxNC1CQ0Q1LUI0OTVDODgxOTUwRX0 Ambiente de Produção - Para a utilização desse PSP serão necessárias as credenciais: Token e Secret Key; - A liberação das credenciais é feita diretamente com @José Nilton Pace através do número: (16)99972-5688 (Telefone e Whatsapp). Conheça mais sobre o PIXPDV em: https://pixpdv.com.br