Запрет создания дублей. Сравнение элементов справочника с табличными частями #766141

Есть справочник Мероприятие с реквизитами: Наименование, ТипМероприятия, КонтингентСлушалей (ПотокГрупп, Группа, Подгруппа, КоллективЛюдей), Ответственный, КоличествоЧеловек(рассчитывается на основании данных ТЧ). И есть табличная часть (ТЧ), в которой перечислены слушатели (группы, преподаватели или просто имена людей) Надо чтобы при создании элемента проверялось нет ли в базе такого же. По реквизитам проверку понятно- можно запросом. А как быть с ТЧ? Тем более что порядок слушателей произвольный. Даже если исключить проверку при контингенте = КоллективЛюдей, т.к. тут состав участников в принципе не окончательный, всё равно группы добавляются в ТЧ в произвольном порядке, но от перемены мест слагаемых.... При этом надо текущую форму элемента закрыть, существующую открыть. А если Форма создания была вызвана из формы выбора, то установить указатель на ней. Насколько реально это сделать? Просто 1с только осваиваю, поэтому знаний так себе((((

все же решили сами ваять? или готовое допиливаем?

Нужно сделать запрет создания дубля мероприятия с некими людьми, если эти же люди уже ходили на такое же мероприятие?

Готовое я так и не нашла где скачать Так что изобретаю свой велосипед. К тому же это диплом, так что тут готовое вроде как нельзя использовать, даже допиливая

Есть два Мероприятия. Одинаково все, кроме того, что в первом есть Вася, а во втором Васи нет. Это разные мероприятия? Может должны быть другие критерии отличия?

DracO прав, отделяй мух от котлет. Мероприятия  это котлеты, контингент - мухи.

и Сейчас постараюсь пояснить на примере Мероприятие 1: С Л У Ш А Т Е Л И      - ТЧ Мероприятие 2: ОтветственныйЗаМероприятие: Семёнов В.С. С Л У Ш А Т Е Л И     Группа К-8             Это одинаковые элементы. В ТЧ может быть один элемент - группа. Могут быть перечислены преподы из справочника или просто имена какие-нибудь(Тип данных составной: группы, преподы, строка - выбирается нужный автоматически в зависимости он контингента слушателей). Но в случае преподов или просто имён думаю такая проверка будет лишней, т.к. это не точный перечень

Немного некрасиво отформатировалось во втором мероприятии

А что написано в задании?

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

"Но тут всё решается для числовых данных и результат выясняется на основе некоего сворачивания, что в моём случае как я поняла невозможно." Почему невозможно? Сворачивание необходимо только для сравнения количество одинаковых строк.

пока сути проблемы не понял ну завели 2 документа и что? по каким признакам можно догадаться (программа должна) что это дубль? может начать с формулирования этих признаков? тогда будет понятно как контролировать

Когда совпадают и данные шапки и данные ТЧ (состав строк). Типа, когда ЭрастПетрович Бирюлькин ведет матан для групп 202 и 203 и когда он же ведет для групп 202 и 204 - это разные мероприятия, а если введут снова его же для групп 202 и 203 - это дубль. Интересно, а как это учитывает две пары подряд? :)

В задании к диплому? Тут я расписывала: Собственно задачи именно так организовывать мероприятие не стоИт. Это моя задумка для реализации Изначально я думала, что в мероприятии будут данные о частоте его проведения, дням недели, номерах пар - чтобы автоматически найти нужные даты. Но потом решила вынести это в саму обработку а за мероприятие принимать именно мероприятие, которое может быть использовано несколько раз. Потому что лекция по ПАСу еженедельно по вторникам - это одна аудитория, а раз в 2 недели по четвергам - уже вполне может быть другая. НО эта лекция по ПАСу - лекция по одной и той же дисциплине, ведётся одним и тем же преподом для одних и тех же студентов. Т.е. ПАС по неделям в расписании этих групп так: 1. Вторник 1я пара ауд. 1, четверг 3я пара ауд.15 2. Вторник 1я пара ауд. 1 3. Вторник 1я пара ауд. 1, четверг 3я пара ауд.15 4. вторник 1я пара ауд. 1. Для 1 и 3  недели - это в одном случае поиска выбираем, а для 2 и 4 - уже в другой. По сути их ничего не связывает, только одинаковое мероприятие. Или можно создать 2 мероприятия для двух графиков проведения: 1.еженедельно (ищем аудиторию на каждый вторник) 2.раз в 2 недели (ищем аудиторию на каждый четверг по чётным неделям)

А, ну это я не знала про сворачивание, просто предположила=) Спасибо, что сказали)

про это и хотел сказать, что не хватает как минимум "времени мероприятия" а если время разное но хочется чтобы одна и та же группа не изучала дважды одно и то же то так и сделать проверку именно по группам (по ТЧ) на количество строк с совпадающими реквизитами шапки ))

не взлетит

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

+ система (интерфейс пользователя) получается слишком сложная, на защите диплома завалитесь и использовать ее не смогут

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

Так как ты будешь сдвоенные лекции вводить, объясни?

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

Для пользователя по идее видно не будет Она просто всегда будет создавать мероприятие, заполнять все 5 реквизитов и ТЧ, просто объект новый создаваться не будет А вот с защитой... Как сказать. В комиссии 99% не будет человека, знающего 1С.

+ таким "ключом набора групп" банально может выступать их отсортированный список т.е. ТЧ забили произвольно а оно автоматом сортируется или использовать "битовые маски" где каждый бит (или символ) это признак нахождения группы в составе ТЧ

>Для пользователя по идее видно не будет >Она просто всегда будет создавать мероприятие, заполнять все 5 реквизитов и ТЧ она не будет создавать мероприятие  - ибо "слишком сложно" )) если уж пошел учет "по предметам", то придется сразу и учебный план вносить (предмет, препод, группы, кол-во часов) и чтобы по кнопке "рассчитать" оно разбивало по кабинетам и времени ))

2 раза поиск аудитории Сначала ПАС с графиком еженедельно по вторникам. Выбрали аудиторию - ок, записали Снова вызвали форму поиска выбрали мероприятие ПАС. Но график указали - раз в 2 недели по четвергам. Нашли аудитории для четверга на это время на все рассчитанные даты Упрощённо даты планирую считать так: Есть дата начала, дата окончания и график. В итоге на семестр из 16 недель нужно чтоб аудитория была свободна в указанное время для всех дат (по вторникам начиная с даты начала и по дату окончания)

Нет, если во вторник должно преподаватель читает ДВЕ лекции по этому предмету этим группам?

.Не, по предметам учёта нет. Это просто в названии в ручную как правило сокращённо название предмета забивается. Она может даже не знать, что это за предмет и для её задачи это не важно. Важен тип мероприятию и требования к помещению для его проведения. , . Идея с регистром интересна. Правда наверное не очень оправданно для такой задачи как запрет дублей аж целый регистр создавать. А какая тогда структура регистра?

структура регистра то что нужно контролировать, логично же

Мы же номер пары указываем ещё. Не только день недели. Я думала для спаренных пар просто разрешить множественный выбор. Поверхностный поиск по гуглу сказал, что можно выбирать несколько из формы выбора. Получается ищем по измерениям дата, пара, где мероприятие не заполнено - значит аудитория свободна Это из регистра сведений "Занятость аудиторий" с измерениями: Дата, пара, аудитория, и ресурс- мероприятие

. Т.е. я не ошиблась, когда решила, что измерения - это все 5 реквизитов + ТЧ в виде ключа? А ресурс тогда Ссылка на элемент справочника?

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

Ну что ж, пожалуй, это действительно лучший вариант. Спасибо за идею Только вопрос стОит ли овчинка выделки. По сути пользователь всегда будет заполнять реквизиты. И для неё ничего не изменится. Это только вопрос оптимизации хранения данных. С другой стороны у меня при запуске сисетмы постоянно двигается время в РС (дни из прошлого более, чем месячной давности не интересуют нас и они удаляются, новые добавляются - т.о. постоянно поддерживается заполненность регистра пустым мероприятием на пол года вперёд, т.е. поиск аудитории можно осуществить на пол года вперёд). И есть процедура в модуле УП, которая удаляет из справочника неиспользуемые элементы. Как думаете, стОит ли так усложнять алгоритм и добавлять чисто служебный объект, который больше нигде не будет использоваться ради сокращения количества записей в справочнике?