Painel de líderes

Show.. muito obrigado... Pode deixar que eu mesmo sigo com a analise...

eu verifiquei calma e achei o erro. Segue print A gerava os xml e depois chamava o evento AssinarEventos, isso fazia gerar novamente, por isso duplicava. Olhando seu exemplo, retirei o método AssinarEventos, e coloquei o Gerar, Assinar e Validar. Funcionou perfeitamente. Agradeço imensamente o auxilio!

Boa tarde, fiz implementação do TEF Auttar via DLL nos fontes do ACBR, inclusive homologado junto a Auttar. Quem começou o desenvolvimento foi @Michael Belmonte, eu achei os fontes na internet e terminei a adaptação para o ACBR. Por favor, peço que validem e se possivel liberem no SVN. Obrigado João Victor ACBrTEFD.zip

Pessoal, Preciso pedir desculpas. O erro que estava ocorrendo é de schema. Copiei o ultimo schema da pasta exemplo do ACBr e funcionou perfeitamente. Por favor, encerrem o tópico. Obrigado Icozeira

Boa Tarde Pessoal, agradeço a ajuda de todos e as dicas. Finalmente consegui resolver, no meu caso era o SSLTYPE, na verdade tava "comendo bola", ao enviar o reinf, o meu programa não estava setando a propriedade SSLTYPE no componente, possivelmente estava indo nula, hoje resolvi dar corrida nas rotinas, checando parte a parte e notei que estava faltando a carga do SSLTYPE no componente. Arrumei a rotina e fiz transmissão, funfou belezinha. Mais uma vez, obrigado a todos pela ajuda.

Boa tarde, O limite é de 50 eventos por lote no novo modelo assíncrono, no modelo síncrono são 100. 5. Envio de Lote - modelo assíncrono A partir da entrada dos novos eventos da série R-4000, a EFD-REINF possuirá o modelo de envio de lote com processamento assíncrono. A princípio para os lotes no modelo assíncrono a quantidade máxima será de 50 (cinquenta) eventos. Essa quantidade poderá ser alterada durante os testes e até o efetivo início da recepção em produção. Neste caso o manual será atualizado. Segue manual com maiores informações. http://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ManDesenvolvedor/ManualOrientacaoDesenvolvedor-REINF-v2.3.pdf

Bom dia, Acredito que o texto atual esteja de acordo com o descrito no MOC.

Bom dia! A configuração fica no caminho DFe > Impressão > Dados Empresa.

Eu quem agradeço a atenção.

Por favor, faça um teste utilizando o programa exemplo. Ambos os arquivos anexos* foram gerados marcando o evento R-4020 e usando o botão "Gerar Arquivos" do programa exemplo. Como é possível observar: Ele gera, assina e valida os XMLs. *Removi a informação das tags relacionadas a assinatura, mas como é possível observar, o XML foi gerado corretamente. Estou usando certificado A1, configurado apenas caminho PFX e senha. Reitero também que verifique se seus fontes e seu programa exemplo não possuem alterações locais e que ao atualizar os fontes do ACBr, é preciso reinstalar para que as atualizações e alterações surtam efeito, então sempre que fizer um SVN Update, precisa reinstalar. 1111111110000002023092209453524440-R-4020-0.xml 1111111110000002023092209373708795-R-4020-0.xml

Mas será que uma IDE em 64 bits resolveria esse problema? Os Compiladores do Delphi são outros executáveis... e sao vários... para cada plataforma...

Olá boa tarde, pegamos a seguinte inconsistência no WriteToIni() da classe EventoPagOpTrasnporte. Fazendo com que ao carregar o evento retorne erro pois os índices ficam errados. A var é J ao invés de I, nesse caso fica em looping até gerar a exceção de índice. EventoPagOpTrasnporte.cs

@Daniel Simoes, muito obrigado pela aula! Fiz como indicou, e o cupom impresso ficou perfeito! Obrigado.

Boa tarde, Realizei diversos testes. Se gera o XML sem vogais acentuas e cedilha o XML é assinado, enviado e o provedor não recusa por assinatura invalida. Por outro se incluir cedilha ou vogais acentuadas, o mesmo é recusado e o motivo é assinatura inválida. Peguei esse XML recusado pelo provedor e chequei a sua assinatura através do site: Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br) Ele acusa que a assinatura é valida. Chego a conclusão que o problema é o webservice do provedor que deve fazer uma checagem diferente. Logo o componente esta gerando e assinando da forma correta. Não tem o que ser alterado nele.

Boa tarde, Criada a TK-4485 para avaliação. Obrigado pela contribuição.

vou instalar uma versão Zerada .. aqui eu uso Lazarus Italo .. vou fazer isso . e te aviso aqui .. Desde ja agradeço .. toda a sua ajuda . Adilson Pazzini .

Boa tarde Marcos, Já esta no SVN.

muito obrigado

Bom dia, o código fonte de vocês parece não estar atualizados a versão do componente é a atual 22/09/2023? ou superior a 22/06/2023

Obrigado pelo retorno como você apresentou está de acordo, só vamos notificar o cliente que solicitou que a descrição fosse "Emitente" que conforme o manual de orientação do contribuinte (MOC) não há essa possibilidade. Agradeço a sua explicação, Salvei o link do MOC para consultas antes de novos questionamentos.

De minha parte, podemos considerar resolvido. Obrigado a todos, em especial ao Diego.

Bom dia! @jplguido, você pode deletar essa Unit, eles não estão mais utilizando ela.

Bom dia João, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-4481

Bom dia Diego Baixei a versão 1.4.0.198 do ACBrMonitorPLUS e armazenou no local configurado (Salvar XML de Downloads). Só a impressão que gostaria de saber onde configuro o logo da prefeitura. Pelo menos no ambiente de homologação ele não aparece. Não testei em produção. Saudações.

testei aqui e funcionou, to usando Alexandria

Entendi o cenário. Aberta a TK-4479 para avaliação. Obrigado.

Sim, nessa situação eu coloquei o seguinte valor: Selçao [CFe] - Tag: SSLHttpLib=4 (Não ativo na compilação ACBr). Não grava log mesmo, pois a dll nem chega a inicializar e ocorre o erro. Então creio que tenha algo dentro da Lib que não permite fazer mais nada (nem mesmo gravar o log de erro), pois a configuração está incorreta. Mas é bem simples simular essa situação: basta mudar essa tag que informei acima no seu ACBrLib.ini e tentar utilizar a Lib, vai perceber que o erro irá ocorrer.

Vamos tentar achar uma solução aqui, muito obrigado!

Luiz, esse log que você enviou é o gerado com a configuração que você comenta? porque no log não consta nem a mensagem de erro do -1 que vc cita. Obrigado

Bom dia Valdir, O problema é o seguinte: O Consultar Evento existem 3 formas diferentes de realizar essa consulta. 1. Consultar informando somente a chave da NFS-e, esta consulta esta funcionando sem nenhum problema, retorna e salva o XML do evento. 2. Consultar informando a chave e o código do evento desejado, esta consulta não é realizada retornando um erro 404. 3. Consultar informando a chave, o código e o numero sequencial do evento, esta consulta esta funcionando em partes, pois quando o componente tenta descompactar o XML após ter sido decodificado em base 64 ocorre o erro de Data Error. Descobrimos que o XML foi codificado em base 64 duas vezes, note que existe uma linha comentada que chama a função DecodeBase64 duas vez, se você comentar a linha acima e descomentar a outra, vai ver que vai funcionar. Mas lembre-se que se fizer essa alteração a primeira forma de consulta vai parar de funcionar. Já reportei o problema para o pessoal que cuida da API, agora é aguardar eles fazerem as devidas correções.

Bom dia Everton, Apesar de no XML da NF3e constar o grupo autXML que tem como objetivo relacionar as pessoas (CNPJ ou CPF) autorizados a ter acesso ao XML, o componente já possuir o método para consumir o DistribuicaoDFe para obter os XML, a SEFAZ ainda não disponibilizou a URL de homologação e de produção para esse serviço. Isso explica a mensagem de erro.

@Valdir Dill Bom dia ! Os fontes do ACBr estão atualizados? Se testar com o programa exemplo o mesmo acontece? pode realizar um teste de atualizar os repositórios e testar via exemplo por favor.

Bom dia @Luiz Antonio Ubaldini Criado a TK-4477 para análise do time. Obrigado por reportar

@Dev Telluria Bom dia ! Consulte o estado operacional do seu SAT em questão, ele vai devolver algumas informações, dentre elas a versão do layout do firmware dele, exemplo: Então vc ajusta seu INI de acordo com esta resposta. Talvez em outros clientes funcionam , pois já estão com 0.08 , mas este ai deve estar ainda no 0.07

https://projetoacbr.com.br/cursos/nfce-offline/

A janela de Preview do Fortes Report é montada internamente pelo mesmo. Você pode conferir a unit RLPreviewForm para mais informações. Não encontrei nela uma propriedade específica relacionada ao ícone da janela de preview (tem relacionada aos ícones da janela do menu dela). Mas elas não são acessíveis diretamente no componente ou na Lib.

Por favor, seus fontes estão atualizados? Você não possui nenhuma modificação local? (Isso é indicado pelo SVN com uma bolinha vermelha). Pergunto porque fiz um teste com o programa exemplo e o XML foi gerado corretamente. Já no arquivo r-4020_3.xml que nos encaminhou no e-mail, está constando duas vezes as mesmas informações. Vale a pena você conferir a sua rotina de preenchimento do evento também.

No Linux, você precisa instalar as dependências (OpenSSL 1.1.1 e LibXML2)

Bom dia @Renan S, de imediato não. Estamos tentando desenvolver uma avulsa junto com um arduino, mais ainda não avançamos. Segue abaixo o link onde adquirimos uma avulsa para teste(assim que tiver uma solução posto o resultado) https://pt.aliexpress.com/item/4000386522400.html?spm=a2g0o.order_list.order_list_main.4.2763caa4Sh3ouO&gatewayAdapt=glo2bra

Bom dia, Conforme publicação de ontem do portal do Reinf, o ambiente de Produção estará indisponível das 07h às 17h de 21/09/2023. http://sped.rfb.gov.br/pagina/show/7271 Publicado em 20/09/2023 Comunicamos que o ambiente de produção da EFD-Reinf estará indisponível do período de 7h às 17h do dia 21/09/2023 para realização da migração da versão 1.5.1 para a versão 2.1.2 e implantação da recepção dos eventos da série R-4000. A aplicação da EFD-Reinf acessada pelo e-CAC (https://www3.cav.receita.fazenda.gov.br/ ) também ficará indisponível nesse período. Após concluída a implantação, apresentará mudanças na interface visual buscando facilitar sua utilização com a implantação da série R-4000.

Estamos avaliando ainda a situação. Se os endereços voltarem a funcionar o componente naturalmente volta a funcionar. Nos outros casos as platafomas de consulta ou são pagas ou envolvem soluções diferentes como as que foram sugeridas neste tópico. Lembrando sempre que procuramos manter compatibilidade com Lazarus e com versões anteriores do Delphi até o Delphi 7. Então algumas soluções apresentadas precisam ser avaliadas e testadas em diversos cenários.

Parece que estão trabalhando nisso...

Olá pessoal, Para aqueles que acompanharam as reuniões com o Fisco do RS ao vivo ou viram a gravação posteriormente, ficou a pendência por parte do Fisco de tornar viável a orientação dada quanto a inserção na NFCe de Recargas de Celular e outras Operações como Recebimento de Contas, mas usando o CFOP 5949. Como todos sabemos, até a data da publicação deste post, isto não é possível, já que ocorre rejeição por por parte do ambiente de emissão, porém com a publicação da NT 2023.003, a partir de 05/06/2023 em homologação e 03/07/2023 em produção passará a ser possível atender esta demanda. Apesar da modificação trazida pela NT acima citada ter sido gerada pela demanda do RS, ainda não temos informações mais claras da UF, porém eles já sinalizaram que irão emitir uma orientação sobre o preenchimento do documento. At.

Novidade saindo do forno pessoal!! A SEFAZ-RS publicou em 15/05/2023 a Instrução Normativa 37/23, qual estabelece um novo cronograma para a exigência das mudanças trazidas pela legislação, desta forma a obrigatoriedade esta escalonada por faturamento tendo seu ultimo grupo entrando em 01/01/2024. Link para a Instrução Normativa: https://www.diariooficial.rs.gov.br/materia?id=857004

Boa tarde pessoal, Foi publicado em 08/03/2023 a instrução normativa excluindo as empresas com faturamento inferior a R$ 360.000,00 em 2022 da obrigatoriedade em 01/04/2023, ou seja agora só aquelas que se enquadram nos CNAEs citados e tem tiveram faturamento SUPERIOR a R$ 360.000,00 permanecem conforme já estava previsto anteriormente. Fonte: https://www.diariooficial.rs.gov.br/materia?id=826207

Boa tarde, Foi publicada em 26/12/2022 a Instrução Normativa 108/2022, a qual trouxe pequenos ajustes visando esclarecer melhor a integração entre os pagamentos eletrônicos e os documentos fiscais. A seguir as diferenças com as mudanças destacadas em vermelho e textos removidos em tachado Esclarecimento sobre as Operações afetadas (Artigo 29.5.1) A emissão do comprovante de transação ou intermediação de vendas ou serviços, realizados de forma presencial, efetuada com cartões de débito, de crédito, de loja ("private label"), transferência de recursos, transações eletrônicas do Sistema de Pagamento Instantâneo e demais instrumentos de pagamento eletrônico, deve estar vinculada à NFCe emitida na operação ou prestação, mediante interligação com o programa emissor do documento fiscal Sobre as Obrigatoriedades (Artigo 29.5.1 b) b) 01/07/23, para os demais estabelecimentos emissores de NFC-e. Sobre as Informações Mínimas no Comprovante de Transação (Artigo 29.5.1.3 - Itens b e c) b) número da autorização junto à instituição de pagamento código da autorização ou identificação do pedido c) identificador do terminal em que ocorreu a transação, nos casos em que se aplica Sobre o envio das Informações pelos Bancos (Artigo 1.1.4 - Itens g e h) g) para os meses de julho a setembro julho e agosto de 2023, até o último dia de outubro de 2023; h) para outubro setembro de 2023 e meses subsequentes, conforme prazo estabelecido no "caput" do item 1.1 Fonte: http://www.legislacao.sefaz.rs.gov.br/Site/Document.aspx?inpKey=292768&inpCodDispositive=&inpDsKeywords=108