Painel de líderes

Olá como todos sabem estamos com uma nova ferramenta para gerar arquivos PDF de documentos fiscais, boletos e demais. https://github.com/Projeto-ACBr-Oficial/FPDF-Pascal O mesmo foi escrito baseado em outro projeto aberto em FPDF PHP e ele agora está presente dentro do Delphi pela ferramenta GetIt https://getitnow.embarcadero.com/ então agora para usar o mesmo basta acessar a ferramenta Getit no seu delphi e baixar

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Não tenho certeza, mas pode ser alguma instabilidade do lado do provedor, tentou contato com o provedor para saber do retorno ?

Membros em nossa comunidade compartilharam este feedback que foi disponibilizado em um dos relatos no DownDetector:

Isso pode variar de um provedor para o outro.. Geralmente o Cancelamento esta implementado, mas não são todos os provedores que utilizam.. Alguns provedores, fazem o cancelamento na hora, através do método, outros criam uma solicitação de cancelamento ou até mesmo alguns provedores requer que o cancelamento seja analisado por um fiscal da prefeitura, então não deixa fazer via webservice. Melhor caminho é entrar em contato com o provedor e verificar qual o caminho para o cancelamento.. Este tópico pode te ajudar também:

Boa tarde, Não deveria ocorrer esse erro uma vez que na unit GeisWeb.Provider a leitura da tag DataLancamento esta da seguinte forma: Data := ObterConteudoTag(ANode.Childrens.FindAnyNs('DataLancamento'), tcDatVcto); O tipo tcDatVcto se utiliza da formatação DD/MM/YYYY para ler a tag (vide unit ACBrXmlBase). Na unit GueisWeb.LerXml a leitura das tags DataEmissao e DataLancamento também é utilizado o tipo tcDatVcto, veja: DataEmissao := ObterConteudo(ANode.Childrens.FindAnyNs('DataEmissao'), tcDatVcto); dhRecebimento := ObterConteudo(ANode.Childrens.FindAnyNs('DataLancamento'), tcDatVcto); Checklist: Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Boa tarde, Está com os fontes atualizados? Neste mesmo ambiente funcionava e parou ou está configurando agora? Teste com o programa de exemplo para descartar algum problema na sua aplicação. Qual versão do Reinf está utilizando? Revise suas configurações de ssl/tls conforme o tópico a seguir.

Boa tarde Gary, Você escreveu que esta apenas enviando e querendo obter uma informação que consta no XML da NFS-e. Ai que esta o seu problema. Todos os provedores que seguem a versão 1 do layout da ABRASF (Betha por exemplo) o serviço que recepciona o XML do RPS no webservice trabalha no modo assíncrono. Sendo assim, ao enviar o que você tem como retorno é o numero do protocolo apenas. Por favor leia o tópico abaixo, ele explica como funciona os provedores.

Boa tarde Fer, Se tratando de MEI, se não for alterado a data, esta previsto para 01/09/2023 a obrigatoriedade. Agora para quem não é MEI, primeiro é preciso saber se a prefeitura aderiu o pacote completo do Projeto da NFS-e Padrão Nacional. Tenha em mente o seguinte: A prefeitura pode não aderir, neste caso continua como esta. A prefeitura pode aderir somente o pacote de compartilhamento, deste caso também continua com esta. A prefeitura pode aderir o pacote completo, neste caso ela vai ter que informar a data quando os prestadores que não são MEI vão passar a emitir as suas notas segundo o Padrão Nacional.

Foi justamente o que pensei Italo. Acredito que apenas com esse material, não seja possível seguir com a implementação do envio automático. Atualmente já temos o envio manual e acredito que seja melhor deixar como está. Mas agradeço o apoio e caso eu consiga descobrir mais informações, compartilho aqui.

adicionei a versão no arquivo ACBrNFSeXServicos.ini para este município e recompilei o pacote, funcionou. obrigado.

@Daniel InfoCotidiano creio que amanhã envio as classes com algumas correções Att,

Bom dia! Para que a alteração no ACBrNFSeXServicos.ini surta efeito, você precisa executar o CompilaRes.bat, reinstalar o ACBr e dar um build all na aplicação. Mais informações sobre isso aqui: Caso já tenha feito isso, seu ACBrNFSeXServicos.ini esteja diferente disso(Configuração atual do SVN): Então verifique se não tem um ACBrNFSeXServicos.ini antigo ou desatualizado na mesma pasta do .EXE e caso positivo exclua.

Maravilha, muito obrigado, irei aguardar.

Bom dia Diego, Já esta no SVN.

Bom dia Antonio. Sim temos o contrato assinado desde o ano passado, mês 06. Devido a algumas implementações grandes aqui na empresa e numero baixo de desenvolvedores não conseguimos dar seguimento naquele momento com o desenvolvimento e a homologação do TEF PayGo. Agora estamos dando prioridade nesta demanda, procurei já em nossos e-mails antigos, porém não há. CNPJ: 33.462.939/0001-27 Já temos desenvolvido pelo componente ACBrTEFD e testado com a CliSitef (Não homologado, foi necessário desenvolver apenas para realizar a homologação do PAF-ECF), mas vamos utilizar ACBRTefAPI com a PayGo, e comercializar esse produto para os nosso clientes.

Bom dia Diogo, Tenta conseguir com a prefeitura o manual com o layout do arquivo que deve ser enviado para o WebService do provedor.

Veja o que falei é que se precisa de SLA , senão poste e aguarde até que alguém tenha disponibilidade de vir responder, e não ficar postando para UP no tópico.

Deu certo pessoal, no fim bastava trocar os layouts para: fpLayoutVersaoArquivo := 107; fpLayoutVersaoLote := 67; Assim o cedente ficaria 7 digitos e tudo funcionaria

Bom dia ! Não é um erro de componente. Observe a reposta acesso negado. Ontem tivemos vários relatos instabilidade na sefaz SP e tbm problema com certificados de algumas certificadoras. Relato sobre problema com Algumas certificadoras:

Bom dia, Esse tópico é bem antigo, se necessário inicie um novo na área de assuntos não relacionados ao componente. obrigado

Olá Danilel, Muito obrigado pela ajuda! Agora devo conseguir gerar e receber o TXT. Pode encerrar este chamado! Abraços, Sergio

Geralmente essa informação você encontra no calendário. No Discord do ACBr teve relatos de problemas em SP, que estava acusando erro 403 quando usando certificados AC DIGITAL.

Foi aberta uma TK para analise do caso - #TK-4057 Vamos atualizando aqui no tópico..

C:\ACBR\Fontes\ACBrDFe\ACBreSocial\PCNeSocialfiz os testes e da erro. O correto e: s := Copy(FXML, Pos('/evt/evtIrrf/', FXML)+13, 12); pcesS5012.pas xml de retorno empresa exemplo homologação 20230612142406-sit.xml ID1033416450000002023061212403307878-S5011.xml ID1033416450000002023061212403307878-S5012.xml ID1033416450000002023061212403307878-S5013.xml

https://stackoverflow.com/questions/23949373/stretching-a-bitmap-in-delphi-using-stretchdraw-method Veja o código no post original deste tópico, eu tive esse problema (enviar o QrCode por WhatsApp) e resolvi dessa forma.

Para Delphi ou Lazarus: https://www.projetoacbr.com.br/fontes Para outras linguagens: https://www.projetoacbr.com.br/forum/files/category/21-acbrmonitorplus-demo/

não tem problema no banco caixa, voce deve ter enviado é as coisas errada, esse banco é nojentinho... igual BB sugiro, ler isso: Na sua pasta do componente: \ACBr2wc\Fontes\ACBrBoleto\Particularidades.pdf Posta como vc colocou os dados no componente.

Estou tentando ajustar isso para o ACBr pois estou utilizando o mesmo em produção já! se tiver novidades posto aqui e aviso o commit

Bom Dia. Para colaborar: Fiz o mesmo processo novamente, coloquei novamente as dll junto do executavel, conferi todos os dados, o email tava em branco, preenchi novamente, gerei, validei no Digicert, enviei ao sicredi e hoje foi aprovado.

Pode ser a tua "edição" do FastReport. Pra usar os .fr3 do ACBr precisa ser no mínimo a edição Standard, com suporte a scripts. A versão que vem junto ao Delphi não terá compatibilidade.

Boa tarde! Está em nosso backlog para ser analisado. Outras demandas de maior urgência impediram que a princípio ela fosse alocada para o sprint desta semana. Vou verificar a possibilidade de inclusão. Qualquer novidade você será notificado neste tópico.

Bom dia pessoal! Conforme foi mencionado acima, o tópico a seguir está bem movimentado com a participação e debate dos membros da comunidade sobre o tema: Foi nele que o membro @famwg, chamou atenção ao fato da Sefaz/RS ter publicado em seu portal um FAQ a respeito do tema: FAQ - Integração entre NFC-e e Meios de Pagamento Eletrônicos

Você já teve dúvida no momento de verificar se a cobrança PIX gerada pela sua aplicação foi realmente paga? Pois é, essa dúvida é mais comum do que imaginamos! A primeira dica é ter a certeza que está armazenando as informações de identificação da cobrança/pagamento/devolução em seu sistema, pois são através desses campos que vc conseguirá utilizar as requisições de consulta dos endpoints. A seguir vamos detalhar qual os campos indispensáveis para cada rotina. Cobrança (/cob): Ao criar uma cobrança é muito importante armazenar o campo txID. Através dele você conseguirá ter acesso a toda "vida" da cobrança e saber exatamente as ações que foram efetuadas(Pagamentos, Devoluções, etc); Pagamento (/pix): Quando o pagamento de uma cobrança é efetuado, é gerado um campo chamado E2E (End to End). Esse campo também deve ser armazenado para que seja possível consultar esse pagamento posteriormente. Devolução (/pix/{e2eid}/devolucao} : Quando uma devolução é solicitada, é necessário informar o campo "ID da Devolução", esse campo é importante, caso seja necessário futuramente efetuar uma consulta a essa devolução. A seguir, vamos realizar testes utilizando nosso demo do componente ACBrPIXCD configurado com o PSP Banco do Brasil em ambiente de Produção: Ao consultar o txID de uma cobrança recém criada, podemos verificar que o status inicial dela é: "ATIVA" Você tem acesso a essas informações através da propriedade: ACBrPixCD1.PSP.epCob.CobCompleta Quando o pagamento dessa cobrança é efetuado, ao consultá-la novamente temos o status "CONCLUIDA": Também podemos perceber que existe um objeto PIX na resposta, que contém um campo chamado "endToEndID". É aqui que encontramos todas as informações referente ao pagamento. Com esse campo E2E podemos também consultar um pagamento específico, como mostra a imagem a seguir: Essas informações são encontradas na propriedade: ACBrPixCD1.PSP.epPix.Pix Ao efetuar uma devolução e consultar novamente a nossa cobrança (utilizando ainda o txID), temos o seguinte cenário: Vemos que a cobrança continua com o status "CONCLUIDA", porém existe uma devolução com status "DEVOLVIDO". Isso quer dizer o que o valor NÃO está na conta do recebedor, ou seja, a cobrança não está paga. Portanto é sempre importante avaliar a lista de pagamentos(Pix) que a cobrança possui e verificar também a lista de Devoluções que cada pagamento possui.

PAPO SOBRE O BACKUP DOS DADOS DO CLIENTE Ola minha sugestão é sobre como implementar uma boa rotina de backup, algo que não lembro se já foi abordado aqui no Acbr, e seria legal se pensassem quem sabe até em criar um componente sobre isso. AcbrBackup, com rotinas do backup do firebird e interação com algum serviço de nuvem. Obrigado.

Resolvido, para SAT ELGIN SMART nao pode ativar a propriedade de identar XML CFeCanc.IdentarXML := False; Coloquei como false resolveu.

Boa noite José, Vamos pela lógica: Se um MDF-e foi encerrado, significa que a mercadoria foi entregue. Sendo assim o transporte foi realizado, portanto não faz sentido e acredito que não seja possível cancelar o CT-e vinculado ao MDF-e. Se a mercadoria foi entregue, significa que a venda foi realizada, portanto não faz sentido e acredito que não seja possível cancelar a NF-e vinculada ao CT-e. Agora se você esta conseguindo cancelar um CT-e vinculado a um MDF-e encerrado, posso concluir que: 1. A SEFAZ ainda não implementou a regra que proibi o cancelamento; 2. Você esta usando o ambiente de homologação que com certeza não possui todas as regras implementadas pela SEFAZ. Respondendo a sua pergunta: Pelo descrito acima é obvio que não é correto.