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.

Ok. Vou atualizar e darei um retorno.

Agora deu certo, muito obrigado

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:

Bom dia, um cliente me informou que a prefeitura de Cambé/PR estará adotando a nova emissão de NFSe em 01/09/2023 para MEIs, acredito que para os demais contribuintes seja feito nos meses subsequentes, porém ainda sem data definida: Criei esse tópico para informar a todos interessados e também para saber o status do componente com relação ao novo padrão. Obrigado

Boa tarde! @jovitomg, para o seu caso, note que a informação que vem dentro da tag ItemListaServico não é conforme o padrão esperado. Para este caso, você pode definir a propriedade TabServicosExt da seção [NFSe] como 1 - Sim e adicionar no diretório da sua aplicação um arquivo TabServicos.txt com a descrição por código. @Microsys Sistemas, estamos analisando a questão do Fast.

Boa tarde Ítalo, Tinha reparado nisto também, relatei isso para eles e estou aguardando um retorno. Primeiro, eles orientaram varias questões sobre o preenchimento do meu xml de envio, foi alguns dias vendo isso, mesmo não sendo bem isso o problema, mas depois de corrigir retornei a falar sobre a questão dos retornos. Inclusive aproveito aqui para deixar aqui em anexo os modelos de exemplo que me passaram, do que deve ser preenchido para o ISSFortaleza, além de um documento que me ajudou a tirar algumas dúvidas também. xml_ISSFortaleza.zip Perguntas Respostas ISS Arquivos Lote RPS - v8.pdf

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde a todos, deu certo com a alteração da forma de enviao para emissão CTe.CriarEnviarCTe("C:\ACBrMonitorPLUS\119106.txt", 1, , , , , , 0) Muito Obrigado, Carlos

Boa tarde! Após o ajuste funcionou perfeitamente. Obrigado!

Boa tarde Leandro, Não vejo outra alternativa entrar em contato com a prefeitura e expor o problema. Olhe como esta a geração do retorno: Segundo o bloco de notas esta no formato ANSI, conforme dito da postagem anterior, mesmo com o encoding no inicio do XML. Outro absurdo, ao gerar o XML de retorno estão usando a sequencia escape: "&lt;" em vez do caractere "<" para indicar o inicio de uma tag, mas isso o componente consegue tratar. O grande erro mesmo é gerar o XML no formato ANSI e colocar a declaração de encoding sendo UTF-8.

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.

Boa tarde, Lembre-se que você tem um prazo de 168 horas a contar da Data/Hora de autorização do CT-e para realizar o seu cancelamento. Se o envio do CT-e em modo de contingência foi para a SVC, ou seja, SEFAZ-Virtual de Contingência, temos o seguinte com relação ao cancelamento: Os pedidos de cancelamento na modalidade SVC somente poderão afetar documentos autorizados em contingência pela correspondente SVC-[SP/RS]. Se o CT-e foi enviado para o SVC, configure o componente para este modo de envio e envie o evento de cancelamento. É para funcionar.

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/

Sobre a questão da informação do prefixo não seguir um padrão, isso porque cada município informa de uma maneira diferente, e nós só replicamos os dados em nossa tabela. Por isso comentei que cada município tem um formato, pois são informações preenchidas de forma manual e não automatizadas pelo nosso sistema. Sendo assim, é necessário que faça a adaptação, respeitando a tabela do município, para que não tenha problemas no envio de NFS-e pela integração. Anexo04 - Tabela de Tipos de Logradouros(LINS).xls

ok

Se você fizer o mesmo teste com o programa exemplo, usando essas classes, ocorre o mesmo comportamento ? Chegou fazer este teste ?

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.

Bom dia! A implementação do método foi enviada ao SVN na Rev-29923. Para utilizar ele você vai chamar: ACBrNFSeX.ConsultarSeqRps; A chamada do método não recebe nenhum parâmetro, mas utiliza os seguintes dados configurados previamente no componente para montar a requsição: ACBrNFSeX.Configuracoes.Geral.CodigoMunicipio; ACBrNFSeX.Configuracoes.Geral.Emitente.InscMun; ACBrNFSeX.Configuracoes.Geral.Emitente.CNPJ; Depois de executar o método, você vai checar a resposta nas propriedades: ACBrNFSeX.WebService.ConsultarSeqRps.IMPrestador; ACBrNFSeX.WebService.ConsultarSeqRps.CNPFCNPJRemetente; ACBrNFSeX.WebService.ConsultarSeqRps.NroUltimoRps; Por favor, queria atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia! Vou Atualizar e testar. Obrigado.

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.

Boa tarde! Que bom que deu certo de encontrar a solução para a questão. Neste caso em questão, foi resolvida enviando o valor 85. O ideal seria que o provedor fornecesse uma tabela, pois não tem como adivinhar qual valor corresponde a que nesses casos e o padrão que estamos habituados é o código de serviço. Muito obrigado por reportar. Pelo que pude perceber esta questão está encerrada. Vou encerrar o tópico e caso surja alguma nova dúvida ou problema, basta criar um novo.

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 @ARConsultoria e @tiautomacao ! Infelizmente em nossos testes algumas requisições demoraram 15 minutos para serem concluídas. Enquanto isso recebíamos a reposta “Solicitação ainda em processamento”. Nosso amigo @tiautomacao falou com o banco e recebemos a reposta: "INFORMAÇÃO IMPORTANTE: Conversei com nossa gerente financeira agora e ela disse assim: 1-Se no dia do Registro ela pedir o arquivo de boletos baixados, demora 20 minutos ou mais, (pelo site) 2-Se for em outros dias, que ela não registra nada, demorar entre 10 e 15 minutos para liberar o arquivo. Então, a API demorar 15 minutos está super normal. Está dentro da normalidade viu." Como o componente não pode ficar aguardando 15 minutos uma reposta, fica inviável implementar esta consulta. Neste caso sugerimos tratar o retorno via arquivo CNAB.

Bom dia! Foi enviado ao SVN na Rev-29722 alterações visando corrigir o problema. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

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.