douglaswf

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...

Boa tarde! Hoje fui atualizar o ACBR e recebo erro ao tentar instalar com a versão 13746. com a versão 14640 isso nao ocorre. O erro é na hora de compilar o ACBR_Comum: C:\Dropbox\Trunk2\Fontes\ACBrComum\ACBrCompress.pas(48) Fatal: F2613 Unit 'GZIPUtils' not found. Não sei onde é o lugar correto pra postar este caso, então peço perdão caso não seja aqui.

Sim. Na verdade quando vocÊ manifesta é gerado um novo NSU com o XML completo. não é exatamente um Download como no modelo antigo. E isso só acontece via manifestação.

Note que na mesma nota técnica tem uma citação que não pode haver lacunas. Considerando que o Ambiente Nacional gera NSU sem lacunas, o processo de distribuição de conjunto de DF-e a partir do NSU informado (tag:distNSU) disponibiliza para o interessado uma sequência de numeração ordenada de forma ascendente. A identificação de alguma lacuna na base de dados do interessado indica que houve alguma falha no processo de distribuição dos documentos. Eu já abri um chamado no CSS do Serpro, mas seria interessante quem notar o problema fazer o mesmo pra dar peso lá.... O endereço é: http://serpro.gov.br/menu/suporte1/especificos/sped

Sim, como isso vem afetando a identificação, fiz uma alteração e mesmo que eu receba 137, se o MaxNSU for maior, eu incremento a busca de um em um até chegar no MaxNSU. Assim pelo menos o processo vai indo aos poucos, pegando a maioria da movimentação. Tbm nunca vi isso antes. Sempre que alguma NF não vinha logo, vinha depois com um NSU da sequencia, mas nunca assim...

Acho que nao é limitação de download, pois se fosse, nao deveria pular a numeração. E quanto a esse limite, ele era pro método antigo. No distribuicaoDFe diz que se fazer ciencia, vai receber um NSU com a nota completa sem exceção.

@Italo Jurisato Junior , da uma olhada nesse retorno... Eu chamei o distribuicaoDFe com o ultimo NSU que tinha. Ele me retornou que não tinham mais documentos, mas o MaxNSU é beeeeem maior que o UltNSU. <?xml version="1.0"?> <retDistDFeInt xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.01" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <tpAmb>1</tpAmb> <verAplic>1.1.9</verAplic> <cStat>137</cStat> <xMotivo>Nenhum documento localizado</xMotivo> <dhResp>2017-08-16T10:57:14-03:00</dhResp> <ultNSU>000000000558186</ultNSU> <maxNSU>000000000559912</maxNSU> </retDistDFeInt>