Painel de líderes

Acredito que por se tratar de um usuário que já emitia com a versão em Delphi, que agora passou pra C#, ele já tenha essa permissão, vou precisar analisar melhor aqui pra tentar achar o que pode ser, são bem poucos clientes conosco ainda que utilizam a nota conjugada. Vou verificar aqui, talvez possa ser algum processo que estamos fazendo de forma incorreta, notei antes que algumas TAG's estão gerando diferente, mas não consegui dar uma atenção ainda. Perfeito, obrigado pela informação, não tinha ciência disso, vou procurar me informar melhor sobre isso. Muito obrigado pelo apoio @Diego Foliene e @Renato Rubinho, assim que tiver mais informações posto aqui

Complementando o que o Diego explicou bem, que eu saiba somente o DF utilizava a NFe conjugada e eles pararam de utilizar em janeiro deste ano quando passaram a utilizar a NFSe "municipal"

Boa tarde! Opinando um pouco no âmbito fiscal. A NF-e que contenha um serviço é também conhecida como nota conjugada. Até onde sei, com o advento da nota de serviço, a NF-e conjugada já não é mais tão utilizada e antes de partir para ela é preciso confirmar se o município permite. Fonte: Portal da NF-e Então talvez bater cabeça com isso não seja a melhor solução. Agora sobre o problema em si. Se buscarmos no MOC temos o seguinte detalhamento para a rejeição: Logo, verifique no XML gerado se o mesmo respeita esta regra tendo finfe diferente de 3 e possuindo a tag ISSQN no item.

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

Já é possível... https://acbr.sourceforge.io/ACBrMonitor/PassoaPassoNFSe.html

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.

Hercules esta na com2 monitorando o aplicativo teste de balança tbm; Feche todos estes aplicativos. Na Balanca Urano deixe ela em modo "empacotadora", assim sempre que ela receber o peso, vai comunicar. No aplicativo balanca teste, antes de ativar marque a opção de "monitorar balança" Realize os testes por favor

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.

Para consultar novamente pelo ultNSU tem que esperar 1h, independente da manifestação, bem porque em tese o XML completo não necessariamente é distribuído imediatamente após a manifestação.

Caro Diego, obrigado, agora realmente retornou alguma mensagem q possamos entender <?xml version="1.0" encoding="UTF-8"?><retorno><mensagem><codigo>00132 - Usuário ou Senha inválidos!</codigo><codigo>00131 - Não foi possível validar o usuário logado!</codigo></mensagem><numero_nfse></numero_nfse><serie_nfse></serie_nfse><data_nfse></data_nfse><hora_nfse></hora_nfse><arquivo_gerador_nfse></arquivo_gerador_nfse><nome_arquivo_gerado_eletron></nome_arquivo_gerado_eletron><link_nfse></link_nfse><cod_verificador_autenticidade></cod_verificador_autenticidade></retorno> tentei enviar o mesmo "usuario" e senha q utilizamos para acessar o portal deles, mas retornou a mensagem acima, enviei um email a eles perguntando se é a mesma ou nao, eles retornando te informo aqui, muito obrigado

NFe_Imprimir(\\caixa\elgini9,1,,TrueFalseFalseFalse,FalseFalseFalse,FalseFalse,False) << precisa de virgula p separar os parametros NFE_Imprimir([cImpressora], [nNumCopias], [cProtocolo], [bMostrarPreview], [cMarcaDagua], [bViaConsumidor], [bSimplificado]); https://acbr.sourceforge.io/ACBrLib/NFE_Imprimir.html

Boa tarde, Este LOG está assim mesmo ou você editou? Os parametros booleanos estão estranhos.

ok @Daniel InfoCotidiano Com esta Unit deu certo, aguardo nova versão. Obrigado.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Atualizado versão, problema resolvido, agradeço a atenção.

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! Por manifestação do Destinatário, você diz enviar o evento de Ciência, Confirmação ou Desconhecimento da Operação depois de conseguir o resumo das NF-es pela DistribuiçãoDFe, correto? Se sim, então pode sim, enviar o evento logo em seguida. O que você não pode é ficar abusando do método de DistribuicaoDFe para não cair em consumo indevido. Na NT2014/002 tem algumas orientações a respeito. Por ser membro PRO, você também tem acesso ao curso Implementando o Serviço DistribuiçãoDFe que explica sobre.

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

Essa mensagem indica que a Unit ACBrNFeDANFEFR que você está utilizando foi compilada com outra versão do Fast Report. Tem algumas informação no StackOverflow sobre o assunto. Mesmo que você tenha instalado essa mesma versão nos dois delphis, se os compiladores usados são diferentes, o erro vai acontecer. Veja na sua própria imagem: Os arquivos são diferentes mesmo comparando para mesma plataforma (veja os tamanhos). Então se o Delphi se confundir (talvez pelas configurações do LibPath, search path, etc...), vai gerar esse erro. Você precisa garantir que o Delphi vai acessar apenas uma versão de units. Isso é válido tanto para o Fast Report, como o ACBr.

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! E-mail recebido, muito obrigado! Faremos alguns testes e reportamos aqui assim que descobrirmos algo.

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.

Enviado, obrigado!

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.

Boa tarde Rogério, Já esta no SVN.

Boa tarde! Foi gerada uma nova compilação da Lib englobando o ajuste que visa resolver o problema. Por favor, queira atualizar e realizar um novo teste.

Aparentemente há algum outro programa rodando na máquina e capturando a Porta Serial...

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.