Добрый день!
Есть регистр сведений, в котором активные менеджеры.
В базе есть константа, которая хранит последнего получившего заказ менеджера. При поступлении нового заказа, список активных менеджеров сортируется по алфавиту, далее находим последнего получившего заказ, и следующий после него - тот кто получит текущий заказ.

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

генератор случайных чисел используй, если число вне диапозона, то переходишь к следующему менеджеру

(0) Сначала "Теперь вопрос, нужно ввести некие коэффициенты"

нашел
wiki:Взвешенная_справедливая_очередь

(2) у меня логика такая)
(1), (3) спасибо, пригодится

Во-первых, нужно учитывать время освобождения менеджера, то есть первый, кто освободился, по идее, и должен получать заказ, так как это заставит их более быстро работать.
Во-вторых, если следует ввести пропорцию по количеству уже полученных заказов, чтобы кто-то не остался вообще без всего.

В идеале, мы пишем функцию, которая в параметрах получает данные менеджера, время освобождения, количество заказов и т.п.
Далее, мы выбираем максимум этой функции на множестве доступных менеджеров - он-то и будет получающим следующий заказ.

генератор случайных + 1
0..5 - Петров
6..8 - Сидоров
9.. 15 - Иванов

(5) Все это уже отработано. Те, у кого есть заказы необработанные, в очереди не участвуют. Они мотивированы получать больше заказов.

(6) Мне тоже идея с генератором понравилась.

(6) и че будем делать если сидорову и иванову выпадет 20 заказов а петврову 1? петров вам попртит лицо я думаю

(8) у генератора равномерный закон распределения
такой вариант возможен, но крайне маловероятен

(8) заказов не мало, думаю распределение будет примерно равномерным.

(9) крайне - это сколько? лицо у меня одно все таки
(10) а сколько менеджеров в отделе и сколько заказов в среднем

(8) карибасы должны страдать

(11) тебе интересно - возьми и протестируй

(10) если я правильно понимаю, у менеджеров заработок зависит от заказов
в этом случае любые отклонения от "справедливого" распределения будут восприниматься очень болезненно. я бы не рекомендовал
(13) слив засчитан

(11) в среднем 25 заказов на менеджера в день

(14) слабо написать тест - засчитано )

(14) согласен, потому вопрос все еще актуален

Как справедливо распределить заказы между заинтересованными менеджерами, с учетом весовых коэфициентов?

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

(19) С дробными коэффициентами можно бороться - просто умножить на какое-то число, чтобы все коэффициенты стали целыми и повторять в очереди людей столько раз, какой коэффициент у него указан.
Далее, можно из этой очереди выдёргивать любую запись, то есть отдавать менеджеру заказ - хоть случайно, хоть по порядку.

И, всё же, мне кажется логичным, что заказ получает тот, кто раньше освободился.
То есть регистр - таблица:Менеджер,ВремяОсвобождения,Занят.
Выбираем запросом первую запись с минимальным временем освобождения, и условием, что Занят=Ложь.
Этой записи ставится Занят=Истина, а менеджер получает заказ.
После того, как менеджер освобождается, он нажимает кнопку для постановки в очередь, которая обновляет его запись, указывая время освобождения, а Занят проставляет в Ложь.
И всё.

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

(20), (21) спасибо, но я придумал по-другому:
добавляем 2 поля: Количество заказов в рамках одной очереди (A), Количество заказов полученных в текущей очереди (B).
А - постоянный коэф. задается вручную.
B - при каждом получении заказа увеличивается на 1
При B = A, B присваиваем нулю.

Далее сортируем активных менеджеров:
1) A-B по-убыванию
2) По фамилии возр

В такой схеме по-моему даже константа "Последний получивший заказ менеджер" не нужна.

Там где описание А и В "очередь" надо читать как общая порция заказов, в рамках которой идет распределение.

Ошибся немного в терминах, но суть надеюсь понятна.

Кто-нибудь "подводные камни" видит?

(21) У нас очень хитрые менеджеры, если по времени освобождения распределять, то качество пострадает.
Например, самый умный будет фиктивно проводить заказы, чтобы ему система добавляла еще, а потом когда будет затишье - начнет обзванивать те заказы, что провел ранее и корректировать их.
А нужно, чтобы заказы обрабатывались сразу при поступлении, а не через час, например.

Сначала всем, у кого вес больше 1 - остаток от (вес - 1) кладем в кэш
Потом по кэшу, у кого уже есть 1, выдаем, потом опять всем и тд

(25) Тогда проще сделать:
А - весовой коэффициент заказности, то есть доля в количестве заказов (получаемых по сумме всех долей).
Б - количество уже выполненных заказов.
Если Б равно нолю, то заказ получает менеджер с максимальным А.
Если Б не равно нолю, то выбираем минимум Б/А.

(25) В приведенном примере не видно как пострадает качество.
Ну наберет заказы, главное чтобы он их отработал.

(28) он будет их отрабатывать долго, а те кто недополучили заказы из-за хитрости коллеги, будут сидеть без работы.

Ты определись что тебе нужно "справедливость для менеджеров" или "повысить эффективность" отработки заказов.

(30) мне нужно равномерное распределение заказов, согласно очереди и коэф-тов

(22) Вообще, есть две ситуации - первая, когда очередь заказов, то есть заказ пришёл, а свободного менеджера нет, тогда да - нужно их подгонять, чтобы они работали побыстрее; а вторая - заказов нет, а несколько менеджеров их ждут - тут, наоборот, нужно мотивировать менеджеров подольше работать с заказами - иногда это приводит к росту объёмов заказов.

(25) корректировки нужно фиксировать и учитывать в КПИ

(33) не согласен.

(32) обе ситуации есть, например утром заказов много (за ночь насобиралось), те кто с утра конкурируют чтобы больше забрать заказов. Днем заказы к распределению приходят по-одному, а менеджеров активных много.
При этом необходимо, чтобы менеджеры отзванивались втечение 5 минут после поступления заказа.

А что мешает обрабатывать заказы через час.
Например, если покупатель запрашивает то, что сейчас нельзя рассчитать - не проще ли узнать у покупателя телефон и заняться расчётом и запросом цен у поставщиков, а в это время взять ещё несколько заказов ?
Потому как иногда заказ может переходить в состояние, когда от менеджера уже ничего не зависит.

(27) не пойму почему проще, в моем варианте нужно просто посортировать колонку и сразу получить того кому заказ (первая строка в таблице), в вашем варианте нужно искать минимум и максимум.

(36) количество менеджеров позволяет отзваниваться по новым заказам втечение пяти минут после поступления заказа.

(31) для этого нужно знать время выполнения заказа

(37) Да, в принципе, таким же запросом и делается.
Непонятно только, зачем нужно сортировать их по фамилии ?

(37) В итоге все получат по 1 заказу, только в разной последовательности и где тут весовые коэффициенты?

(39) у меня уже реализована та чать, которая автоматически управляет активностью менеджеров, поэтому вопрос был лишь в распределении.

(41) В (22) А - это весовой коэф-т

(38) Тогда, быть может, разбить их на группы - "попугаи" и "кроты" - первые, отзваниваются как можно бытсрее и выясняют заказ, если быстро, делают всё сами, если какие-то запросы, то передают "кротам", а вторые "разгребают" то, что не сделали первые.
В этом случае, в начале рабочего дня "попугаи" получают последние заказы, по которым нужно отзвониться быстрее.
Потом, лимит времени на работу попугая можно задать так, чтобы он его старался соблюдать и успевал утрясти все простые вопросы, "крот" же должен довести заказ до конца.

(43) Так и в (27) - тоже, только там в Б накапливается количество заказов, которое, само по себе, очень интересно.

(40) Сортировка по фамилии это как очередь второго порядка, для тех у кого значения по первой сортировке одинаковы.

(45) (22) и (27) по-моему одну и ту же суть несут, только я не понял почему (27) проще?

(46) Это несправедливо, так как первые в списке будут иметь приоритет.

(43) да, и я типа такого же предложил

(48) так пока первая порция заказов не распределится их приоритет по фамилии не сработает

(47) Потому что В, в (22) ставим равным нолю после того, как оно дошло до А.
Если все дошли, и все стали равными нолю - что - начинаем новый день ?

(50) Если не сортировать по фамилии, то первой записью будет та, которая первая в регистре - тоже как бы априори задана.

Просто, если каждый день первый заказ будет получать какой-нить Абакумов, то справедливость системы сразу поставят под сомнение.

Ладно - в принципе - всё уже описано и сделано в (22) осталось только убедить менеджеров, что так и должно быть.
А мне пора.

(51, 52, 53) понял, это уже доводка алгоритма, буду смотреть как лучше, выбор вы мне предоставили, спасибо

А - заказов за день всего
Ам - этому манагеру
Вм - вес манагера
Вм-Ам/А - отклонение веса
решаем задачу минимизации вектора, надо ввести метрику, ужас
при равных бросок ГСЧ

(56) непонятно чем ваш вариант лучше предложеного в (22), (23) или (27).
Чем хуже - сказать могу, только смысл объяснять, если я для себя решение уже нашел?

метрика Мин() по всем итым больше 0

(56) Если менеджеры работают втечение дня разное время, то ваш алгоритм будет работать не верно, заказы должны распределяться равномерно среди активных менеджеров, а не учитывать общее количество заказов, и отношение к весовому коэф-ту.

(57) я бы добавил случайности, а так все равно. в (22) манагер довольно быстро выяснит что до обеда ловить не чего

(60) случайность состоит в том что таблица активных менеджеров непостоянна, те кто получают заказ, или долго не обрабатывают поступивший заказ, автоматически становятся неактивными.