Как-то вот оно не получается красиво... может, туплю...
Итак: есть продажи (опт).
Требуется рассчитать премию клиенту в зависимости от оборота (ну например тупо процент от оборота).
Премия для разных клиентов рассчитывается по РАЗНЫМ (произвольным!) периодам; премия считается для связки "клиент-договор"
а) Делаем справочник "Периоды", реквизиты ДатаН и ДатаК, наименование - формируем из реквизитов, тут вроде понятно...
б) делаем док типа "РасчетПремии", в тч дока "подбираем" документы продаж, задаем клиент+договор; далее задаем период из спр.Периоды - и тут хочется после ввода периода !!быстро!! поиметь "инфу" о том, что данный кортеж "клиент-договор-период" - есть уникальные, при этом период не должен пересекаться с другими периодами (полностью или частично не включать в себя другие периоды и не быть самому включаемым в другие периоды)... и тут я застрял... или схема кривая выбрана или иначе никак... Проверять на уникальность при проведении дока - хз... как-то мне это не хочется (но видимо придется) - при проведении планируется в регистр оборотов писать клиент-договор-документ как измерения и при проведении проверять что такой документ еще не присутсвовал в этом регистре оборотов...
.
??? мнения, плиз.

стареешь...

(1) вот не поверишь - информации в товем сообщении - никакой ;-)

В номер документа через разделитель КодКонтрика, КОдДоговора, ДатаНач, ДатаКон


Но сама схема премирования не правильная ... что ж лучший покупатель недели, не м.б. лучним покупателем месяца или года?

один док нуна, типа "Договора клиентов" с датами и прочей лабудой

(3) ну.. на крайняк и так можно...

(4) ??

(3) может быть. но по умолчанию док заполняется продажами за отчетный период, которые не были еще в "премиях"; манагер может произвольно добавить доки из других отчетных периодов (ранее упущенные, на переходящих/стыке периодов) - они будут относится в премию УКАЗАННОГО периода.
.
тут не "лучшие" покупатели - тут сети, у них может быть что угодно, вплоть до бонуса на премию.. ;-)

(4) имеется в виду, что расписать "график" премий... - как вариант, подумаем...

имелось ввиду программно указанный док формировать
ЗЫ ночью когда все спят, что бы никто не видел

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

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

(7) а упущенных быть не должно .. ТЧ заполнять автоматом при вводе периода

Но я тут хз .. как у вас там вообще процесс

(12) да, примерно так!

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

Хорошо помогает при анализе примерчик расчетов, в котором есть все возможные варианты расчета. Обороты по клиенту есть всегда. Нет смысла считать их отдельно. Процент от оборота можно закинуть в договор. В договоре есть начало и окончание договора. А вот принцип "быстро.. поиметь инфу..", на мой взгляд, неправильно. Инфа должна быть по итогам завершенного периода.

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

(15) процент от оборота - известен, "проблем" нет.
"по итогам завершенного пери ода" - так и есть, период закрыли - премию посчитали.  Но если не предусмотреть контроль "неуникального "периода - это потенциальная дырка, в которую если проскользнет сумма - истребовать ее назад весьма геморрно...

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

(16) хорошо, если есть регистр с полями Клиент - Договор - !!Период!! - Документ, то какие проблемы с быстрым получением информации по уникальности? я забыл метод регистра, посмотри, как это делается в форме подбора МПЗ со складов в ТИС. Поле "Остаток на складе". О, СводныйОстаток(<?>,), только надо будет рассчитывать регистр на "задние" документы.

+(19) только надо придумать, как его закрывать....

хм, хотя планируется регистр оборотов, у него нет такого метода. Тогда СводныйИтог(), пойдет?

(19) мну не нравится сам тупой подход..
13.11.11-20.11.11 пересекается с 01.11.11 - 30.11.11
- это бежать по всем записям и тупо смотреть.
.
тогда уже лучше в регистр в качестве измерения пихать отдельно ДатаН и ДатаК - проще тогда анализировать будет

(22) забыл про то что периоды в справочнике периодов могут пересекаться

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

(23) угу.. это я уже скакнул вперед...  тут, блин, получается дубль проверки - и при заполнении документа и при его проведении... бяка..

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

или расчетом так же перекрывать период, затем смотреть в журнал расчетов, ест ли у этого клиента расчеты на требуемый период?

(26) а смысл - все равно по датаН и датаК проверять надо...

можно ли каким-то образом свести пару ДатаН-ДатаК к какому-нить "примтивному" значению, которое бы при сравнении с другим примитивным аналогичным значением (по другому периоду) -позволяло бы сразу понять - что трабла!!?

"премия считается для связки "клиент-договор" " - контрагент здесь явно лишний

(30) непринципиально, можно и сократить..

(7) При такой схеме не все ли равно какой период? Просто смотри чобы доки были уникальны. Типа за этот док уже было начисление

(29) наврятли, а чем не нравится по ДатаН и ДатаК парсить. Делаешь ЗначениеНаДату, смотришь, что на начало; ВыбратьЗначения(<ДатаНачала>,<ДатаКонца>) есть ли перемены.

(32) а действительно!

Я так понимаю, справочник "Периоды" будет подчиненным спр. Договоры? А если для всех КА и договоров сделать по 365 периодов по 1 дню и проставлять плюсики типа "использован"?

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

"вместо сравнения двух периодов надо сравнить гораздо больше периодов" - да, но в момент выбора юзером ДатыКонца идет проверка на вхождение в период дней с пометкой "использован". Зато у все КА+договор одинаковые периоды и легко выдать пропущенные - за которые не рассчитана премия.
"пекриоды стопудово не подчинен договорам" - а почему, если "Премия для разных клиентов рассчитывается по РАЗНЫМ (произвольным!) периодам; премия считается для связки "клиент-договор" ?

(37) можно уменьшить до "договор" вместо "клиент+договор"

(37) "...в момент выбора юзером ДатыКонца идет проверка на вхождение в период дней с пометкой "использован".
.
подумаем...

можно уменьшить до "договор" вместо "клиент+договор" - это не важно, договор - ниже по уровню, поэтому и предложил подчинить ему. Плюсы - все проверки проводятся в момент подготовки дока, когда док уже заполнен - ничего проверять не надо. Галочку "использован" проставляем в момент проведения дока.

+ "манагер может произвольно добавить доки из других отчетных периодов" - при добавлении дока проверяем его дату на "использован"

кардинально мне не нравится (вообще) когда проведение в справочник что-нить пишет... но идея ясна, подумаю...

(41) дата дока тут - не то, док, регистрирующий расчет премии лежит м.б. вне отчетного периода премий

(43) - я, наверное, не так понял - думал, добавляются доки реализации