douglaswf

Bom dia! Estou conseguindo enviar o evento de prestação de serviço em desacordo normalmente faz um bom tempo. Porém, nunca tinha enviado para o estado do MT (51). Quando estou tentando enviar esse evento para CTes emitidos no MT recebo o erro 632 (Rejeição: O autor do evento diverge do emissor do CT-e). No caso, eu sou o TOMADOR e realmente eu não sou o Emissor, pois é um evento de desacordo com a emisssão. Entrei em contato com o SEFAZ MT a alguns dias. Me pediram os XMLs para análise, mas ainda não me deram resposta. Alguém aí está conseguindo ou já conseguiu enviar esse evento pro MT alguma vez?

Leandro, agora acho que todos os eventos estão tratados. Atualizei o Trunk hoje e não recebo mais o erro naquele evento de MFDe. Pode validar por aí tambem? @italojr_87, obrigado pela ajuda!

O evento de prestação em desacordo é enviado sim para a Sefaz de Origem do documento, e não do tomador. Isto está no manual. Eu estou usando o serviço normalmente. Como você faz pra definir o destino do evento?

Conferi os eventos e achei essa lista aqui sem tratamento: @italojr_87 e Leandro, eu fiz testes com documentos com esses eventos e tive sucesso. Porém, o erro que o Leandro reporta na chave 51180414199898000264570010000150911000123732 acontece ainda, mas eu não encontrei a razão. Esse erro é algo que já deveria acontecer antes (na minha opinião), mas passava em branco pois não tinha esse tratamento pra dar exception quando não encontrar um evento. pcteEventoCTe.pas pcnConversao.pas

Achei mais alguns eventos que não estão cadastrados. Estou conferindo o que está tratado e o que falta e em seguida posto o tratamento pra incluir todos os eventos de uma vez só.

Consultei essa chave e realmente deu erro com esse evento que você comentou. Não entendi o porque. O XML do evento está em anexo: xml.xml

O evento não tratado é o evento de "Autorizado CTe Complementar" (240130). Fiz o tratamento para tratar o evento nos fontes abaixo e testei. Se mais alguém puder testar, para que os moderadores possam aplicar a alteração. pcteEventoCTe.pas pcnConversao.pas

Bom dia! Durante a tarde de ontem e hoje pela manhã estou sofrendo tentando enviar ciencia e confirmação das operações. Recebo erro não catalogado (999) como retorno. Queria apenas um feedback de como está o serviço com os demais. Alguém está conseguindo fazer as manifestações normalmente? grato, Franciscon

Ítalo, testei tudo e funcionou perfeitamente. Obrigado pelo retorno...

Bom dia pessoal! Estou gerando alguns eventos de "Prestação de Serviço em Desacordo" e acho que tem um equívoco no tratamento do retorno desse evento. Notem na imagem abaixo que se o retorno não for 134, 135 ou 136 ele vai retornar "false" na função. Isso gera um except que faz com que o retorno do evento não seja preenchido. Se eu tentar enviar esse evento pra um CTe com mais de 45 dias, ao inves dele me retornar as informações no objeto, ele só gera a except e nao consigo pegar as informações. Esse tratamento é diferente da NFe, que considera isso. Outra coisa que notei é que no retorno vindo do SEFAZ não tem (isso mesmo, não tem a chave) Segunda imagem. Como não tem chave, mesmo tratando a primeira correção, ele não gera o retorno corretamente por causa desse IF que testa a chave. Não tentei fazer uma correção pois não tenho certeza que meu entendimento está correto, e como tem outros eventos que podem usar a mesma rotina, não sei se é simples de tratar isso.

Boa tarde! Eu notei que o tratamento para a propriedade NFSe.Servico.CodigoMunicipio no padrão ABRASF_V1 é diferente na leitura da RPS e da NFSe. No LerRPS_ABRASF_V1 o conteúdo vem do campo XML 'MunicipioPrestacaoServico' NFSe.Servico.CodigoTributacaoMunicipio := Leitor.rCampo(tcStr, 'CodigoTributacaoMunicipio'); NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'MunicipioPrestacaoServico'); if NFSe.Servico.CodigoMunicipio = '' then NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoMunicipio'); No LerNFSe_ABRASF_V1 NFSe.Servico.CodigoTributacaoMunicipio := Leitor.rCampo(tcStr, 'CodigoTributacaoMunicipio'); if FProvedor = proISSNet then NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoTributacaoMunicipio') Else NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoMunicipio'); Ou seja, pega o mesmo conteúdo da TAG 'CodigoTributacaoMunicipio' ao invés da 'MunicipioPrestacaoServico'. Como eu uso só a impriessão de DANFSe dos XMLs de empresas que recebo de Cuiabá, notei que desse modo o Município em que o serviço foi prestado não aparece impresso. Alguém consegue validar se isso é correto, pois no meu modo de ver, o correto é como é no LerRPS. Me parece que o correto ficaria assim: NFSe.Servico.CodigoTributacaoMunicipio := Leitor.rCampo(tcStr, 'CodigoTributacaoMunicipio'); if FProvedor = proISSNet then Begin NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'MunicipioPrestacaoServico'); if NFSe.Servico.CodigoMunicipio = '' then NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoMunicipio'); End Else NFSe.Servico.CodigoMunicipio := Leitor.rCampo(tcStr, 'CodigoMunicipio');

Pode ser a versão da NFe configurada no compomente. <dEmi> é bem antigo. agora é <dhEmi> pelo que lembro.

Certo... você tem 2 patchs no componente. o .PathNFe e o .PathSalvar. Note que tem tambem a propriedade .Salvar. Se ela estiver False, não vai gravar nada. Mas, se você já está vendo o xml dentro do compomente, e está sofrendo em configurar ele pra salvar direto, cria uma Stringlist, atribui o conteúdo do XML nela e da um SaveToFile.

mas eles não terão valor fiscal, pois o Digest deles será diferente do que foi assinado e registrado no Sefaz. Se for só pra ter o XML tudo bem, mas se for pra guardá-los pra algum processo fiscal, recriar eles assim não adianta. No caso dele não... note que ele está falando dos xmls emitidos dele...

Qual o objetivo de conseguir esses xmls?

Você não está fazendo a Ciencia da Operação após já ter dado uma confirmação ou desconhecimento?

Boa tarde! Gostaria fazer minhas considerações também... Gostaria e pretendo assinar o SAC. Não o fiz ainda por achar que ele é um pouco caro pra o que eu uso. Talvez pra quem usa o ACBR na integra, seja um valor baixo (eu diria de graça), mas pra mim, é um pouco fora. Eu uso o ACBR apenar pra ler os XMLs e extrair as informações alem do DistribuicaoDFe. Não gero NFe, não autorizo, não imprimo DANFE nada. Devido a isso não consigo contribuir com muita coisa fora dessas rotinas que eu uso. Nas rotinas que eu uso, sempre testo e reporto problemas ou dificuldades nesses processos. Minha sugestão seria: Quem sabe ter uma opção onde o valor mensal seja menor, e seja cobrado um valor pelo tempo de atendimento seja um caminho. Quando ao Fórum, Como sugestão: Impedir responder tópicos muito antigos (tipo 3 meses atras). Isso impede que o novato chegue, e pegue carona num assunto morto, e comece uma nova discussão. Posts abertos em duplicidade poderiam ser "aglutinados" ? Não sei se a ferramenta tem esse recurso. (Isso evitaria 50% das rudezas). Notem que num mesmo dia as vezes temos 3 posts falando de problemas com manifestação do destinatário por exemplo. Um release semanal ou quinzenal com as alterações (será que da pra extrair no GitHub?) com uma frase que diga o que foi alterado seria um ótimo jeito de motivar os usuários a testar. Assim eu poderia ajudar mais, testando o que foi alterado e não tudo o que eu uso. Se isso existe hoje, me perdoem pois eu não conheço. Já notei varias pancadas pra lá e pra cá. Algumas delas, eu acho que não são totalmente sem razão. Tem muito post de usuário que criou a conta ontem e fez o primeiro post pedindo como faz pra fazer o download do XML, exemplo pronto de como gerar nota na versão x, etc.... Esses deveriam ter mais vontade e correr atras de documentação antes de sair querendo tudo pronto. Mas também já vi muitos casos onde o tratamento dado foi desnecessário e exagerado sim. As demais sugestões que vi no vídeo do @Daniel Simoes (Criar DLL, Webinar, etc...) acho ótimas e seriam de grande valia para todos.

Cara esse assunto é bem complexo e tem dezenas (senão centenas) de posts aqui no forum. Como ponto de partida (Já que você está querendo fazer um teste primeiro) é ler com atenção a Nota Técnica 2014/002. http://www.nfe.fazenda.gov.br/PORTAL/exibirArquivo.aspx?conteudo=VcEhGZODuo4= Se ler ela com cuidado vai entender tudo e vai fazer com certa facilidade... Exemplo Pronto, acho que nao tem no forum...

O retorno "oficial" que tenho é um chamado no Sefaz (em anexo). Eu passei a considerar que o que pulou, se consultar só ele e retornar 137, nunca mais receberá.

Eudis, por curiosidade. Sefaz de qual estado? Grrato...

@josenildo.bandeira conseguiu contornar o caso?

Você repete enquanto o ultnsu seja menor que o maxnsu ou até que receba 137? Se sim, pode ser o caso que eu tiver aqui. No meu caso o sefaz "SUMIU" COM 60 NSUS de uma vez, e dai eu recebia um retorno sem nenhum NSU com o cstat = 137. Dai o meu while parava ai, mesmo tendo mais NSUs. Qual teu MaxNSU e qual teu UltNSU? Se quer testar pra ver se é mesmo que meu caso, muda o fonte pra fazer o While enquanto o UltNsu < MaxNSU. Não olha se é cStat 137 só pra testar.

Você chamava o método DistribuicaoDFe em um while ou repeat? Qual a condição que usa pra sair da repetição?

Leandro, recebi uma resposta do chamado. A posição foi de que o NSU realmente não deve pular, porém, como o Sefaz não é livre de falhas, caso ele salte, o NSU não será mais reaproveitado. Nesse caso, deve-se confirmar se realmente o retorno daquele NSU faltante vai ser 137 e ignorar ele. Achei meio "mal-feito" pois, eles podiam de algum modo retornar outra coisa, pra não confundir isso.a tambem. Não sei se é um problema que o Sefaz vem passando ou se estão usando esse NSU pra outra coisa que não aparece pra nós, mas eu revisei o meu processo e quando pego esse salto eu gero uma linha no BD pra que não fique o salto e ter um histórico disso lá. Depois dessa resposta do Serpro, li e reli a NT2014.002_v1.02b_WsNFeDistribuicaoDFe na parte citada por tí, e passei a entender dessa forma.

Pra mim funcionou... Tudo certo...