francinaldoac

Bom dia! Com o fim do envio da MDF-e em modo assíncrono, haverá alguma mudança no envio dos eventos da MDF-e ou eles já estão no modo síncrono?

Eu já resolvi fazendo isso LFill(NUM_ACDRAW). Estou apenas reportando para o componente ser corrigido. Obrigado.

Bom dia, Tem um problema no registro C120, o campo NUM_ACDRAW é opcional e do tipo string, quando ele não é informado no registro, o componente está fazendo o preenchimento com zeros até o limite do tamanho do campo, isso causa erro no validador. Detectei que o problema reside no método "WriteRegistroC120" do código abaixo que está no arquivo ACBrEPCBloco_C_Class.pas : procedure TBloco_C.WriteRegistroC120(RegC100: TRegistroC100); var intFor: integer; strCOD_DOC_IMP: string; begin if Assigned(RegC100.RegistroC120) then begin for intFor := 0 to RegC100.RegistroC120.Count - 1 do begin with RegC100.RegistroC120.Items[intFor] do begin case COD_DOC_IMP of diImportacao : strCOD_DOC_IMP := '0'; diSimplificadaImport : strCOD_DOC_IMP := '1'; end; Add( LFill('C120') + LFill(strCOD_DOC_IMP) + LFill(NUM_DOC__IMP) + LFill(PIS_IMP,0,2) + LFill(COFINS_IMP,0,2) + LFill(NUM_ACDRAW, 20)) ; // RegistroC990.QTD_LIN_C := RegistroC990.QTD_LIN_C + 1; end; end; // Variavél para armazenar a quantidade de registro do tipo. FRegistroC120Count := FRegistroC120Count + RegC100.RegistroC120.Count; end; end; O trecho LFill(NUM_ACDRAW, 20) causa esse comportamento, corrigi fazendo a alteração para LFill(NUM_ACDRAW).

Bom dia! Mesmo problema comigo também, caso alguém tenha alguma informação, favor compartilhar.

As pastas estão separadas, como disse funcionava normalmente há alguns dias, então passou a informar o erro, não houveram mudanças nessa rotina nas últimas semanas, não vi nota técnica com mudanças, por isso resolvi perguntar aqui no fórum se alguém sabia alguma coisa.

Copei os schemas do svn, mesmo assim o erro continua, não fiz mudança nessa rotina nas últimas semanas, nem alterei os schemas, simplesmente começou a dar o erro, há uns dois dias.

Eu também pensei que fosse, já tinha feito isso sem sucesso, por isso abri esse tópico.

Bom dia! Estou com o erro "Cabecalho - Versao do arquivo XML nao suportada.CStat: 239" ao consultar a DistribuicaoDFe do MDFE, usando o método ACBrMDFe.DistribuicaoDFePorUltNSU, isso começou ontem, verificando o portal da MDFe não encontrei mudanças para esse mês, alguém está tendo o mesmo problema?

Boa tarde, Existe algum projeto em andamento para denvolvimento da API, ou isso não está no radar da Acbr? Atualmente os novos das empresas estão sendo desenvolvidos usando a API e não mais o método de troca de arquivos texto.

Juliomar, meu cliente quer apenas enviar promoções para vários clientes ao mesmo tempo, sem lista de transmissão, individualmente, as conversas vão fluir pelo whatsapp web, tendo em vista isso, qual a API mais simples?

Em termos de preços e simplicidade, você daria alguma opinião? No caso o cliente que compra o serviço junto a integradora?

Boa tarde, Eu já havia escutado há uns meses atrás, mas isso já faz mais de um ano, então queria mais uma troca mais prática de experiências com os desenvolvedores do fórum.

Bom dia, Pessoal, andei olhando os posts sobre API whatsapp aqui no fórum e também pesquisando na internet, quero desenvolver uma integração, mas gostaria de saber de quem já desenvolveu, a experiência com essas APIs, já li sobre gupshup, twilio, zenvia, vi também um componente em delphi o "tinject", mas que dizem que pode ocorrer o banimento do número do cliente. Queria poder usar um ambiente de testes desses componentes, mas pelo li até agora apenas a twilio possui um. Existe alguma plataforma brasileira que vocês indicam? Grato.

Alguém sabe se é problema na SEFAZ SP?

Bom dia! Estou com o mesmo problema do colega, o emissor do CTe é de São Paulo, já conferi todos os dados e estou recebendo: "Rejeição: CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital" ao tentar fazer o desacordo.

Bom dia, Ítalo, o usuário não digita o número da MDF-e, ele é gerado sequencialmente de forma automática, nossa rotina é parecida com o procedimento que você falou agora, mas acho que não ficou claro o meu problema, vou resumir. Ao tentar enviar um MDF-e a SEFAZ retornou o erro de duplicação, o que significa que já estava na base, tendo essa resposta nosso sistema faz consulta a chave de acesso, a SEFAZ então retorna o protocolo da autorização, você viu o XML que enviei com tudo OK, autorizado, porém mesmo com o protocolo de autorização, quando consulto essa chave, diz que não consta na base de dados. O que suponho ter acontecido: nosso sistema permite salvar o MDF-e e depois enviar, o usuário pode ter aberto duas instâncias do sistema, aberto o MDF-e nas duas, enviado por uma e depois enviado pela outra instância, acabei de ver que ao contrário da rotina da NF-e do nosso sistema, a rotina da MDF-e não checa se aquele documento foi transmitido enquanto o usuário estava consultando, vou corrigir isso. Bom, já resolvemos o problema enviando novamente, obrigado pela ajuda.

Sim, foi minha aplicação. Fui olhar os XMLs e achei a resposta abaixo: <retConsReciMDFe xmlns="http://www.portalfiscal.inf.br/mdfe" versao="3.00"> <tpAmb>1</tpAmb> <verAplic>RS20220512135344</verAplic> <nRec>249001167830048</nRec> <cStat>104</cStat> <xMotivo>Arquivo processado</xMotivo> <cUF>24</cUF> <protMDFe versao="3.00"> <infProt Id="MDFe270520220902450590"> <tpAmb>1</tpAmb> <verAplic>RS20220512135344</verAplic> <chMDFe>24220508811226000427580010000084631001460735</chMDFe> <dhRecbto>2022-05-27T09:02:45-03:00</dhRecbto> <digVal>rtU+WvetX0FyPDg8mfrGAJXDMdM=</digVal> <cStat>204</cStat> <xMotivo>Rejeição: Duplicidade de MDF-e [nProt:924220000759203][dhAut:2022-05-27T09:02:31-03:00]</xMotivo> </infProt> </protMDFe> </retConsReciMDFe> Existe uma duplicidade, mas meu sistema está programada nos casos de status 204, ignorar a resposta e fazer uma consulta pela chave da MDFe, dessa forma pego o protocolo de autorização. 249001167830048-pro-rec.xml 146071-env-lot.xml

Sim, vou anexar, eu também fiz a consulta diretamente no site do MDF-e usando a chave. 24220508811226000427580010000084631001460735-mdfe.xml

Meu problema é exatamente esse, eu tenho tudo isso, mas na SEFAZ a minha chave não consta na base, como se não tivesse sido transmitido

Bom dia, Sim eu tenho o XML do MDF-e e com o "carimbo" da autorização, veja abaixo (retirei a chave): <protMDFe xmlns="http://www.portalfiscal.inf.br/mdfe" versao="3.00"> <infProt Id="MDFe924220000759203"> <tpAmb>1</tpAmb> <verAplic>RS20220512135344</verAplic> <chMDFe>número omitido.....</chMDFe> <dhRecbto>2022-05-27T09:02:31-03:00</dhRecbto> <nProt>924220000759203</nProt> <digVal>rtU+WvetX0FyPDg8mfrGAJXDMdM=</digVal> <cStat>100</cStat> <xMotivo>Autorizado o uso do MDF-e</xMotivo> </infProt> </protMDFe>

Boa tarde, Alguém já passou pelo problema de ter uma MDFe que foi autorizada normalmente, tenho o protocolo e recibo de autorização, mas quando consulto na SEFAZ, informa que a MDFe não consta na base. O que fazer nesses casos? Estou pensando em tentar transmitir novamente, mas seria bom se houvesse uma forma de consulta pelo número do protocolo para ver o que houve.

Sim, obrigado.

Boa tarde, erro dos dois, tanto o emissor da Nota quanto da SEFAZ, mas no caso da SEFAZ é de lógica também, porque mesmo estando na tag de terceiros, sendo a empresa participante das regras de acesso total ao documento, não devia aplicar a regra de acesso de terceiros, mas tudo bem, pior de tudo que já olhei mais de 10 transportadores de diferentes UFs que emitem MDF-e para nossa empresa, e todos repetem nosso CNPJ na tag AutXML, acho que deve ser um erro de orientação/comunicação da própria SEFAZ para essas empresas.

Obrigado pela informação, verifiquei e realmente também estamos listados na tag AutXML, mas isso seria uma coisa que o sistema da SEFAZ deveria diferenciar, acredito que é um erro de lógica do sistema deles, ora se estou listado com contratante, destinatário, o fato de estar listado também nessa tag não devia inviabilizar o meu acesso completo.

Olhei a NT agora e realmente consta isso lá, mas não faz sentido para nós que somos os contratantes no MDFe, receberemos todos os documentos quando o carga chegar em nossa empresa, não existe sigilo quebrado nesse caso, porque somos os destinatários. Não faz sentido baixar os MDFe sem essa informação, ficou quase inútel esse método de distribuição. Grato pela ajuda.