fix: Change account number integrity from unique by company to unique by (company, root_type)

[noec764]

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 60.12%. Comparing base (3fa8706) to head (5e5ab57). Report is 130 commits behind head on develop.

:exclamation: Current head 5e5ab57 differs from pull request most recent head fb32ec3

Please upload reports for the commit fb32ec3 to get more accurate results.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #39703      +/-   ##
===========================================
- Coverage    60.92%   60.12%   -0.81%     
===========================================
  Files          764      758       -6     
  Lines        72284    70963    -1321     
===========================================
- Hits         44041    42666    -1375     
- Misses       28243    28297      +54     

Files	Coverage Δ
erpnext/accounts/doctype/account/account.py	69.48% <100.00%> (-0.33%)	:arrow_down:

... and 343 files with indirect coverage changes

[FHenry]

Context : In France we have chart of account where the same code can be use as Liability or as Asset ( the root_type do not exists like that but in France, it imply other definition and meaning but we try to find a way to allow proper French accountancy in ERPNext) This PR make two changes :

• Use the same method/function on Account creation as on Account update to check the validity of the account number
• Send root_type as parameters to validate_account_number() to check account number uniqueness by company and root_type

We can understand that add root_type to the check the uniqueness of a Account number may not please all country accountancy rules. So we can also change the PR to always send root_type as parameters and not use it for standard/core test of uniqueness but add @erpnext.allow_regional on the validate_account_number() function. Like that we can override it in ERPNext France app

@deepeshgarg007, @ruchamahabal : What is your opinion / preference on these options ? What can we do find a compromise on this ? What is the better process to discuss and make it possible in ERPNext for this feature ?

[stale[bot]]

This pull request has been automatically marked as inactive because it has not had recent activity. It will be closed within 3 days if no further activity occurs, but it only takes a comment to keep a contribution alive :) Also, even if it is closed, you can always reopen the PR when you're ready. Thank you for contributing.

[stale[bot]]

This pull request has been automatically marked as inactive because it has not had recent activity. It will be closed within 3 days if no further activity occurs, but it only takes a comment to keep a contribution alive :) Also, even if it is closed, you can always reopen the PR when you're ready. Thank you for contributing.

[stale[bot]]

This pull request has been automatically marked as inactive because it has not had recent activity. It will be closed within 3 days if no further activity occurs, but it only takes a comment to keep a contribution alive :) Also, even if it is closed, you can always reopen the PR when you're ready. Thank you for contributing.

[noec764]

Hi @deepeshgarg007, can you check this PR again please? Regards

[stale[bot]]

This pull request has been automatically marked as inactive because it has not had recent activity. It will be closed within 3 days if no further activity occurs, but it only takes a comment to keep a contribution alive :) Also, even if it is closed, you can always reopen the PR when you're ready. Thank you for contributing.

[stale[bot]]

This pull request has been automatically marked as inactive because it has not had recent activity. It will be closed within 3 days if no further activity occurs, but it only takes a comment to keep a contribution alive :) Also, even if it is closed, you can always reopen the PR when you're ready. Thank you for contributing.