Painel de líderes

Bom dia! Muito obrigado pela contribuição! Fizemos testes com a mesma usando os botões Criar e Enviar e o Carregar XML e Enviar do programa exemplo, tanto para as versões 3.0 quanto 4.0 e em ambos os casos, não houve o problema relatado. A mesma foi enviada ao SVN na Rev-29927. Por favor, queiram atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Boa tarde, Algum desenvolvedor Delphi disponível para colocar o ACBrPixCD no ACBRLIB mediante a pagamento, para usarmos em sistemas em outras linguagens, usar como DLL ? Nota: Não queremos exclusividade, queremos inclusive que isso seja compartilhado na comunidade.

Boa tarde a todos, A um tempo ocorreu problema semelhante também com Certificado A3 na emissão da NF-e na SEFAZ-SP. O problema era na SEFAZ. Não sai mais barato você comprar um certificado A1 para o seu cliente do que ter todo esse stress? Você acaba mostrando para ele a economia burra que ele fez comprando o A3.

Obrigado por contribuir, @Nícolas Dörr. Entendo que então devemos informar esses campos pertencentes ao Grupo Z. Informações Adicionais da NF-e, concordam? A tag ObsCont, que é de uso livre do contribuinte, possui ocorrência 0-10 e pelo que olhei por cima, o componente hoje está limitado a somente 1 ocorrência. Talvez seja necessário o ajuste no componente do ACBr, para que caso alguém pague com mais de 1 pix, consigamos enviar a informação referente aos 2 pagamentos efetuados.

Bom dia! Dia 28/06/2023, por volta das 10:34, começamos a receber relatos no canal #sefaz em nossa comunidade do Discord. Os relatos informavam que ao tentar consumir os serviços de NFe receberam mensagens como: Conferindo no DownDetector, é possível observar que por volta das 10:00 os relatos de problema aumentaram exponencialmente: Não há contingência ativada no Portal da NFe até a publicação desta mensagem.

Está atualizado aqui sim @Márcio B. , possivelmente você não teve o mesmo problema que nós por não utilizar o mesmo recurso de ler o XML já gerado para depois enviar. A questão eh que o tratamento de leitura da tag x geração esta incompatível. Ao ler o XML já gerado o & é convertido para &. Porém ao gerar novamente o parâmetro ParseTextXML estava false. Para seguir o mesmo padrão de demais tags string fiz as seguintes alterações: Em ACBrCTe > GetURLQRCode, preencher a tag com & novamente em vez de & (como já estava antes) Em pcteCTeW passar o parâmetro de ParseTextXML para True, que assim irá realizar a conversão correta dos caracteres. Esta alteração segue os mesmos padrões do comportamento de outros campos string como Nome, Endereço, etc. @Juliano Otaviano Barreto, teste novamente com essa alteração sem zerar o qrCodCTe. pcteCTeW.pas ACBrCTe.pas

Obrigado Renato, segundo a conclusão do post, nenhuma mudança pelo que entendi, continua enfiando pro GINFES, não entendi o motivo do erro então. vou continuar tentando e qualquer coisa retorno aqui.

Recentemente tivemos ocorrências em SP relacionadas a certificados tbm e era um problema na própria SEFAZ. Como você está informando uma situação bem específica acho que vale a pena fazer um contato com o fale-conosco deles relatando o problema. Até o momento não tivemos mais relatos nesse sentido na comunidade...

Pessoal, se alguém estiver com problemas para o CTe 4.0 em MG, eles estão trabalhando nisso ainda, apenas avisando:

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Boa tarde! Para aqueles que estão tendo problemas no envio de CT-e para Sefaz de São Paulo, enviando na versão 3.0 ou 4.0 recebendo o erro: Enviando em contingência SVC-RS na versão 4.0 e recebendo: Por favor, atualizem seus fontes, reinstalem o ACBr e façam novos testes. Para os usuários do Monitor ou da Lib, novas versões já foram compiladas.

você pode testar livremente, usando a DLL Demo... ou até mesmo baixar os fontes da DLL e compilar a sua própria versão... https://www.projetoacbr.com.br/forum/files/category/63-acbrlib-demo/

No ACBr está permitindo mais de uma ocorrência @WINDEL. Eu fiz a implementação e é só usar conforme abaixo: with InfAdic.obsCont.New do begin xCampo := 'txidPIX'; xTexto := 'ValortxidPIX' end; Desta maneira você consegue incluir quantas vezes quiser. Eu ainda inclui uma outra validação caso o pagamento seja feito com mais de 10 Pix (Acho improvável mas pode acontecer) para evitar erro na hora de validar a NFC-e.

Bom dia pessoal, A NT que abriu a possibilidade da NFCe com 5949 foi devido a um pedido da SEFAZ-RS, porém eles ainda não fizeram os ajustes ou regulamentaram internamente seu uso, por conta disso a resposta obtida no Fale Conosco. At.

Boa noite, Antes de mais nada, se o emissor não for MEI, selecione no LayoutNFSe a opção lnfsProvedor. Aumente também o timeout para 30k pois 2k é muito pouco e poderá interromper alguma conexão indevidamente. Com relação ao erro, é um problema recorrente com certificados A3. Veja o tópico a seguir com mais informações.

Provavelmente ainda não tem as URLs da versão 4, para MG, ou você tem um arquivo ACBrCTeServicos.ini desatualizado, na mesma pasta do .EXE

@LeonardoRocha boa tarde ! Fiz um teste com o Programa Exemplo em Java utilizando Linux Mint, usando a ultima versão do ACBrLibNFSe=1.0.0.30 Meu ACBrLib.ini ACBrLib.ini Veja os retornos em JSON: Log ACBrLib ACBrLibNFSe-20230627.log Soap 1-lista-nfse-sinc-soap.xml E validação do JSON: jsononline-net.json Quanto ao envio, eu não consigo fazer teste, pois não tenho certificado com permissão para envio.. Mas o retorno em JSON parece correto.. Tente uma instalação zerada com esta ultima versão do ACBrLib, veja se resolve.

Respondido no discord. https://discord.com/channels/798697718800318484/800724885835743252/1123268916563689572 Pode usar o mesmo, provavelmente a filial nunca utilizou o serviço ou ficou mais de 60 dias sem utilizar, interrompendo a distribuição.

Valeu Juliomar, Muito Obrigado.

Para cumprimento da Lei 12.741/12, não esqueça de atualizar sua tabela de alíquotas - Versão 23.1.G Sua vigência é de 20/06/2023 até 31/07/2023 Integre o seu sistema à API De Olho no Imposto e não se preocupe mais com as atualizações da tabela. Fonte : https://deolhonoimposto.ibpt.org.br/

Bom dia Mauricy, Segundo a versão 3.00a do Manual do CT-e que contem o layout do XML não esta previsto informar o CPF do emitente, somente o CNPJ. A unit do componente que gera o XML segue o layout desse manual, portanto não vai ser possível emitir um CT-e cujo emitente não possua um CNPJ. Mas existe uma Nota Técnica ( NT 2020/001 versão 1.03 ) que trata sobre a NFF ( Nota Fiscal Fácil ). Nessa NT ( página 6 ) contem uma alteração no layout de tal forma que seja possível informar o CPF em vez de CNPJ, neste caso teríamos a tag <CPF> em vez da <CNPJ> no XML dentro do grupo <emit> ( emitente ). Essa alteração no componente não foi realizada e o motivo é: Emitente do CT-e O emitente passa a poder ser identificado pelo CPF do transportador autônomo de cargas (TAC), desde que atendidas as regras da NFF. A IE do emitente passa a ser uma tag opcional, que não será informada somente no caso da NFF. Primeiro: Para o emitente ser identificado pelo CPF tem que atender as regras da NFF. Segundo: Até onde sei a SEFAZ não liberou os aplicativos de terceiros emitirem documentos segundo as regras da NFF. Esta previsto o desenvolvimento pela SEFAZ e com distribuição gratuita de um APP para celular chamado NFF, com este aplicativo o contribuinte vai poder emitir CT-e, NF-e e MDF-e de forma simplificada. Resumindo: Hoje para emitir um CT-e usando o componente ACBrCTe: O emitente do CT-e tem que ser uma pessoa jurídica, ou seja, temos que informar o CNPJ dela no grupo <emit>. O dia que a SEFAZ liberar a NFF para que outros desenvolvedores possam escrever seus APP, ai sim vamos fazer as devidas alterações no componente para atender esses desenvolvedores.