General information
Any changes related to Rates, Routes, Destination Sets, Tariffs, DID numbers, DID Charging Groups and Routing Groups may not be applied immediately. You need to wait at least for 1 min so that the system can update its internal "cache". Sometimes, in case of a heavy bulk update of, for example, multiple destination sets at once, it may be required more than 1 min.
Goal
This internal "cache" was designed specifically in order to increase system performance. Roughly saying, the system loses some performance (speed) while updating the authentication/routing data (made by a human) and spends some time on writing the newly updated data into the "cache". However when a real call comes, it does not spend any time on querying the DB and filtering the results. Instead, the system already has this data in "cache" which greatly decreases the time during the authentication/authorization/routing of every new call.
Workflow
The update "cache" job is run every minute. Thus, in case of a minor change, you may expect the new changes to be applied within 1 min. When a multiple entities are updated (e.g. a bulk update of 10 tariffs with 65535 rates each using binary upload), these entities are put into a queue and processed one-by-one. As a result, it could take more than 1 min to update the "cache" and depends how powerful is your bare metal server (i.e. CPU, HDD etc).
How do I know whether my recent changes are already in the "cache" or not ?
There is a tool called Test Dial Plan which uses system's "cache". If your recent changes didn't reflect the result of Test Dial Plan, it means that the cache is still about to be updated.
After adding the prefix 1786 in account's tariff:
After waiting for 1 min and update of system "cache":
