Painel de líderes

@Juliomar Marchetti, obrigado pela resposta, mas a atualização dos Schemas foi a primeira providência que tomamos e infelizmente sem sucesso. Enviei uma msg no portal da Sefaz, vamos ver o retorno deles. Enquanto isso, continuemos na contingência. Obrigado!

A receita retornou, problema resolvido.

Pode por favor, anexar os xmls soap envio e retorno.. nos envie por e-mail para : [email protected] coloque o link deste tópico no e-mail, por favor..

Resolvido, atualizei para versão ACBrMonitorPLUS-1.4.0.245-x64 e Saiu a NFC-e e NF-e. Obrigado !

Pessoal, sobre esse assunto, recebi um direcionamento de que a Sefaz iria prorrogar a implantação dessa NT, com uma nova data de início do período de homologação, dia 25/03/2024. Porém essa informação é extraoficial, não vi nenhuma manifestação da própria Sefaz sobre o assunto nos canais oficiais.

Realizei um teste de emissão e deu certo. Atualizarei as filiais e iremos acompanhar.

Bom dia. Mudança na URL da cidade de Birigui-SP. Segue em anexo o manual enviado pela prefeitura e o arquivo ACBrNFSeXServicos.ini para validação. [3506508] ; Atualizado em 07/07/2023 Nome=Birigui UF=SP Provedor=SmarAPD ProRecepcionar=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSEntrada ProConsultarSituacao=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSEntrada ProConsultarLote=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSSaida ProConsultarNFSeRps=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSSaida ProConsultarNFSe=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSSaida ProCancelarNFSe=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSEntrada ProGerarNFSe=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSEntrada ProRecepcionarSincrono=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSEntrada ProSubstituirNFSe=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSEntrada ProConsultarLinkNFSe=https://pmbirigui02.smarapd.com.br:8443/smartb/services/WSUtil HomRecepcionar=https://tributacao.smarapd.com.br:8443/birigui/services/WSEntrada HomConsultarSituacao=https://tributacao.smarapd.com.br:8443/birigui/services/WSEntrada HomConsultarLote=https://tributacao.smarapd.com.br:8443/birigui/services/WSSaida HomConsultarNFSeRps=https://tributacao.smarapd.com.br:8443/birigui/services/WSSaida HomConsultarNFSe=https://tributacao.smarapd.com.br:8443/birigui/services/WSSaida HomCancelarNFSe=https://tributacao.smarapd.com.br:8443/birigui/services/WSEntrada HomGerarNFSe=https://tributacao.smarapd.com.br:8443/birigui/services/WSEntrada HomRecepcionarSincrono=https://tributacao.smarapd.com.br:8443/birigui/services/WSEntrada HomSubstituirNFSe=https://tributacao.smarapd.com.br:8443/birigui/services/WSEntrada HomConsultarLinkNFSe=https://tributacao.smarapd.com.br:8443/birigui/services/WSUtil ProLinkURL=https://pmbirigui02.smarapd.com.br:8443/smartb/loginWeb.jsp?execobj=NFENotaFiscalBuscarDireto&cnpj=%Cnpj%&numero=%NumeroNFSe%&chave=%ChaveAcesso% HomLinkURL=https://tributacao.smarapd.com.br:8443/birigui/loginWeb.jsp?execobj=NFENotaFiscalBuscarDireto&cnpj=%Cnpj%&numero=%NumeroNFSe%&chave=%ChaveAcesso% Obrigado. NOVO_Manual_de_Integracao_NFS-e.pdf ACBrNFSeXServicos.ini

Olá pessoal! Conferindo no painel Situação SVC é possível observar que a contingência foi ativada para a Sefaz Bahia às 09h55 do dia 14/03/2024, com previsão de permanecer ativada até às 00h00 do dia 18/03/2024. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações deste tópico: Um agradecimento ao membro de nossa comunidade @_asseinfo por compartilhar a informação em nosso Discord.

@narlem Pode fazer um teste por favor. Se vc utilizar ACBrMonitor Use o metodo para definir o modelodf antes de criar a Nota https://acbr.sourceforge.io/ACBrMonitor/NFESetModeloDF.html exemplo NFe.SetModeloDF(65) ou NFe.SetModeloDF(55) (editado) Após o envio se puder nos dar um feedback

Pessoal, problema solucionado. SEFAZ parou de enviar a msg Falha no SChema XML. Aparentemente algo do lado deles mesmo.

Sim. Você não tinha problemas porque o comando automaticamente consulta o lote após fazer o envio. Ele te devolveu o status 100 porque ele te devolveu só o status da NF-e/NFC-e cStat: 100 Msg: Autorizado o uso da NF-e Os cStat 103, 104 e 105 estão relacionados ao lote e o processo assíncrono, por isso você não teve eles nesta tentativa do envio síncrono. cStat: 103 Msg: Lote recebido com sucesso. cStat: 104 Msg: Lote processado. cStat: 105 Msg: Lote em processamento. Isso vai depender do seu contexto e da sua necessidade, mas em minha opinião, acho interessante deixar o ambiente preparado para o envio síncrono por dois motivos. O primeiro é que o no envio assíncrono calhou de ser quase o mesmo tempo de espera, mas se formos ser minuciosos o envio síncrono é "mais rápido". Nele você envia a nota e recebe os erros ou a autorização em uma única conexão. O segundo é que novamente sendo minuciosos, o envio de forma assíncrona para NFC-e na verdade "chegou ao fim". Veja o tópico abaixo para mais detalhes:

atualiza a lib pois feito versão nova

é que o componente não foi modificado então só pode ser lá a situação e aproveitando eu só setaria as dusa propriedades SSLType := LT_TLSv1_2; SSLLib := libWinCrypt; as demais o componente se encarrega de setar correto

antes de carregar tu precisa configurar o componente para a cidade que vai ler o xml para que seja setado o provedor

Boa Tarde, Ja atualizamos a versão nova .244 e passou sem o campo! vamos distribuir nova versão. Obrigado.

Boa tarde, @Italo Giurizzato Junior Sim essas consultas foram realizadas numa NFS-e que foi e esta cancelada, confiro isso pelo site do provedor e fui eu mesmo quem cancelou pelo componente mesmo. Acho que você não leu o post todo com calma, pois o problema é exatamente esse, mas vou explicar de novo aqui: 1. Se consulto a NFSe pelo numero ela traz o grupo <NfseCancelamento>, exatamente da forma que esta abaixo: <NfseCancelamento> <Confirmacao> <Pedido> <InfPedidoCancelamento> <IdentificacaoNfse> <Numero>918</Numero> <Cnpj>01190940000153</Cnpj> <CodigoMunicipio>0</CodigoMunicipio> </IdentificacaoNfse> <CodigoCancelamento>0</CodigoCancelamento> </InfPedidoCancelamento> </Pedido> </Confirmacao> </NfseCancelamento> 2. Se consulto essa mesma NFSe pelo RPS ela simplesmente não trás esse grupo ou informação alguma sobre cancelamento. 3. Se consulto essa mesma NFSe pelo Protocolo ela simplesmente não trás esse grupo ou informação alguma sobre cancelamento. É esse o problema entende, o provedor é uma zorra simplesmente isso, a solução que eu propus no inicio desse topíco é que o componente verifique se existe a tag <NfseCancelamento> e se existir então define a propriedade ACBrNFSeX1.NotasFiscais.Items[0].NFSe.SituacaoNfse = TStatusNFSe.snCancelado. Voca ja disse que o componente faz essa verificação Porem como constatamos o provedor não manda essa informação no XML que esta de fato cancelado, veja a imagem em anexo, sendo assim somente a existência da tag <NfseCancelamento> com a tag filho <Confirmacao> é o suficiente para que confirmemos que a mesma esta cancelada, dai p ficar mais simples vc pode mudar de ao inves de verificar DataHora veja apenas se tem o numero da nota e ou o CNPJ. Lembrando que essa informação vem apenas na consulta da NFSe pelo numero, nas outras consultas nem isso vem, não vem nada, ou seja eles retornam como se fosse uma NFSe com situação normal. Ta na cara que não tem um responsável la naquela empresa (provedor) verificando uma informação tão importante como essa no retorno do XML.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Muito obrigado pela contribuição. Mas achamos melhor corrigir a função. Pelo visto, ela não era usada no código do ACBr em outros lugares e estava incorreta já faz um tempo. @ddsilva, Subi as alterações para o SVN na Revisão 32926. Pelo que vi está tudo certo. Pedimos a todos o favor de atualizar, testar e reportar qualquer problema. Mais uma vez obrigado a todos pelo relato e sugestões de correção.

Boa tarde pessoal! Um usuário do nosso ERP comparou o cálculo do CepCerto com a dos Correios e houve uma divergência no retorno do valor. Entramos em contato com CepCerto que apontou o envio do peso faltando um zero à direita. Analisando os fontes do ACBrSedex observei que o peso está sendo enviado com 2 casas decimais, mas deve ser enviado com 3 casas decimais. Fiz uma alteração no fonte que resolveu o problema. Segue em anexo. Obrigado ACBrSedex.pas

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

resolvido Fiz isto PintarQRCodeEstatico (); var i : integer; qrCodeData: string; begin ACBrPixCD1.Recebedor.Nome := DmDados.configuracao('NOME_PIX'); ACBrPixCD1.Recebedor.CEP := DmDados.configuracao('END_CEPPIX'); ACBrPixCD1.Recebedor.Cidade := DmDados.configuracao('END_CIDADEPIX'); ACBrPixCD1.Recebedor.UF := DmDados.configuracao('END_UFPIX'); lblNomePIX.Text := 'PAGAMENTO PARA, '+ACBrPixCD1.Recebedor.Nome; if DmDados.configuracao('TIPO_CHAVEPIX') = '1' Then begin ACBrPixBradesco.ChavePIX :='+5531'+DmDados.configuracao('CHAVE_PIX') end else begin ACBrPixBradesco.ChavePIX := DmDados.configuracao('CHAVE_PIX'); end; qrCodeData := ACBrPixCD1.GerarQRCodeEstatico( precoACobrar, 'PAGAMENTO ESTACIONAMENTO', ''); {$IFDEF MSWINDOWS} QRCodeWin(imgQR, qrCodeData); {$ELSE} QRCodeMobile(imgQR, qrCodeData); {$ENDIF} end; Usei o acbr para gerar a string do qrCode Quando mobile pela directiva procedure TfrmSaidaVeiculo.QrCodeMobile(imgQRCode: TImage; texto: string); const downsizeQuality: Integer = 2; // bigger value, better quality, slower rendering var QRCode: TDelphiZXingQRCode; Row, Column: Integer; pixelColor : TAlphaColor; vBitMapData : TBitmapData; pixelCount, y, x: Integer; columnPixel, rowPixel: Integer; function GetPixelCount(AWidth, AHeight: Single): Integer; begin if QRCode.Rows > 0 then Result := Trunc(Min(AWidth, AHeight)) div QRCode.Rows else Result := 0; end; begin // Not a good idea to stretch the QR Code... if imgQRCode.WrapMode = TImageWrapMode.Stretch then imgQRCode.WrapMode := TImageWrapMode.Fit; QRCode := TDelphiZXingQRCode.Create; try QRCode.Data := ' ' + texto; QRCode.Encoding := TQRCodeEncoding.qrAuto; QRCode.QuietZone := 4; pixelCount := GetPixelCount(imgQRCode.Width, imgQRCode.Height); case imgQRCode.WrapMode of TImageWrapMode.Original, TImageWrapMode.Tile, TImageWrapMode.Center: begin if pixelCount > 0 then imgQRCode.Bitmap.SetSize(QRCode.Columns * pixelCount, QRCode.Rows * pixelCount); end; TImageWrapMode.Fit: begin if pixelCount > 0 then begin imgQRCode.Bitmap.SetSize(QRCode.Columns * pixelCount * downsizeQuality, QRCode.Rows * pixelCount * downsizeQuality); pixelCount := pixelCount * downsizeQuality; end; end; //TImageWrapMode.iwStretch: // raise Exception.Create('Not a good idea to stretch the QR Code'); end; if imgQRCode.Bitmap.Canvas.BeginScene then begin try imgQRCode.Bitmap.Canvas.Clear(TAlphaColors.White); if pixelCount > 0 then begin if imgQRCode.Bitmap.Map(TMapAccess.Write, vBitMapData) then begin try For Row := 0 to QRCode.Rows - 1 do begin for Column := 0 to QRCode.Columns - 1 do begin if (QRCode.IsBlack[Row, Column]) then pixelColor := TAlphaColors.Black else pixelColor := TAlphaColors.White; columnPixel := Column * pixelCount; rowPixel := Row * pixelCount; for x := 0 to pixelCount - 1 do for y := 0 to pixelCount - 1 do vBitMapData.SetPixel(columnPixel + x, rowPixel + y, pixelColor); end; end; finally imgQRCode.Bitmap.Unmap(vBitMapData); end; end; end; finally imgQRCode.Bitmap.Canvas.EndScene; end; end; finally QRCode.Free; end; end; Vai que sirva pra alguem funcionou todos os bancos. E qualidade ficou otima! Agora funciona desktop e mobile.

Olá PCVALADARES tudo bem? tive este mesmo erro agora pela manhã, mas também tive em outras ocasiões e o que percebi é que se esperar alguns minutos e tentar novamente a nota sai, acho que isto é algum problema do site da prefeitura mas não tenho certeza, gostaria muito que o suporte do ACBr nos desse algum esclarecimento sobre este erro.

rafabarzotto Então é isso amigo....o boleto hibrido PIX Bradesco não está liberado ainda...eles deve ter apenas um projeto piloto....mais nada definitivo....vou tentar solicitar a liberação em produção desse boleto codigo de barras tradicional...porque eles liberaram só em homologação e ainda foi um dificuldade...

Veja que a mensagem mudou: A nota foi recebida pelo web service e aparentemente aceita. No entanto, ele não devolveu para você um número de protocolo correspondente para a operação. Por favor, faça o seguinte procedimento: Aguarde alguns instantes(apenas para ter certeza) e consulte esta nota. Como ele não te devolveu um número de protocolo ou de recibo, consulte direto pela chave dela mesmo usando o comando NFe.ConsultarNFe; Se ele devolver uma mensagem um retorno positivo, então a nota foi aceita. Agora se ele devolver um retorno negativo, consulte direto no site da sefaz apenas para ter certeza. Tendo esta nota sido emitida ou rejeitada, como a Sefaz está devolvendo o número do protocolo em branco, me parece que estão com problemas no processo de emissão assíncrono. Por isso, se possível, faça um teste de envio de forma síncrona. Para isso, atente-se ao parâmetro bSincrono do comando de envio que estiver usando, seja ele o NFe.CriarEnviarNFe ou o NFe.EnviarNFe

Isso parece ser um problema diferente... algo do lado da Sefaz MG não está com a contingência ligada ?

Bom dia! Foi gerada nova compilação do ACBrMonitor com alteração visando corrigir esta questão. Por favor, queira atualizar e realizara novo teste.

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

Bom dia. Tivemos o mesmo problema. Os arquivos xml não estavam com autorização de uso (tag protNFe). Entretanto, consultávamos na sefaz e as notas estavam lá autorizadas. Utilizamos ACBrMonitor. Enviávamos o comando NFe.EnviarNFe("nome_do_arquivo", lote, 0, 0). Há alguns anos fazíamos assim. Mas ontem começou a falhar nos clientes. Atualizei o ACBr mas o problema persistiu. Mudei o comando para: NFe.EnviarNFe("nome_do_arquivo", lote, 0, 0, 0, 1) E deu certo. O quinto parâmetro (1: modo síncrono) Sefaz MG

Ok, Muito Obrigado! fico no aguardo

Bom dia @[email protected], Você notou que ao usar os Schemas corretos que são os que esta no SVN com o arquivo GINFES.ini correto que é o que esta no SVN o Lote de RPS foi enviado e o webservice lhe informa que o Lote esta na fila de processamento. Por outro lado ao fazer a alteração de Schemas e no arquivo GINFES.ini o lote de RPS foi rejeitado pelo simples fato do XML estar fora do layout esperado. Acabei de fazer um teste de envio de um lote de RPS para a cidade de Santos/SP usando o programa exemplo do novo componente: ------------------------------ Versão OpenSSL OpenSSL 3.1.3 19 Sep 2023 03.01.00.030 C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libcrypto-3.dll C:\ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\libssl-3.dll ------------------------------ Requisição Ambiente : 2 Cidade : Santos/SP Provedor : Ginfes Versão: 1.00 Data/Hora: 14/03/2024 10:16:09 Método Executado: Enviar Lote Assíncrono Parâmetros de Envio Numero do Lote: 1 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : E45 Mensagem: CNPJ não encontrado na base de dados Correção: Confira o numero do CNPJ informado. Caso esteja correto, o prestador não está inscrito no município. Como você pode ver o Lote foi recepcionado pelo webservice, mas foi recusado pelo fato do CNPJ informado não é de nenhum prestador da cidade de Santos e não pelo layout estar fora do esperado. Agora lhe pergunto: qual é o correto, os schemas que nós disponibilizamos ou esses outros?

TK-5209

Bm Dia Italo, Sim. Colocamos sempre a opção 9(no momento até nova versão). após apenas colocaremos quando combustiveis. Muito obrigado, Abraço

Bom dia @ALCENIR COSTA, O campo motRedAdRem só aceita os valores 1 = Transporte Coletivo ou 9 = Outros, qualquer outro valor atribuído a este campo é invalido.

Bom dia @DATAC, Uma pequena retificação da informação passada pelo o @Diego Foliene. O campo motRedAdRem só aceita os valores 1 = Transporte Coletivo ou 9 = Outros, qualquer outro valor atribuído a este campo é invalido.

parece ser lá a situação mas em todo o caso baixar os schemas e atualiza mas MG é problema

Bom dia. para esse caso tu tem que alterar o ini de configuração e mandar ler ele em cada empresa para funcionar. tu altera o ini com as configuraçõe e dai faz a leitura https://acbr.sourceforge.io/ACBrMonitor/ACBrlerini.html

Tente mudar as configurações para OpenSSL. Teste com o programa de exemplo para verificar se existe algo de errado na sua aplicação. Se sua consulta não retorna registros o InfCad[0] não existe e dessa forma você está gerando o AV. Verifique se o índice existe antes de tentar acessar.

Faltou configurar o certificado digital.

@Juliomar Marchetti já realizou várias homologações em conjunto com a PayGo

@Sistemas Drogal Quando for possível, atualize, veja se ainda esta com erro

Revise suas configurações de SSL/TLS e certificado, conforme tópico a seguir.

confere o manual do provedor dai conseguimos saber

Sim, mas depurando a rotina, verificamos apenas que a criptografia da senha estava removendo o caractere '.' da senha, ocasionando o problema no envio do e-mail. Agradeço a atenção.

Obrigado Italo, vou testar e retorno aqui.

Certo então tentem entrar em contato com o sefaz para ver o porque não foi habilitado. acho que esse é o caminho a ser tomado

@[email protected], Você não precisa usar esse método GravarXml. O componente se encarrega de salvar o XML do RPS no momento correto, ou seja, após ele ter sido gerado, assinado se assim o provedor exige. O componente cria uma pasta chamada Recibos e salva os XML dos RPS dentro dessa pasta e a pasta Notas para salvar os XMLs das NFS-e. Você só tem que configurar o componente e deixar o resto por conta dele. Note que o programa exemplo não se utiliza do método GravarXml, alias o único gravar que você vai encontrar é o GravarConfiguracao.

Bom dia @Datacamp, Alterei o programa exemplo incluindo um botão para exemplificar o Cancelamento de Insucesso de Entrega. Fiz um teste e o XML gerado e enviado para a SEFAZ foi esse: Abaixo o retorno da SEFAZ: Essa rejeição da SEFAZ é aceitável uma vez que enviei uma chave de CT-e valida mas cujo CTe não foi enviado para a SEFAZ, outra coisa o teste foi feito em ambiente de homologação, além disso informei o numero de protocolo de autorização do CT-e e de autorização do evento de Insucesso de entrega iguais e inválidos. Enfim, o componente esta gerando corretamente o evento de pedido de cancelamento de insucesso de entrega. Vou enviar para o SVN essa alteração que fiz no programa exemplo feito em Delphi.

Sim, SEFAZ/MG só problema!!!