Ramon Valentim

Olá, boa tarde. O cancelamento de NFS-e´s no ambiente nacional para o provedor SimplISS em Blumenau, deve ocorrer através do envio de um evento de solicitação de cancelamento (retirei este código do exemplo do ACBr): Este erro que você apresentou, se não me engano acontece quando tenta cancelar uma NFS-e utilizando o serviço de cancelamento, conforme era antigamente antes da migração para o padrão nacional.

Bom dia! Olhando os logs do ACBr, aparentemente esta atualização ainda não foi disponibilizada no SVN né? Estou com o mesmo problema aqui.

Muito obrigado Danilo. Atualizei agora e o cancelamento começou a funcionar. Revisão 45397 para quem precisar.

Pessoal, boa tarde. De quando é o fonte de vocês do ACBr? Qual é a revisão? Tentei hoje o cancelamento em produção e obtive o mesmo erro: E1235 - Falha no esquema XML do DF-e. Ajuda: The element 'infPedReg' in namespace 'http://www.sped.fazenda.gov.br/nfse' has invalid child element 'e101101' in namespace 'http://www.sped.fazenda.gov.br/nfse'. List of possible elements expected: 'nPedRegEvento' in namespace 'http://www.sped.fazenda.gov.br/nfse'. Como vocês estão fazendo este cancelamento?

O erro acima está acontecendo aqui em Blumenau/SC também. A princípio é problema do SCH no provedor, veja na citação abaixo.

Bom dia. Eu não passei por este erro não. Mas pela experiência que tive com este provedor, eu aguardaria um pouco e tentaria novamente. Normalmente estes erros "sujeitos a mudanças", mudam mesmo

Bom dia. Testei ontem novamente o envio do evento de cancelamento para Blumenau/SC no ambiente de Homologação. Aparentemente o erro mudou. A primeira parte onde dava erro referente ao "Id" sumiu. Alguém conseguiu algo diferente?

O envio e cancelamento utilizando a url antiga + versão 2.03 estão funcionando. O cancelamento ao qual me referi acima é o cancelamento de NFS-e´s enviadas utilizando o Padrão Nacional, na url nova.

No fim do ano passado a SEFAZ alterou o XSD com o tipo de evento de cancelamento. A tag id do evento era composta por 62 dígitos. PRE + chave NFSe (50 dígitos) + Tipo do evento (6 dígitos) + nPedRegEvento (3 dígitos) Aparentemente a SEFAZ alterou esse XSD no final do ano para ser composto por 59 dígitos (retirando o nPedRegEvento do id): PRE + chave NFSe (50 dígitos) + Tipo do evento (6 dígitos) O ACBr já foi alterado e está gerando o XML com 59 dígitos, mas o XSD de validação lá no provedor ainda está esperando o id com 62, aí gera o erro: Eu conversei com o provedor há umas 2 semanas e me informaram que estavam cientes, que estava na lista de correções deles, mas que não havia uma previsão. Provedor: SimplISS Cidade: Blumenau/SC

Boa tarde. Até semana passada não era possível. Os XSD´s do provedor estavam desatualizados. Durante essa semana retornarei à esse assunto e farei um teste novamente. Se houver alguma novidade aviso aqui.

Conversei com o suporte do provedor. Aparentemente, estes são erros internos do provedor, em breve liberarão as correções.

Boa tarde. Apenas para informar, já entendi o que está acontecendo por aqui. O provedor está com os schemas desatualizados.

Boa tarde. Testei agora e voltou a apresentar erro mesmo. Estou testando em homologação. Até ontem no início da tarde ainda estava funcionando.

Bom dia. @Italo Giurizzato Junior, vi no SVN que o arquivo ACBrNFSeXServicos.ini foi unificado, mas faltou um ajuste para que Blumenau/SC funcione enviando considerando a reforma tributária. [4202404] Nome=Blumenau UF=SC Provedor=SimplISS ;ProRecepcionar= Versao=1.01 Params=APIPropria:|PN: ProRecepcionar=https://nfseblumenau.simplissweb.com.br HomRecepcionar=https://producaorestrita.simplissweb.com.br Obrigado!

Boa tarde. Você conseguiu efetuar o cancelamento? Estou tentando por aqui e tendo o mesmo retorno que você: { "erro": { "codigo": "E1235", "descricao": "Falha no esquema XML do DF-e.", "complemento": "The 'Id' attribute is invalid - The value 'PRE42024041281814873000130000000000000526016673005434101101' is invalid according to its datatype 'http://www.sped.fazenda.gov.br/nfse:TSIdPedRefEvt' - The Pattern constraint failed.\nThe element 'infPedReg' in namespace 'http://www.sped.fazenda.gov.br/nfse' has invalid child element 'e101101' in namespace 'http://www.sped.fazenda.gov.br/nfse'. List of possible elements expected: 'nPedRegEvento' in namespace 'http://www.sped.fazenda.gov.br/nfse'." }, "tipoAmbiente": 2, "versaoAplicativo": "SimplissWs_v1.0.0", "dataHoraProcessamento": "2026-01-12T15:07:03.8001199-03:00" } Atualizei o ACBr e os schemas agora no início da tarde.

Alguém conseguiu cancelar NFS-e em Blumenau?

Além do .ini, você precisa alterar também os arquivos schema. No meu código, eu controlo também quando preencher os campos da reforma. Aí quando é para API antiga, uso os schemas do abrasf 2.03, ini como o que você tem e não preencho os campos da reforma. Para a API nova, uso os schemas novos, ini mirando na nova URL e preenchendo os campos da reforma.

Você chegou a trocar os XSD´s? São diferentes entre as API´s.

Na hora que vai montar a série, o ACBr coloca "0" à esquerda. Na hora que vai montar o XML, não. É por isso que fica certo na chave e no XML não.

Sim, era este erro que estava gerando. Você precisa informar um valor com 5 dígitos, mas o ACBr trata como inteiro. Então não pode iniciar como 0 (pelo menos por enquanto). Exemplo: 00000 virá 0 no XML. 10000 fica 10000 no XML.

O local eu já localizei. PadraoNacional.GravarXml.pas Seria alterar para utilizar o tcStr e um Poem_Zeros que no próprio fonte já utiliza. A questão é se isso não teria um impacto maior em outros provedores. Acho estanho porque não vi ninguém reclamando disso. Será que teria alguém do próprio ACBr que poderia nos auxiliar?

Bom dia. Consegui emitir para a produção também, só que informando a série "10012" (dentro do nosso sistema é 12). "00012" não funcionou porque o ACBr trata como integer na hora de montar o XML da DPS. Vocês não acham que seria o caso de ajustarmos fonte do ACBr para tratar como string e adicionar os 0 à esquerda? Olhando o que diz no layout, deveria aceitar o "0" à frente.

Pelo ambiente de produção a emissão mudou mesmo. Agora tive o retorno do erro: "A série informada no identificador da DPS não corresponde à série da DPS. Ajuda: Este erro está em processo de validação interna e por isso ainda não possui um código está sujeito a mudanças." Olhando dentro do ACBr, vi que para colocar na "chave do DPS", ele insere "0" à frente até ficar com 5 casas. No entanto, para montar o XML ele trata a série como int. Para conseguir emitir, foi você que "forçou" ela para ficar com 5 casas decimais (colocando o 1 na frente)? Ou isso é alguma configuração extra do componente? Obrigado pela ajuda.

Obrigado. Vou testar em produção para ver se tenho um retorno diferente.

Boa tarde. Emitindo em homologação, estou com o mesmo problema. Ao amigos que conseguiram, poderiam compartilhar o XML, para compararmos com os nossos e ver o que está faltando preencher? Obrigado!