Update validator to allow new Brazilian CNPJ alphanumeric format

[rennerocha]

In July-2026, alphanumeric CNPJ will be allowed:
https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/cnpj-alfanumerico

Given that the new format is 100% compatible with the current format, we can update the validators now, making the transition smoother for users of the library.

Thanks for your contribution!

A checklist is included below which helps us keep the code contributions
consistent and helps speed up the review process. You can add additional
commits to your pull request if you haven't met all of these points on your
first version.

All Changes

• Add an entry to the docs/changelog.rst describing the change.

• Add an entry for your name in the docs/authors.rst file if it's not
  already there.

New Fields Only

• Prefix the country code to all fields.

• Field names should be easily understood by developers from the target
  localflavor country. This means that English translations are usually
  not the best name unless it's for something standard like postal code,
  tax / VAT ID etc.

• Prefer 'PostalCodeField' for postal codes as it's
  international English; ZipCode is a term specific to the United
  States postal system.

• Add meaningful tests. 100% test coverage is not required but all
  validation edge cases should be covered.

• Add .. versionadded:: <next-version> comment markers to new
  localflavors.

• Add documentation for all fields.

[heltonteixeira92]

Hello, @rennerocha
I appreciate your efforts so far, I'd like to know if you still intend to continue working on this task? I think it would be a very useful update

[rennerocha]

Hello, @rennerocha I appreciate your efforts so far, I'd like to know if you still intend to continue working on this task? I think it would be a very useful update

The task is done. The code updated the validators so everyone will be able to handle the new CNPJ format. I just need that some maintainer of the project review it so it can be in the next release of the project.

Based on the commit history of the project, it appears that @benkonrath would be a good person to review it (or at least indicate who could do that) as he is the one with more commits in the latest year.

[benkonrath]

Thanks for the ping, and sorry for the delay. I'll try to get to it this week.

[benkonrath]

I see that min_length / max_length args have been removed from the doc string and the tests. Also, a couple of the previously valid values in the tests have been removed. I would expect that only a few additional test cases with the new alphanumeric version of CNPJ.

On my first read, this seems like a full re-implementation that's not code-compatible with the the existing version of BRCNPJField (the Django field and validator). i.e. It seems like existing code that uses BRCNPJField will need to be modified. Am I correct on this?

Perhaps a new field and validator should be added instead? -- maybe using the year in the name e.g. BRCNPJ2026Field. In this case, the current field and validator would need to be marked as deprecated (I can show you an example from a past deprecation).

If it is code-compatible, then the tests and doc string shouldn't change so drastically:

• doc string: only enough to tell people about the option for alphanumeric values - it's probably worth specifically mentioning that it's compatible with the update in July 2026.
• test: only adding new valid (and possibly invalid) tests - we need to prove that your changes aren't changing how people use this field.

[benkonrath]

See previous comment (I had to add something here... couldn't be blank).

[rennerocha]

@benkonrath thank you for the review. I addressed some comments and I will answer some considerations:

I see that min_length / max_length args have been removed from the doc string and the tests. Also, a couple of the previously valid values in the tests have been removed. I would expect that only a few additional test cases with the new alphanumeric version of CNPJ.

I added the same valid and invalid values that were present previously to ensure that we don't break anything. The only exception is the format 64-132-916/0001-88 that was inside the valid inputs, but it not valid, as we don't format CNPJ code that way. This was an wrong implementation and it shouldn't be like that.

I reintroduced the min/max length to reduce the changes in the current code, although they are not strictly necessary, since values ​​that do not have this minimum or maximum number of characters will not be validated as valid in any way.

On my first read, this seems like a full re-implementation that's not code-compatible with the the existing version of BRCNPJField (the Django field and validator). i.e. It seems like existing code that uses BRCNPJField will need to be modified. Am I correct on this?

In the old implementation, depending on the value you add to min_length and max_length of the form field, you would accept only one type of input (64132916000188 considered as "short format" and '64.132.916/0001-88 or 64132916/0001-88 considered as "long format"). This is still working, as the max/min length validations are done in Django based on the arguments provided, so any code that has that will continue working as before. To not confuse users I kept the docstring about these "formats¨, just to avoid extra confusion.

Everything else will continue to work, even if the implementation looks different. as the rules for validating CNPJs with digits only are the same using characters. This was done by Receita Federal (our Tax Agency) to avoid breaking things everywhere.

Perhaps a new field and validator should be added instead? -- maybe using the year in the name e.g. BRCNPJ2026Field. In this case, the current field and validator would need to be marked as deprecated (I can show you an example from a past deprecation).

If it is code-compatible, then the tests and doc string shouldn't change so drastically:

I updated the tests and docstring as you suggested.