Painel de líderes

var Titulo: TACBrTitulo; begin Titulo := ACBrBoleto1.CriarTituloNaLista; [...] Titulo.ListaDadosNFe.Add.ChaveNFe := <chave da nfe>;

Obrigado a todos pelo feedback! Desde já quero parabenizar a todos os colaboradores do ACBrPixCD, está funcionando muito bem. Estamos implementando uma solução bem legal, porém não é desktop! fizemos a implementação para transacionar o pix em ambiente linux, daí surgiu a necessidade de trabalhar com o Webhook para melhorarmos a performance, até enviei aqui para ver se havia algo, mas já estamos implementando fora do componente mesmo. Agradeço a atenção de sempre.

Tem muita opção e gente sobrando em Delphi, acredite, tem que ofertar home office e salário compátivel. Se for mudar de linguagem você tem por exemplo c# , que tem compatibilidade com ACBr, então ai você vai subir a régua de salário, pois o dev, c# tem uma expectativa de salário quase uns 40% a mais que o dev Delphi, se for para Node Js por exemplo ai sobe mais ainda a régua.... então acho que a sugestão do colega que postou antes seja muito interessante você observar.

Olá pessoal, Foi publicado a versão 1.30 da NT 2021/003 que trata das Validações do GTIN. "A versão 1.30 da NT basicamente amplia o grupo de NCM (grupo de Mercadorias) que verificam a existência do GTIN no CCG-Cadastro Centralizado de GTIN, dando continuidade a ampliação da obrigatoriedade de uso para indústrias donas de marcas." Essa NT se refere ao Grupo III Observação: Como se trata de validação de novos NCM por parte da SEFAZ não se faz necessário nenhuma alteração no componente ou Lib ou Monitor e nem na sua aplicação. Lembrando que os NCM listados no grupo III tem que estar com os GTIN corretos no cadastro de itens de produtos nos seus clientes, caso contrario a nota vai ser rejeitada.

Layout C240 Sicredi.zip segue o layout q baixei direto da plataforma de homologação do sicredi

Encontrei a solucção, Abra as configurações do seu navegador padrão, acesse opçoes de internet /privacidade/avançado/bloquear cookies(interno e de terceiros). Devido aos cookies ele mantem a sessão com login e senha do provedor. Por isso ocorre a rejeição. Ele mantem as credenciais do primeiro envio salvo. bloqueei os cookies e deu certo.

Boa tarde, Foi encontrada alguma solução para esta situação? Estou com o mesmo problema, e da mesma forma que o Alisson, refaço toda a configuração do componente.

Boa tarde! Criada a #TK-4831 para análise do caso e parecer do consultor responsável.

No PIX da Matera existe a possibilidade de você enviar o endereço do callback. Apenas isso. Nos outros PSP e no ACBrPIXCD padrão BACEN que eu me lembre não tem essa informação. Como comentado na estrutura do componente e modelo de funcionamento desktop não faz muito sentido. A princípio a implementação seria separada do componente mesmo.

Humm.. acho que realmente não mapeamos todos os EndPoints de Webhook.. (Justamente por ser pouco prático em aplicações Desktop) @EliasCesar ou @Alexandre de Paula, podem confirmar ?

Bom dia! Atualizado e as urls estão estar corretas! Qualquer problema eu reporto. Muito Obrigado.

Então a sugestão é que você tenha um controle paralelo da sua modificação dos fontes. Caso tenha a documentação do banco e algo desenvolvido anexe os arquivos no tópico e podemos colocar na nossa fila de avaliação. Obrigado

Obrigado pelo retorno @jaques.rocha

Bom dia @MGS Sistema, obrigado pelo retorno, por fim tive de fazer o mesmo, o cliente comprou um A1 para conseguir emitir cupons.

Boa noite, O componente foi atualizado hoje. Atualize novamente e veja se não tem nenhuma alteração local, pois tem que funcionar e confirme se não tem uma cópia do ACBrNFSeXServicos.ini na pasta do seu exe. Se você ainda utiliza a versão antiga do componente, ela não recebe mais atualizações a mais de 2 anos, migre para o ACBrNFSeX.

Boa tarde a todos, quando for postado posso ajudar nos testes, vou ter de implementar essa funcionalidade também. No que eu puder contribuir estou disponível.

Olha Home office com salário compatível com conhecimento e mercado tem muita gente procurando vaga então tem que ver se tu está fora de um desses dois.

Seria interessante recnosiderar para buscar algo além de tudo que já vimos de relatos no fórum e discord Isso, OpenSSL somente A1 O problema não está nas configurações do componente. Temos relatos do mesmo cenário, aplicação, configurações, certificado, emitente, tudo igual: * Funcionando a NFe e não funcionando a NFCe * Funcionando eSocial e não funcionando o Reinf É o melhor que tem a fazer, pois não terá mais problemas com certificado. Vamos aguardar, quem sabe temos uma luz

Boa tarde @xim.logan, Uma dica, campos referente a percentuais costumam começar com a letra "p" e os que se referem a valores começam com a letra "v".

Bom Dia Willian, você conseguiu avançar com essa demanda ? Também me encontro com essa dúvida.

Deixando a solução para quem precisar, como no Android 12 teve mudanças nas permissões, foi necessário marcar essas opções no projeto.

Boa noite Rosemir, Já tentou desta forma? sStat := IntToStr(ACBrCTe.WebServices.Enviar.cStat);

Só para dar um feedback e compartilhar com quem interessar... Usando o CTe 4.00 o retorno trás a chave de acesso da nf-e. No entanto, pelo menos em SP, o retorno trás sempre a chave da última nf-e referenciada, mesmo estando válida, e não a chave da primeira nf-e com situação inválida, que seria o correto conforme descreve o MOC. Não sei se mais alguem percebeu isso. Enviei mensagem para o sefaz-sp explicando o caso estou aguardando resposta.

Olá pessoal! Entre os dias 04 e 05 tivemos relatos em nossa comunidade do Discord de problemas para emitir CT-e para a Sefaz São Paulo, com o número de protocolo de CT-es autorizados sendo devolvido com tamanho 16 ao invés de 15. Considerando os últimos relatos, tudo indica que a situação foi normalizada e a resposta da Sefaz está de acordo com a documentação. Segue abaixo uma breve transcrição do ocorrido. Se você ainda está tendo problemas, é importante que deixe a Sefaz ciente através de um Fale Conosco. Os primeiros relatos começaram no dia 04/12/2023, por volta das 08h52 e informavam que a emissão era feita com sucesso, mas a Sefaz estava devolvendo um número de protocolo com 16 dígitos ao invés de 15 que é o tamanho estipulado, causando assim problemas. Por volta das 15h49, membros começaram então a reportar estarem recebendo no retorno: Durante este mesmo período, alguns membros mencionaram ter conseguido emitir CT-e enviando em contingência e nesses casos o número do protocolo devolvido era composto de 15 caracteres. No dia 05/12/2023, por volta das 08h46, participantes da comunidade cujos clientes emitiram CT-es em modo normal e receberam um número de protocolo com 16 dígitos estavam tendo dificuldades para realizar o cancelamento devido ao tamanho atípico. Outro detalhe que foi notado é o fato desses CT-es de 16 dígitos estarem retornando 01/01/0001 00:00 na informação da data/hora de aprovação ao realizar um consulta. Por volta das 14h00, tivemos relatos de sucesso ao cancelar os CT-es removendo o primeiro número do protocolo de 16 posições normatizando para o tamanho esperado de 15. A conclusão que se chegou por parte dos integrantes da comunidade é a de que o contador do campo do protocolo estourou passando então para 16 caracteres. As 15h02, um membro relatou que ao consultar as chaves dos CT-es que devolveram protocolo com 16 dígitos, a informação havia sido corrigida e o campo estava agora com caracteres. Não foi encontrado comunicado oficial a respeito do ocorrido no Portal Estadual durante o período.