If in the "Trade Management" configuration you cannot set the main VAT rate of 16%, the reason usually lies in the fact that the database has been customized in a non-standard way: a certain VAT rate is already hard-coded in it, and the standard rate-switching mechanism conflicts with it.
What is happening
In standard 1C configurations, the VAT rate is set by a standard reference book and settings that can be changed through the regular mechanisms of the program. But if the database was customized by a programmer for the specific needs of the company, a hard binding to a certain rate may have been introduced into the code or reference books. In this case, the system simply does not allow applying the new rate — 16% — because the customization "overrides" the standard logic.
What to do
Since the problem is not in the standard functionality, but in the database customization, it needs to be solved specifically:
- You need to find the place in the configuration where this fixed VAT rate is specified.
- Make a correction to the customized code or setting to free up the ability to specify the 16% rate.
This work is best entrusted to the 1C programmer who maintains your database and knows exactly what has been customized. There will be no universal "through the settings" solution here, because the issue is not the standard behavior of the program, but individual changes made to a specific database.
Frequently Asked Questions
Why is 16% set without problems in other databases, but not in ours?
Because your database has been customized — such a problem should not arise in a standard configuration. This means that someone previously made changes to the code or reference books that are now getting in the way.
Can this be fixed on your own, without a programmer?
If you don't know exactly what was customized and where the rate is specified, it will be difficult to find and fix the problem on your own. It is more reasonable to contact the person who customized the database, or any 1C specialist who can analyze the code.
Is this related to a configuration update?
Not necessarily — the problem lies specifically in the customization that was introduced earlier and continues to operate regardless of updates.
