Painel de líderes

Conforme comunicado pelos colegas do Banco do Brasil, haverá manutenção obrigatória em equipamentos de rede no dia 29/03 (domingo), a partir das 2h, com previsão de até 4 horas de duração (podendo ser concluída antes). Durante esse período, poderão ocorrer impactos na geração e no pagamento de QRCode (BB e outros bancos) em ambiente de produção. Outros serviços também podem ser parcialmente afetados. Aquipe de TI do BB estará de plantão durante toda a manutenção, acompanhando o processo e atuando para minimizar possíveis impactos

Prezados Enviaram uma atualização dia 18/03 aumentando o tamanho do pais para 4 caracteres, mas Barueri tem a sua própria relação de pais e sempre foram 3 caracteres. Atualizei o componente ontem e hoje um cliente nosso recusou mais de 1.000 rps deles. https://www.barueri.sp.gov.br/nfe/app/Manuais/RPS_TabelaPaises.pdf Segue unit alterada. Atenciosamente. ISSBarueri.GravarXml.pas

vc deve ter, mas caso não tenha e precisar de usuario e senha, tenho de um cliente que efetuei envios de xml e cancelamentos

Boa tarde galera, eu atualizei os meus fontes hoje e quando fui emitir a primeira nota tive o erro em anexo. Investiguei a cheguei a conclusão que tem um erro de logica nos fontes do acbr. Na unit PadraoNacional.GravarXML.pas, linha 1615 temos o seguinte código: NrOcorr := 0; if (NFSe.Servico.Valores.tribMun.tpRetISSQN = trNaoRetido) and (NFSe.OptanteSN <> osnNaoOptante) then NrOcorr := 1; Result.AppendChild(AddNode(tcDe2, '#1', 'pAliq', 1, 3, NrOcorr, NFSe.Servico.Valores.tribMun.pAliq, '')); Mas esse IF acredito que esteja errado, porque, se o ISSQN não é retido e o emissor é optante pelo simples nacional não deve ser informada a alíquota de tributação municipal. No caso com esse fonte alíquota é informada zerada... Comentei esse trecho e a nota validou com sucesso

Boa tarde sim sim. eles mudaram autenticação. estou com código aqui do ACBrANE modificado e efetuando alguns testes. nas proximos dias será commitado no SVN

Boa tarde @Daniel InfoCotidiano, enviamos um e-mail para a Tinus solicitando mais informações a respeito. Assim que obtivermos uma resposta retorno aqui mesmo.

vlw! S´pra quem ainda está com dificuldades nesta questão, de uma pausa de 1 segundo antes de cada requisição, se estiver tipo carregando uma base com alíquota do município vai demorar um pouco mais, mais a api não vai dar erro por excesso de requisições.

Foi criada a tarefa ACBR-9192 para análise do caso e parecer por parte da equipe de consultores. Qualquer novidade será divulgada aqui no tópico.

provavelmente fora dos padrões do manual e da lei

Bom dia Cliente já está usando em fase de produção, tudo ok com a emissão com a versão que passei. Assim que possivel, farei a consulta, embora ela seja um pouco "inutil" pq não traz pagamentos. Obrigado.

Bom dia Juliomar. Entendi, e já vi como imprime apenas o protocolo... É que o meu cliente me enviou uma foto de um MDF-e diferente. Abraço, Wagner

vai ver que a prefeitura estava usando uma base de cep desatualizada e do nada resolveu atualizar.

acho q só muda a numeração se fosse emitido pelo emissor nacional. Como continua emitindo pelo provedor, acredito q continua com a mesma numeração.

Obrigado por este retorno parcial, aguardamos novas atualizações

Mandei um email o setor de tributação da prefeitura de Ijuí-RS detalhando todo o problema. Em todos da Pronim deve ocorrer essa situação. NFSE emitidas por CPF. Eles vão precisar corrigir.

Já chegou a entrar em contato com o Pronim a respeito deste problema? Passe esta sua observação para eles e nos mantenha atualizados.

Descobri onde está o problema (e é no sistema da PRONIM), olha só: Na mensagem de erro está assim: "erros":[{"codigo":"P9008","descricao":"Documento do Certificado Digital (14071941104686) enviado na requisição difere do documento do emitente da nota (10468617000)"}]" Perguntei ao portador do certificado A1 CPF, se a data de nascimento era 14/07/1941. E a resposta foi SIM. Se juntarmos a data de nascimento (14071941) com os 6 primeiros dígitos do CPF (104686), o resultado é: 14071941104686 (14 dígitos, igual a um CNPJ) Ou seja, o sistema PRONIM está esperando necessariamente sempre por um CNPJ, ao pegar os metadados do certificado A1 CPF, ele está pegando os 14 primeiros dígitos dos metadados. O sistema da PRONIM deveria primeiro ver o tipo do certificado, se é CPF ou CNPJ, e dependendo do tipo fazer a validação dos metadados com o CPF ou CNPJ do emissor da nota.

Olá @Italo Giurizzato Junior, Muito obrigado pela inclusão rápida! Já estamos em produção com Estiva Gerbi, emissão funcionando perfeitamente. Porém, para o cancelamento via EnviarEvento (pedRegEvento com tpEvento=e101101), precisamos da linha ProEnviarEvento. Sem ela, o ACBrLib retorna "Serviço não implementado para este provedor". Poderia adicionar ao município 3557303: ProEnviarEvento=https://webapp1-estivagerbi.cidade360.cloud/Nfse.Api/NotaNacional Ficando: [3557303] Nome=Estiva Gerbi UF=SP Provedor=Pronim ProRecepcionar=https://webapp1-estivagerbi.cidade360.cloud/Nfse.Api/NotaNacional ProEnviarEvento=https://webapp1-estivagerbi.cidade360.cloud/Nfse.Api/NotaNacional Já testamos o cancelamento com essa URL e funcionou em produção. Obrigado, sucesso!

Boa tarde, Identificamos alterações necessárias para emissão de NFSe através do provedor Centi. Há algumas informações do padrão Abrasf que não existem nos schemas do provedor. Estamos anexando a unit em que realizamos as alterações para análise e versionamento pelo ACBr. ACBrNFSeXGravarXml_ABRASFv2.pas

Boa tarde @Center Informática, Você tem fontes do ACBr 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 as opções de apagar arquivos antigos e Usar o ACBrXmlDocument marcadas. Compile a aplicação com a opção Build. Por fim repita os testes.

Ao desenvolver um projeto NOGUI com o ACBrCTe no LINUX, estava recebendo a seguinte mensagem na compilação da unit pcteCTe.pas pcteCTe.pas(50,49) Error: Cannot find pcteProcCte used by pcteCTe, incompatible ppu=acbr/Lib/Lazarus/ACBrDFe/ACBrCTe/x86_64-linux/pcteProcCTe.ppu, package ACBr_CTe Após algum tempo de busca pela solução descobrimos que o problema estava relacionado a case sensitive na unit ACBrCTeWebServices.pas, onde estava escrito pcteProcCte (na linha 48) deveria estar pcteProcCTe, simplesmente a letra T. Imagem abaixo já com código corrigido.

Agora entendi então estou sofrendo atoa aqui, estou trazendo o CódigoAutorizacaoTransacao e está vindo padrão NSU. Então o demo de teste do GP Padrão de Tef não está vindo o CodigoAutorizacaoTransacao. O estranho que no comprovante de saída de impressão está vindo um número 124456 em todas as transações. Acha que pode ser o demo do tef ?