День добрый.
Есть задача. У документа есть два реквизита Статус и КомментарийКСтатусу. КомменатрийКСтатусу имеет тип Строка. Так же есть справочник ПричиныОтменыЗаказа. Когда заказ имеет статус "отменен", то на форму в поле комментария вываливается список причин отмены из справочника, и далее в реквизит документа "комментарий" пишется наименование причины отмены как строка. Тогда встает проблемы аналитики. Как отбирать документы включая/исключая те или иные причины отмены?
У меня пока два варианта:
- в отчетах формировать список значений из строк (наименование причины отмены), и искать по реквизиту Содержит/Не содержит
- либо добавить еще один реквизит, который будет иметь тип СправочникСсылка.ПричиныОтменыЗаказа, и в зависимости от статуса заполнять тот или иной реквизит.
Мне кажется оба варианта какие-то корявые. Подскажите как грамотно решить такую задачку?

dnjhjq dfhbfyn

первый слишком долгий согласен, а третьего не дано?

(0) На форме два поля на два разных реквизита - один справочник "причина отмены отказа", второй комментарий. Нефиг их мешать вместе

(3) да поле лучше одно оставить, чем больше полей, тем больше пользователь ошибаться будет.

ну а третий-то вариант может какой быть? ))

Одно поле для справочника "Причины отмены отказа". При выборе причины выскакивает окошко "Прокомментируйте!" куда надо ввести комментарий

Обычно начинают с формулировки задачи и цели, которой хотят достигнуть. После этого идёт сабж. ИМХО. Полагаю, что избрано неверное направление.

(7) Изначально стояла задача вести историю изменения статусов документа, и при необходимости добавлять комментарии. Далее усложнили, и решили что при статусе "отменен" в комментарий помещать причины, но они должны быть строго определены справочником. Но отображаться одним полем. Вот собственно вопрос, на коммент два или один реквизит? Или вообще менять подход к работе со статусами?

(8) Ты забыл рассказать еще про третье усложнение:
"Дальше еще усложнили и решили, что по причинам отказа надо вести аналитическую отчетность"

(9) да, извините.

Очень похоже на версионирование. Осталость сообщить какая типовая конфигурация используется. БСП используется?

Какой тип реквизита статус? Если справочник, то достаточно включить иерархию в нём разложить возможные причины. При этом ограничить доступ на формирование справочника.
P.S. Информацию клещами вытягивать? ))
Или задача ветки оказаться длинной?

(11) да похоже, но в малых масштабах. Конфигурация УТ 10.3, переписана сильно, очень сильно. Честно говоря, что такое БСП только что-то загуглил )) думаю что не используется.

статус да, справочник. Можно поподробней про иерархию?

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

(15) что-то я не подумал про это. Спасибо большое за идею.
И всем спасибо за советы. ))

Имхо, работу со статусами лучше выносить в регистр сведений.
Это позволит легче оперировать содержимым + сразу можно добавить дату изменения статуса, не добавляя новых реквизитов.

(17) все так и работает. Только вот заморочка вышла с комментарием к статусу, он теперь потребовался в виде справочника.ссылки + строка.

(18) Тогда в чем проблема - новый реквизит в РС - комментарий к изменению статуса. + доп. форма при изменении статуса.
Как вариант - справочник с причинами + текстовая расшифровка. Тогда отбор по причине позволит видеть причины отклонений, а тесктосвая расшифровка позволит контроилровать обоснованность применения причины.

(19) да так все и работает, спасибо. )))