Note: Tradução para português usando o Google Translator
During our upgrade from NFE 10.0 SP28 to a higher version i.e. NFE 10.0 SP30 + we noticed that SAP has changed the way the validations are carried out especially for special characters "##". Thus when ever we sent out data to SEFAZ it was returning Status Code 225 - Rejeição: Falha no Schema XML do lote de NFe.
Português - Durante nossa atualização do NFE 10.0 SP28 para uma versão superior, ou seja, NFE 10.0 SP30 +, observamos que o SAP mudou a maneira como as validações são realizadas, especialmente para caracteres especiais "##". Assim, sempre que enviamos dados à SEFAZ, ele retornava o Código de Status 225 - Rejeição: Falha no Esquema XML do lote de NFe.
Thus we referred to Knowledge Management 2613668 to see how to handle special characters but no luck.
Based on the KBB 2613668 there is a difference in version 3.1 and 4 layout.(In our case we were already on version 4 of layout)
For the new 4.0 layout if you have a special character like '#', you should inform in table /XNFE/XMLVALID >>> NO_SPEC_CHAR >>> the character ‘#’ directly or the value ‘DEFAULT’, which will remove a predefined set of characters (‘"!@#$%¨&*()_+=-`´`[]~^/?;:.,><’).
We tried this but it was still failing with same error.
After comparing the XML generated in upgraded vs Non-upgraded environments we were able to drill down to two structures where the special character "##" was still being passed to SEFAZ. These are
IF_STRUC - IS_NFE_INFADIC with IF_FIELD INF_AD_FISCO and
IF_STRUC - IT_NFE_DET with IF_FIELD INF_AD_PROD
Português -
Tentamos isso, mas ainda estava falhando com o mesmo erro.
Após comparar o XML gerado em ambientes atualizados e não atualizados, pudemos detalhar duas estruturas nas quais o caractere especial "##" ainda estava sendo passado para a SEFAZ. Esses são
IF_STRUC - IS_NFE_INFADIC com IF_FIELD INF_AD_FISCO e
IF_STRUC - IT_NFE_DET com IF_FIELD INF_AD_PROD
On comparing and analyzing the code time and again we realized that SAP has changed the way it fundamentally performs validations. This change was made as part of Version NFE 10.0 SP30 as document in this link.
But unfortunately this link does not throw much light on what has changed and how it impacts the current validation. Thus, we had to debug and find out for ourselves what changed and going forward what needs to be maintained to ensure that all validations work as they were working before.
Basically, before NFE 10.0 SP30 SAP had logic written around table /XNFE/XMLVALID field DEF_CHAR_SET i.e. if the value is set to X then system will perform ADOPT_CHAR_SET validation which used to take care of "##". But starting SP30 it will not be using /XNFE/XMLVALID-DEF_CHAR_SET. SAP has introduced a new configuration that gives users the flexibility to maintain the structure and fields for which we want the validation to be performed. Find below the code snippet where the change was implemented by SAP.
Português -
Ao comparar e analisar o código uma e outra vez, percebemos que a SAP mudou a maneira como fundamentalmente realiza validações. Essa alteração foi feita como parte da versão NFE 10.0 SP30, como documento neste link.
Infelizmente, esse link não lança muita luz sobre o que mudou e como afeta a validação atual. Portanto, tivemos que depurar e descobrir por nós mesmos o que mudou e o que precisa ser mantido para garantir que todas as validações funcionem como antes.
Basicamente, antes do NFE 10.0 SP30, a SAP tinha a lógica escrita em torno da tabela / XNFE / XMLVALID campo DEF_CHAR_SET, isto é, se o valor for definido como X, o sistema executará a validação ADOPT_CHAR_SET, que costumava "##". Mas, iniciando o SP30, ele não utilizará / XNFE / XMLVALID-DEF_CHAR_SET. A SAP introduziu uma nova configuração que oferece aos usuários a flexibilidade de manter a estrutura e os campos para os quais queremos que a validação seja realizada. Encontre abaixo o snippet de código em que a alteração foi implementada pela SAP.
It's note worthy that table data /XNFE/XMLVALID is provided by SAP and should only be changed on recommendation on SAP or NFE consultant.
To ensure the consistent behavior now projects need to maintain below stated SPRO configuration.
SPRO —> Nota Fiscal Eletrônica -> Outbound —> NF-e → NF-e: Maintain Validation Rules
Here you need to maintain all the validations for which you want to ensure that ADAPT_CHAR_SET validation is performed.
In our case we played it safe and decided that for all the entries for which DEF_CHAR_SET is set to 'X' in table /XNFE/XMLVALID we will maintain a corresponding entry in "Maintain Validation Rule" which technically is table /XNFE/XMLVALIDC (Validation Customizing)
Português -
Vale ressaltar que os dados da tabela / XNFE / XMLVALID são fornecidos pela SAP e devem ser alterados apenas por recomendação do consultor da SAP ou NFE.
Para garantir o comportamento consistente agora, os projetos precisam manter a configuração SPRO declarada abaixo.
SPRO -> Nota Fiscal Eletrônica -> Saída -> NF-e → NF-e: atualizar regras de validação
Aqui você precisa manter todas as validações para as quais deseja garantir que a validação ADAPT_CHAR_SET seja executada.
For all Structure and fields we decided to have ALLOWED_CHAR_SET set to "ASCII".
You have three option for ALLOWED_CHAR_SET i.e.
1. ASCII - all characters in the ASCII character set are permitted.
2. ANSI - all characters in the ANSI character set are permitted.
3. A user-defined sequence of characters - Then only the specified characters will be permitted.
You should review the documentation provided for "NF-e: Maintain Validation Rules" in SPRO. That will help you decide on what value is best for your organization.
I hope this article will save some time for teams in their NFE upgrade journey to Version NFE 10.0 SP30 or higher.
Português -
Você tem três opções para ALLOWED_CHAR_SET, ou seja,
1. ASCII - todos os caracteres no conjunto de caracteres ASCII são permitidos.
2. ANSI - todos os caracteres no conjunto de caracteres ANSI são permitidos.
3. Uma sequência de caracteres definida pelo usuário - Somente os caracteres especificados serão permitidos.
Good Day!
Dia bom!
During our upgrade from NFE 10.0 SP28 to a higher version i.e. NFE 10.0 SP30 + we noticed that SAP has changed the way the validations are carried out especially for special characters "##". Thus when ever we sent out data to SEFAZ it was returning Status Code 225 - Rejeição: Falha no Schema XML do lote de NFe.
Português - Durante nossa atualização do NFE 10.0 SP28 para uma versão superior, ou seja, NFE 10.0 SP30 +, observamos que o SAP mudou a maneira como as validações são realizadas, especialmente para caracteres especiais "##". Assim, sempre que enviamos dados à SEFAZ, ele retornava o Código de Status 225 - Rejeição: Falha no Esquema XML do lote de NFe.
Thus we referred to Knowledge Management 2613668 to see how to handle special characters but no luck.
Based on the KBB 2613668 there is a difference in version 3.1 and 4 layout.(In our case we were already on version 4 of layout)
For the new 4.0 layout if you have a special character like '#', you should inform in table /XNFE/XMLVALID >>> NO_SPEC_CHAR >>> the character ‘#’ directly or the value ‘DEFAULT’, which will remove a predefined set of characters (‘"!@#$%¨&*()_+=-`´`[]~^/?;:.,><’).
We tried this but it was still failing with same error.
After comparing the XML generated in upgraded vs Non-upgraded environments we were able to drill down to two structures where the special character "##" was still being passed to SEFAZ. These are
IF_STRUC - IS_NFE_INFADIC with IF_FIELD INF_AD_FISCO and
IF_STRUC - IT_NFE_DET with IF_FIELD INF_AD_PROD
Português -
Assim, nos referimos à Gestão do conhecimento 2613668 para ver como lidar com caracteres especiais, mas sem sorte.
Com base no KBB 2613668, há uma diferença no layout das versões 3.1 e 4. (No nosso caso, já estávamos na versão 4 do layout)
Com base no KBB 2613668, há uma diferença no layout das versões 3.1 e 4. (No nosso caso, já estávamos na versão 4 do layout)
Para o novo layout 4.0, se você tiver um caractere especial como '#', informe na tabela / XNFE / XMLVALID >>> NO_SPEC_CHAR >>> o caractere '#' diretamente ou o valor 'DEFAULT', que removerá uma predefinição conjunto de caracteres ('"! @ # $% ¨ & * () _ + = -` ´ [[] ~ ^ /?;:.,> <').
Tentamos isso, mas ainda estava falhando com o mesmo erro.
Após comparar o XML gerado em ambientes atualizados e não atualizados, pudemos detalhar duas estruturas nas quais o caractere especial "##" ainda estava sendo passado para a SEFAZ. Esses são
IF_STRUC - IS_NFE_INFADIC com IF_FIELD INF_AD_FISCO e
IF_STRUC - IT_NFE_DET com IF_FIELD INF_AD_PROD
On comparing and analyzing the code time and again we realized that SAP has changed the way it fundamentally performs validations. This change was made as part of Version NFE 10.0 SP30 as document in this link.
But unfortunately this link does not throw much light on what has changed and how it impacts the current validation. Thus, we had to debug and find out for ourselves what changed and going forward what needs to be maintained to ensure that all validations work as they were working before.
Basically, before NFE 10.0 SP30 SAP had logic written around table /XNFE/XMLVALID field DEF_CHAR_SET i.e. if the value is set to X then system will perform ADOPT_CHAR_SET validation which used to take care of "##". But starting SP30 it will not be using /XNFE/XMLVALID-DEF_CHAR_SET. SAP has introduced a new configuration that gives users the flexibility to maintain the structure and fields for which we want the validation to be performed. Find below the code snippet where the change was implemented by SAP.
Português -
Ao comparar e analisar o código uma e outra vez, percebemos que a SAP mudou a maneira como fundamentalmente realiza validações. Essa alteração foi feita como parte da versão NFE 10.0 SP30, como documento neste link.
Infelizmente, esse link não lança muita luz sobre o que mudou e como afeta a validação atual. Portanto, tivemos que depurar e descobrir por nós mesmos o que mudou e o que precisa ser mantido para garantir que todas as validações funcionem como antes.
Basicamente, antes do NFE 10.0 SP30, a SAP tinha a lógica escrita em torno da tabela / XNFE / XMLVALID campo DEF_CHAR_SET, isto é, se o valor for definido como X, o sistema executará a validação ADOPT_CHAR_SET, que costumava "##". Mas, iniciando o SP30, ele não utilizará / XNFE / XMLVALID-DEF_CHAR_SET. A SAP introduziu uma nova configuração que oferece aos usuários a flexibilidade de manter a estrutura e os campos para os quais queremos que a validação seja realizada. Encontre abaixo o snippet de código em que a alteração foi implementada pela SAP.
It's note worthy that table data /XNFE/XMLVALID is provided by SAP and should only be changed on recommendation on SAP or NFE consultant.
To ensure the consistent behavior now projects need to maintain below stated SPRO configuration.
SPRO —> Nota Fiscal Eletrônica -> Outbound —> NF-e → NF-e: Maintain Validation Rules
Here you need to maintain all the validations for which you want to ensure that ADAPT_CHAR_SET validation is performed.
In our case we played it safe and decided that for all the entries for which DEF_CHAR_SET is set to 'X' in table /XNFE/XMLVALID we will maintain a corresponding entry in "Maintain Validation Rule" which technically is table /XNFE/XMLVALIDC (Validation Customizing)
Português -
Vale ressaltar que os dados da tabela / XNFE / XMLVALID são fornecidos pela SAP e devem ser alterados apenas por recomendação do consultor da SAP ou NFE.
Para garantir o comportamento consistente agora, os projetos precisam manter a configuração SPRO declarada abaixo.
SPRO -> Nota Fiscal Eletrônica -> Saída -> NF-e → NF-e: atualizar regras de validação
Aqui você precisa manter todas as validações para as quais deseja garantir que a validação ADAPT_CHAR_SET seja executada.
No nosso caso, jogamos pelo seguro e decidimos que, para todas as entradas para as quais DEF_CHAR_SET está definido como 'X' na tabela / XNFE / XMLVALID, manteremos uma entrada correspondente em "Manter regra de validação", que tecnicamente é a tabela / XNFE / XMLVALIDC ( Customização de validação)
For all Structure and fields we decided to have ALLOWED_CHAR_SET set to "ASCII".
You have three option for ALLOWED_CHAR_SET i.e.
1. ASCII - all characters in the ASCII character set are permitted.
2. ANSI - all characters in the ANSI character set are permitted.
3. A user-defined sequence of characters - Then only the specified characters will be permitted.
You should review the documentation provided for "NF-e: Maintain Validation Rules" in SPRO. That will help you decide on what value is best for your organization.
I hope this article will save some time for teams in their NFE upgrade journey to Version NFE 10.0 SP30 or higher.
Português -
Para toda a estrutura e campos, decidimos ter ALLOWED_CHAR_SET definido como "ASCII".
Você tem três opções para ALLOWED_CHAR_SET, ou seja,
1. ASCII - todos os caracteres no conjunto de caracteres ASCII são permitidos.
2. ANSI - todos os caracteres no conjunto de caracteres ANSI são permitidos.
3. Uma sequência de caracteres definida pelo usuário - Somente os caracteres especificados serão permitidos.
Você deve revisar a documentação fornecida para "NF-e: manter regras de validação" no SPRO. Isso o ajudará a decidir qual o melhor valor para sua organização.
Espero que este artigo economize algum tempo para as equipes em sua jornada de atualização da NFE para a Versão NFE 10.0 SP30 ou superior.
Good Day!
Dia bom!
- SAP Managed Tags:
