Painel de líderes

Olá Pessoal, Já se encontra no SVN a atualização dos fontes de componente ACBrCTe visando a emissão do CT-e Simplificado. Foi enviando também a atualização dos programas exemplos tanto em Delphi quanto em Lazarus, que agora tem uma procedure para exemplificar a alimentação do componente para a emissão do CT-e Simplificado. Peço a todos que façam a atualização dos fontes, reinstale o ACBr e realizem os testes. Até a data de hoje (17/09/2024) somente a SEFAZ-Virtual do RS que disponibilizou as URLs de homologação especificas para o CT-e Simplificado, sendo assim somente RS e as UF atendidas pela SVRS que vão poder realizar os testes neste momento. UF atendidas pela SVRS: AC, AL, AM, BA, CE, DF, ES, GO, MA,PA, PB, PI, RJ, RN, RO, RS, SC, SE e TO. Caso encontre algum erro na emissão do CT-e Simplificado ou no CT-e ou CT-e OS ou GTV-e, por favor criem um tópico no fórum relatando o problema para que possamos sanar o mais breve possível.

Olá, pessoal. Temos o prazer de anunciar que o novo pacote ACBrBaas já está disponível no SVN! Este pacote foi criado para facilitar a integração de sistemas com serviços bancários e APIs de pagamento, atendendo à crescente demanda por soluções de automação financeira. ACBrExtratoAPI: Primeira Solução Disponível O primeiro componente disponível neste pacote é o ACBrExtratoAPI. Este componente permite a consulta de transações do extrato de uma conta corrente, ideal para quem precisa automatizar o acompanhamento e controle financeiro diretamente em seu software. Atualmente, o ACBrExtratoAPI oferece suporte para dois bancos: Banco do Brasil Banco Inter A proposta é expandir o suporte para outros bancos, conforme a demanda dos usuários. Então, caso seu banco de interesse ainda não esteja incluído, fique à vontade para sugerir a inclusão! Futuros Componentes no Pacote ACBrBaas Além do ACBrExtratoAPI, estamos trabalhando na inclusão de novos componentes ao pacote ACBrBaas, que irão ampliar ainda mais suas funcionalidades, entre eles: ACBrPagamentosAPI: Voltado para a integração com APIs de pagamento, facilitando transações financeiras diretamente pelo software. ACBrBBPay: Um componente específico para a plataforma BBPay, do Banco do Brasil, que permitirá realizar transações de forma simplificada. Estamos atentos às necessidades dos usuários e planejamos adicionar mais APIs bancárias e de pagamento, tornando o ACBrBaas uma ferramenta essencial para desenvolvedores que buscam eficiência e automação no setor financeiro. Disponível em: https://svn.code.sf.net/p/acbr/code/trunk2/Exemplos/ACBrBaaS/ Fiquem atentos às próximas atualizações!

tentei várias coisas mas a solução definitiva foi uma dica do @Daniel Simoes aqui no forum com essa configuração funciona sem erros

Olá pessoal! No dia 01/07/2024 entrou em vigor no ambiente de produção as regras de validação da versão mais recente da Nota Técnica 2023/004. Essa versão alterou a regra de validação que devolvia a rejeição 391, dando a ela o texto: Quando está regra entrou em vigor, muitos contribuintes começaram a receber no estado de Minas Gerais a rejeição 391, o que no início assustou muitos colegas, visto que a UF não havia publicado legislação que dessa a entender que adotaria a implementação da mesma. Na época, a AFRAC buscou mais informações junto a Sefaz e recebeu o seguinte retorno: No dia 16/09/2024, ao acessar o portal SPED MG o seguinte aviso foi exibido indicando que a regra será reativada no dia 01/10/2024:

Abre o exemplo, escolha a primeira cidade, clica em "Salvar Configurações" Fecha o exemplo e abre novamente...deve aparecer a cidade...

Obrigado @Diego Foliene também. Pela sua ajuda e esforço de sempre;

Boa tarde. Alteração enviada ao SVN na Rev-35294

Desculpa @Italo Giurizzato Junior Refiz o teste com a linha que você indicou e gerou com sucesso. Vou enviar a unit em anexo, para que vocês possam avaliar. Obrigado. EL.Provider.pas

@C4Dev, O provedor EL na sua versão 1 (layout próprio) o fluxo para obter o XML completo da NFS-e é este abaixo: 1. Alimentar o componente com os dados do RPS. 2. Enviar o RPS para o webservice. 3. Com o componente ainda carregado com os dados do RPS, executar o Consultar Situação informando o numero do Protocolo retornado ao enviar. 4. Com o componente ainda carregado com os dados do RPS, executar o Consultar Lote informando o numero do Protocolo. 5. Se o RPS foi processado com sucesso o componente vai montar o XML completo da nota com os dados do retorno da consulta ao lote. Você esta seguindo esse fluxo? Ele chega a gravar o XML da nota em disco?

Faça o teste usando essas unit. reinstale o componente após trocar. lembrando que somente foi implementado no Sicoob V3 ACBrBoletoW_Sicoob_V3.pas ACBrBoletoWS.pas

Sim, vi aqui. No retorno deles aparece assim : "juros" : { "codigo_tipo_juros" : "01", "valor_juros" : "00000000000000008", "percentual_juros" : "00000000000960000" }, "multa" : { "codigo_tipo_multa" : "02", "valor_multa" : "00000000000000050", "percentual_multa" : "00000000000200000" } Como se ele calculasse o juros mensais automaticamente, ficando igual ao Santander, que só aceita juro percentual mensal. Acho que o Itaú aceita as outras formas de cobrança de juros, mas transforma para percentual mensal automaticamente. Estou aguardando o retorno deles.

@C4Dev, Eu acho que ficou faltando uma linha, veja: AResumo.Data := Response.Data; AResumo.Situacao := Response.Situacao; AResumo.NumeroRps := Response.NumeroRps; aXmlRetorno := AuxNode.OuterXml; <==== incluir esta linha if AResumo.NumeroNota <> '' then ANota := TACBrNFSeX(FAOwner).NotasFiscais.FindByNFSe(AResumo.NumeroNota); if not Assigned(ANota) then ANota := TACBrNFSeX(FAOwner).NotasFiscais.FindByRps(AResumo.NumeroRps); Inclui a linha reinstale o ACBr e faça novos testes.

Boa tarde @chico_lopes, Pelo que eu entendi, você pega um XML qualquer e na base da tentativa erro tenta descobrir se o XML é de uma NF-e, ou CT-e, ou evento de NF-e ou evento de CT-e, é isso? Se a ideia é essa não seria o caso de, você carregar o XML como uma string checar a presença de um elemento que você sabe que só existe em um determinado tipo de documento? Por exemplo: procedure TfrmEmissorDFE.CarregaArquivo; var ArquivoXML: TStringList; Tamanho: Integer; PathEvento: String; begin ArquivoXML := TStringList.Create; ArquivoXML.LoadFromFile(edtArquivo.Text); TipoDFE := 0; if pos('<infNFe', ArquivoXML.Text) > 0 then TipoDFE := 1; if pos('<infCte', ArquivoXML.Text) > 0 then TipoDFE := 2; if pos('InfNfse', ArquivoXML.Text) > 0 then TipoDFE := 3; if pos('infMDFe', ArquivoXML.Text) > 0 then TipoDFE := 4; if pos('procEventoNFe', ArquivoXML.Text) > 0 then TipoDFE := 5; if pos('procEventoCTe', ArquivoXML.Text) > 0 then TipoDFE := 6; if pos('procEventoMDFe', ArquivoXML.Text) > 0 then TipoDFE := 7; ArquivoXML.Free; (...) end;

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

Boa tarde @Anderson Grolli, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Bom dia @Anderson Grolli, Já foi criado a TK-5972 para analise do problema.

Bom dia @Elisângela Borato, Você anexou a unit do Ginfes e não do Giap.

Vamos aguardar, fazer um modelo próprio estaria imprimindo documento fiscal sem homologação dos órgão competentes. Obrigado.

Daniel, eu quis dizer em relação à outra consulta (tpConsultaDetalhes), pode usar sim para a tpConsulta. Meu medo maior na verdade é em relação à registro e alteração de boletos. Caso não dê certo com os dados da outra pessoa pode usar estes aí pois todas as outras requisições estão funcionando de boa. A requisição da movimentação do Sicoob é bem complicada. Era só para fazermos a requisição e ela devolver um Json, mas pense complicação que inventaram? Você faz a pesquisa da movimentação e ao invés de trazer um retorno Json, ele traz um codigoSolicitacao Ai depois você faz outra requisição com esse código para obter um ou mais de um IdArquivo e isso quando estiver disponivel. Aí depois você faz uma terceira requisição com cada um destes IdArquivos para baixar os arquivo zipados Aí você vai ter de descompactar esses arquivos para obter os Json. Pense no gênio, esse cara que criou essa requisição!?

segundo pessoal do banco o numero do contrato é o mesmo numero do convenio, porem estas outras duas informacoes(CodigoCedente, CodigoTransmissao), vou pedir pra eles preencherem pra min.

Sim, mandei um email para o suporte, estou aguardando o retorno.

@Pedro Frayman, pode me ajudar com esse caso ?

Deu certo Obrigado @Juliomar Marchetti e @EliasCesar

- Verificar se no path do windows tem a OpenSSL versão 3, e remover se tiver (pode causar problemas com outras aplicações) ou - Fazer a "conversão" do certificado digital pra tornar ele compatível com a OpenSSL versão 3, conforme o link na primeira resposta deste tópico

é o mesmo numero da conta, segundo eles

Na verdade se tu olhar o componente basta tu acessar lá ACBrNFSeX.Configuracoes.Webservice.SSLType e lá tem

Com o componente PosPrinter você pode usar os métodos: function LerStatusImpressora( Tentativas: Integer = 1): TACBrPosPrinterStatus; function LerInfoImpressora: String; O ACBrSATExtratoESCPOS é apenas um componente de configuração.

isso daqui é MDFe é o documento para a transportadora usar para informar os CTe e NFe no caso tu está querendo os MDFe ou as NFe ser for NFe é com ACBrNFe e se for CTe é com o ACBrCTe

ok vou fazer o teste. obrigado

Olá Pessoal, É com grande alegria que informo a todos que já se encontra no SVN o componente ACBrNFCom. Para quem não sabe o que vem a ser NFCom, segue abaixo o texto copiado do Portal da SEFAZ-Virtual do Rio Grande do Sul. "O Projeto NFCom tem como objetivo a implantação de um modelo nacional de documento fiscal eletrônico (modelo 62) que venha substituir a sistemática atual de emissão da Nota Fiscal de Serviço de Comunicação/Telecomunicações (modelos 21 e 22), com validade jurídica garantida pela assinatura digital do emitente, simplificando as obrigações acessórias dos contribuintes e permitindo, ao mesmo tempo, o acompanhamento da emissão em tempo real pelo Fisco." Foi enviado para o SVN, os fontes do componente, os pacotes de instalação para o Delphi e Lazarus e o programa exemplo para o Delphi. O que falta a ser feito: o programa exemplo para o Lazarus e a instalação do componente via ACBrInstall. Enquanto não for liberado uma nova versão do ACBrInstall a instalação do componente vai ter que ser via pacote. Como eu não tenho um certificado digital de um prestador de serviço de comunicação/telecomunicações os testes ficam prejudicados. Detalhe importante: Na pagina que trata o NFCom no Portal da SEFAZ-Virtual do Rio Grande do Sul não consta ainda o manual com o layout do DANFCom, sendo assim não foi possível implementar o componente de geração do Documento Auxiliar da NFCom. Convido a todos que tenham interesse nesse componente, instalar e fazer os testes. Ficaremos felizes em receber melhorias e correções nos fontes do componente.

Pessoal, pesquisando aqui encontrei esse código de rejeição da NFCe. 715 - Rejeição: NFC-e com finalidade inválida De acordo com a Nota Técnica 2013.005, a rejeição “715 - NFC-e com finalidade inválida”, será retornada ao emitir uma NFC-e onde a finalidade for diferente de Normal. O que essa rejeição significa na prática? Ao emitir uma NFC-e onde a finalidade de emissão (campo finNFe) for diferente de ‘1 – Normal’, será retornada à rejeição 715, ou seja, as opções 2 - NF-e complementar; 3 – NF-e de ajuste e 4 - Devolução/Retorno não são aceitas. Exemplo: O emissor envia uma NFC-e onde a finalidade de emissão é igual a "2 - NF-e complementar". Isso resultará na rejeição do documento pelo motivo 715, pois para emissão de NFC-e é permitido apenas o uso da finalidade "1 - NF-e Normal". Como resolver? Na emissão de NFC-e deve-se sempre informar a Finalidade de Emissão como 1 - Normal. Se necessitar emitir com uma Finalidade de Emissão diferente de Normal, opte pela emissão de uma NF-e (modelo 55). Para contornar essa rejeição deve-se modificar o campo finNFe para 1 e enviar o documento novamente. Resumindo, não tem como emitir nota fiscal complementar de uma NFCe.