[Ardi]

Допустим есть журнал "Реализация". В требуется вывести дополнительные колонки.
Наподобие "Есть расходный ордер", "Возврат", "Перечень номенклатуры документа", "Есть ПКО", "Есть банк" и т.д.
Делать это запросами к куче таблиц надоело.

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

[logist]

Регистр сведений: измерение - Объект, ресурсы - необходимые значения.

[Vofka]

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

запросами к куче таблиц

[logist]

Потому как для запонения того же регистра сведений всеравно прийдется делать

изменять его подписками на события например.

При записи того или иного документа делается запись в регистр, какие еще запросы?

[Vofka]

При записи того или иного документа делается запись в регистр, какие еще запросы?

Для того, чтобы данные записать в нужном виде их необходимо как-то/откуда-то получить. "Как-то" - это скорей всего с использованием запросов. Ваш Кэп.

[logist]

Данные в нужном виде это и есть документ Источник события. который, например, по полю Основание = Объект в РС запишет данные о себе. Не надо никаких запросов.

[Vofka]

Данные в нужном виде это и есть документ Источник события. который, например, по полю Основание = Объект в РС запишет данные о себе. Не надо никаких запросов.

Берем УТ. Вы говорите, что эти данные:

Наподобие "Есть расходный ордер", "Возврат", "Перечень номенклатуры документа", "Есть ПКО", "Есть банк" и т.д.

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

[logist]

"Есть расходный ордер" - при записи Источника ордера в нем же есть ссылка на документ Объект? При записи Источника возврата в нем же есть ссылка на документ Объект?....

Я говорю о том, что записи в регистр должен делать не сам Объект, а документы которые связаны с этим Объектом по полю которое определяет связь.

[Ardi]

Я говорю о том, что записи в регистр должен делать не сам Объект, а документы которые связаны с этим Объектом по полю которое определяет связь.

Именно. (Например ПКО вводится на основании РН. Центральным документом сделки будет заказ либо РН если заказ не заполнен).

И я спрашиваю какие есть интересные варианты в каком дополнительном объекте хранить связанную инфу.
Пока только одно предложение.

Сообщение отредактировал Ardi - 17.09.13, 11:50

[Vofka]

А, ну я знач не так изначально понял. Тогда, тут только 1 вариант может быть: только регистр сведений. Если сделать как по проще, то выше logist вариант озвучил. Но можно сделать по сложнее, но, по-моему, красивше будет: сделать 2 измерения Объект и НазваниеДопКолонки. Название доп. колонки - это может быть какое-то перечисление либо какой-то справочник. Работать с такой структурой будет сложнее, за то структура хранения данных будет корректнее и без излишек, я считаю.

Сообщение отредактировал Vofka - 17.09.13, 12:01

[python]

Vofka, какой тогда тип данных у значения регистра сведений будет? И как оно потом в БД хранится?

А отборы планируется строить по этим колонкам дополнительным?

[Vofka]

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

[Ardi]

сделать 2 измерения Объект и НазваниеДопКолонки

При пометке на удаление ПКО запись из регистра удалится. А если ПКО 2 штуки - то одна запись должна остаться.

А отборы планируется строить по этим колонкам дополнительным?

А если вдруг потребуется - то тогда какие объекты использовать?

[Vofka]

При пометке на удаление ПКО запись из регистра удалится. А если ПКО 2 штуки - то одна запись должна остаться.

Тогда 3 измерения: Регистратор, ВладелецСвойства (расходная накладная, в данном случае), Свойство.

[Zaval]

При пометке на удаление ПКО запись из регистра удалится. А если ПКО 2 штуки - то одна запись должна остаться.

А что дает сам факт наличия ПКО? Или возврата?
По-доброму нужно примероно так
Заказ
Отгружено на ... грн
Оплачено на ... грн
Выписано НН на ... грн
Возврат на ... грн

А еще лучше сразу выводить отклонения? нпр "недовыписано НН на ... грн. Тогда юзеру не придется вчитываться в цифры и сравнивать их.
Или не цифры, а колечки, как в УНФ.

[python]

Какова все же цель этих реквизита? Тип данных содержания?
Если текстовая метка для журнала - так можно просто регистр сведений, и значение каждой из колонок отдельно для объекта хранить. Придется менять метаданные - это да. Но и код для извлечения и вывода данных будет проще. В принципе - и тип данных может быть разным...
Неопределенный тип данных значения и вид свойства в измерении - 1с создаст несколько полей для хранеия каждого из типов значения, не хорошо это.

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

[Домовик]

нужно нарисовать дерево всех возможных решений, отталкиваясь от центрального документа. Обозвать каждую точку-состояние как-то и описать, чтоб понятно было пользователю (пример "РН-Возврат-РКО"). При совершении события (проведении дока, пометке на удал, снятии пометки на удал,.... ) изменяем точку-состояние, на другую точку-состояние (точки-состояния хранятся не знаю где). В журнале "Реализация" ссылка на точку-состояние.



Сообщение отредактировал Домовик - 17.09.13, 14:21

[Zaval]

сделать 2 измерения Объект и НазваниеДопКолонки. Название доп. колонки - это может быть какое-то перечисление либо какой-то справочник. Работать с такой структурой будет сложнее, за то структура хранения данных будет корректнее и без излишек, я считаю.

Думаю, так лучше не делать. Есть пример - РС КонтактнаяИнформация в типовых. Вначале было хорошо, теперь получился этакий монстрик.

Других предложений по объекту хранения данных не будет, logist выдал единственно правильное.
Принять его мешает то, что придется писать запрос по двум таблицам - т. е. данные хранятся неоптимально с точки зрения удобства извлечения.
Но это беда не решения, а постановки задачи.
Строго говоря, это надевание седла на корову - форма списка документа хороша для решения своих задач.
По-моему, лучше использовать форму списка того самого РС, в который все документы сами о себе все запишут.
Если одного РС будет мало - тогда отчет формоспископодобного вида.

нужно нарисовать дерево всех возможных решений, отталкиваясь от центрального документа. Обозвать каждую точку-состояние как-то и описать, чтоб понятно было пользователю (пример "РН-Возврат-РКО"). При совершении события (проведении дока, пометке на удал, снятии пометки на удал,.... ) изменяем точку-состояние, на другую точку-состояние (точки-состояния хранятся не знаю где). В журнале "Реализация" ссылка на точку-состояние.

Дерево получится, нпр, для статуса документа. Оплату и возврат в одно дерево не запихнешь.

[python]

А не лучше ли заменить журнал на обработку?

[Vofka]

Думаю, так лучше не делать.

Почему?