Если этот комментарий относится к моему утверждению: я не смог смоделировать такую ситуацию.
Т.е. не могу придумать, как пользователи могут помешать друг другу, если функции планирования работают на фильтре формы ввода.
Если они полезут толпой вводить данные в один и тот же срез -- они заблокируют друг друга раньше, чем что-либо введут и сохранят. И от этого никакие фильтры не помогут.

Да легко: у тебя на срезе данных по какому-нибудь признаку "тип значения"= # лежат какие-нибудь коэффициенты для пересчетов. Если ты включишь в фильтр "тип значения" = {#;переменная} , чтобы расчитать значения на срезе "тип значения"= "переменная пользователя1", то первый же пользователь заблокирует этот срез, а второму пользователю, работающему со срезом "тип значения"= "переменная пользователя2", выполнить эту функцию уже не удастся, пока первый не завершит сеанс, т.к. они будет частично пересекаться по значению #.

Коэффициенты нельзя вообще включать в фильтр, т.к. они общие для всех, а блокировка всё равно ставится и остальные пользователи работать не смогут. Так что не годится пример. Он не будет работать даже если на каждом шаге последовательности разные фильтры.

Дорогие коллеги, нужна ваша помощь.
С FOX последний раз работала давно еще в BPS, а тут пришлось вспомнить.
Задача несложная, но я уже зациклилась и не знаю, в какую сторону двигаться.
На мультике есть 2 кубика, один с базовыми данными формата Страна-Департамент-Отдел-Счет-Сумма. Нужно суммы по счетам распределить согласно ключам из второго кубика с одного департамента на другие по отделам в рамках страны. Но коэффициенты там хранятся без статьи.
У меня следующий код

Foreach country, dep, otd in refdata.

Key = {kf2, cube2, dep, #, country, otd}.

Foreach acc in selection.
Base = {kf1, cube1, d1, acc, country, otd}.

If dep = d2 or dep = d3.

{kf1, cube1, dep, acc, country, otd} = base * key.

Endif.
Endfor.
Endfor.

Вроде все логично. Заходим с 3мя параметрами, полуваем ключик и гуляем с ним дальше в foreach по счетам.
но нет, при проверке с отладчиком оказалось, что fox ставит счет выше всех остальных параметров и вся логика на смарку т.е. ключ из второго кубика считывается, но только когда счет пустой, а дальше - '0'. Как побороть вредный fox? Или я может что-то из виду упустила? Помогите, пожалуйста, разобраться.

Поясните пожалуйста следующие моменты:
1. Фраза "Но коэффициенты там хранятся без статьи." практически разрушила мне мозг. Она наверняка что-то значит, но выпала из контекста.
2. В ключевой фразе вопроса "при проверке с отладчиком оказалось, что fox ставит счет выше всех остальных параметров и вся логика на смарку т.е. ключ из второго кубика считывается, но только когда счет пустой, а дальше - '0'" тоже далеко не всё ясно. Если здесь ключ -- это переменная key, то она и должна считываться с пустого счёта, см строчку "Key = {kf2, cube2, dep, #, country, otd}.", а дальше ничего не должно быть.

1. без статьи = без счета. Оговорка от многочисленных ночных бдений.
2. Проблему решила разделением циклов по country, dep, otd для кубика с ключом и для целевого кубика.