jek

Ítalo, pelo menos 4 desses desenvolvedores que postaram aqui (eu incluso) afirmaram que já abriram um chamado na SEFAZ de SP relatando este problema. E nos chamados que abri hoje, incluí um link para este tópico, com a esperança de que isso abra o olho deles de que é um problema grave e que está afetando diversos contribuintes do Estado de SP. Além disso, há detalhes que foram expostos neste tópico sobre este problema (por exemplo: só acontece com CT-e's emitidos na versão 2.00, acontece apenas em SP, em MG, se aconteceu, já está resolvido), com certeza deve ter ajudado muito mais gente do que apenas os que se manifestaram aqui de alguma forma. Entendo que um dos principais benefícios de um fórum é a troca de ideias e informações, e é isso que estamos fazendo aqui. Se ninguém tivesse se manifestado e apenas seguissem esta "recomendação" de guardar para si os problemas e entrar em contato individualmente com a SEFAZ, quantos estariam perdendo tempo olhando código, fazendo testes, apenas para descobrir o que nós já constatamos aqui?

Discordo totalmente da sua visão, acho bem importante que este tipo de informação seja compartilhada, eliminando possíveis dúvidas que o problema seja culpa do próprio código, tanto do ACBr ou do sistema de cada um. Para os demais interessados no assunto: o problema ainda persiste (testado em ambiente de Produção há poucos minutos), já abrimos vários chamados na SEFAZ de SP desde a semana passada, mas até agora não obtivemos nenhum retorno.

Ítalo, sei que o resultado final é o mesmo, mas entendo que a sugestão enviada pelo BigWings é melhor do que o commit revisão 14006 na questão de organização do código, onde ele colocou no constructor do TIde a inicialização do FindGlobalizado e constructor do TInfCteSub a inicialização do FindAlteraToma. E considerando a explicação do BigWings sobre o uso da diretiva default, elas poderiam ser removidas do código também, já que não são propriedades que podem ser setadas no DFM.

Ítalo, Vi que esta alteração é referente ao commit revisão 13942, mas mesmo com este default declarado, após a inicialização o valor padrão continua sendo "tiSim". Tentei reinstalar todo o ACBr, apaguei as DCUs, mas não tem jeito... e suspeito que esta declaração não funciona, pois acontece exatamente o mesmo comportamento com a propriedade indAlteraToma do TInfCteSub (que está declarada como "default tiNao" também desde a revisão 13986). Por fim, fiz um teste criando um novo tipo T_Indicador e mudando a declaração do FindGlobalizado para ele, e constatei que o que influencia o valor padrão é a ordem em que os valores deste tipo são declarados, pois é sempre considerado o primeiro valor: Se T_Indicador = (ti_Sim, ti_Nao), o default é ti_Sim Se T_Indicador = (ti_Nao, ti_Sim), o default é ti_Nao Não sei se estou me perdendo em alguma coisa aqui (e se for o caso, há uma solução?), mas peço por favor que verifique esta questão. Obs: testado no Delphi 10.1 Berlin

Ítalo, obrigado pela informação, não conhecia este Boletim Técnico 2012/001. Até procurei por um site oficial com estes boletins, para ver se há outros, mas não encontrei nada... sabe se existe? Interessante também que a Portaria CAT 121/2013 não faz menção ao termo "CT-e Globalizado", e comparando com o Boletim, parece ser um pouco menos burocrático, sem a necessidade do regime especial concedido pela UF;

Boa tarde, Ítalo! Sim, esta era uma operação de transferência de um CD para outro, depois que foi realizada a distribuição entre os destinatários finais, com emissões individuais de CT-e's. Mas mesmo se fosse para diversos destinatários, existe a Portaria CAT 121 de 29/11/2013 que regulamenta este tipo de operação, quando há apenas um tomador do frete, aí no lugar do nome do destinatário seria enviado "Diversos", com o CNPJ da Transportadora.

Aparentemente voltou ao normal, acabei de fazer uma emissão em homologação, usando exatamente o mesmo documento que estava recebendo o erro "999 - Falha no processo de validacao MDF-e". Encerramento também funcionou em homologação.

Confirmado, fiz uma emissão de CT-e com Simples Nacional pra Pernambuco (que usa o SVC-SP) e aceitou, está corrigido mesmo.

sandraexvi, este problema está acontecendo apenas na SEFAZ de São Paulo, e no ambiente de Homologação. O motivo é que na primeira liberação dos schemas da NT 2015.004, foi incluída uma regra indevida em cima do Simples Nacional. O Portal Nacional já enviou uma correção destes schemas - observe no site que está escrito ao lado do link "(Atualizado em 30/11/2015)" - mas, além de não anunciarem nada sobre esta correção, a SEFAZ de São Paulo também esqueceu de atualizar o ambiente de homologação. O jeito é reclamar lá com o pessoal de São Paulo, ou aguardar que eles mesmos descubram a falha e atualizem os schemas.

Uma dúvida sobre este tema: existe uma razão específica para que não seja efetuada a impressão das Observações do Contribuinte no DACTE quando o modal é Aéreo? Esta regra foi colocada na revisão 2823 pelo Ítalo, e permanece até hoje no ACBr. Infelizmente não há nenhuma mensagem no log do SVN sobre o commit... Para agilizar, estou me referindo a este bloco de código aqui no procedimento TfrmDACTeQRRetrato.qrb_16_DadosExcEmitenteBeforePrint da unit ACBrCTeDACTeQRRetrato.pas if FCTe.Ide.modal <> mdAereo then begin for i := 0 to (FCTe.Compl.ObsCont.Count-1) do with FCTe.Compl.ObsCont.Items do begin qrmObsExcEmitente.Lines.Add( StringReplace( xCampo, '&lt;BR&gt;', #13#10, [rfReplaceAll,rfIgnoreCase] )+': '+ StringReplace( xTexto, '&lt;BR&gt;', #13#10, [rfReplaceAll,rfIgnoreCase] ) ); end; end; Obs: me desculpe por ressuscitar este tópico antigo, mas como o código é ainda mais velho, achei que seria melhor reusá-lo...

Blz, vi a alteração na revisão 6101, obrigado!

Turbo Drive, muito obrigado por ter postado aqui a solução para este problema! Temos um cliente do Pará que precisou cancelar uma MDF-e, e estava ocorrendo a mesma rejeição 226: Código da UF do Emitente diverge da UF autorizadora, e o problema estava exatamente na função TInfEvento.getcOrgao da pmdfeEventoMDFe.pas, que inclui o Pará nesta regra do SVAN. Removi a regra e pimba, MDF-e cancelada com sucesso (ambiente de Produção)! --- Ítalo e demais colaboradores do projeto: não encontrei nenhuma referência sobre esta regra de enviar o código 91 para as UFs ES, MA, PA, Pi e RN na documentação da MDF-e. Não vou conseguir testar para as demais UFs, mas como não encontrei nenhuma menção sobre isso, acredito que a regra toda deva ser removida, ficando apenas: function TInfEvento.getcOrgao: integer; // (AC,AL,AP,AM,BA,CE,DF,ES,GO,MA,MT,MS,MG,PA,PB,PR,PE,PI,RJ,RN,RS,RO,RR,SC,SP,SE,TO); // (12,27,16,13,29,23,53,32,52,21,51,50,31,15,25,41,26,22,33,24,43,11,14,42,35,28,17); begin Result := StrToInt(copy(FChave, 1, 2)); end;

Adaílson, pelo que entendemos, a SEFAZ não permite gerar um MDF-e com descargas em UF's distintas. Mesmo declarando o percurso como você fez no seu exemplo, você não pode ter no mesmo Manifesto uma descarga na Bahia e outra no Pará, declarando que o destino final é no Pará. Neste caso, entendemos que a ideia deles é que seja emitido uma outra MDF-e específica entre SP e BA. Devido a esta regra, colocamos uma trava no nosso sistema para não permitir este tipo de operação.

Nisso eu concordo com você, é bem melhor ter vários tópicos do uma única bomba misturando tudo. E você há de concordar comigo que chegou a hora de ser criado um subfórum específico do MDF-e, para não ficar misturando aqui no subfórum do CT-e!

Caro EMBarbosa, entendo que este é um tópico único sobre o MDF-e, portanto o questionamento do Ariel é pertinente a este assunto, sem a necessidade de criar um novo tópico. Ariel, utilize a versão anterior dos schemas mesmo. Esta mudança da tag veicPrincipal para veicTracao não está documentada na NT 02.2013, apenas na parte de notícias do site da SEFAZ RS: https://mdfe-portal.sefaz.rs.gov.br/Site/Noticias Teoricamente, esta alteração deveria estar em vigor a partir de hoje em ambiente de Homologação, mas estamos conseguindo emitir os MDF-e's usando o schema anterior... É possível emitir usando o schema novo renomeando as tags no procedimento GerarRodo da unit pmdfeMDFeW.pas, mas como esta mudança só entrará em Produção em 01/07/2013, e não temos como testar a emissão neste ambiente, não sei se é correto fazer esta modificação neste momento.

Pois, para falar a verdade, aproveitei o tópico pontualmente porque é exatamente o mesmo problema (o atributo de identificação não ser "Id") que encontramos na implementação da Carta Frete Eletrônica da NDDigital. Por isso gostaria de saber se alguém já achou uma solução para esta questão, independente de ser na NFS-e ou em outro lugar.

Boa tarde, pessoal! Nos deparamos com este mesmo problema, no XSD que precisamos enviar, o atributo é "ID" ao invés de seguir o padrão W3C, "Id", e com isso não conseguimos assinar o XML nem por OpenSSL ou CAPICOM. Alguém já conseguiu resolver este problema?

Estranho... tivemos este problema com um novo cliente de Pernambuco, e precisamos alterar o ACBr para usar o webservice de SP, o fonte atual ainda está apontando para a Sefaz Virtual RS (unit ACBrCTeUtil.pas, revisão 3267 do Ítalo) Se alguém precisar modificar ou quiserem adicionar ao fonte oficial, a alteração é apenas isso na função GetURL: 26: Result := CTeUtil.GetURLSP(AAmbiente, ALayOut);

Ítalo, conseguimos enviar corretamente uma CL-e pelo componente! O Diego lhe mandará os fontes com as modificações necessárias ainda hoje, e então poderemos finalmente concluir o desenvolvimento do ACBrCLe!