Версия для печати темы (https://pro1c.org.ua/index.php?showtopic=14270)

Автор: Ardi 16.09.13, 16:32

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

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

Автор: logist 16.09.13, 17:15

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

Автор: Vofka 17.09.13, 7:50

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

Автор: logist 17.09.13, 8:04

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

Автор: Vofka 17.09.13, 8:06

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

Автор: logist 17.09.13, 8:43

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

Автор: Vofka 17.09.13, 10:05

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

Автор: logist 17.09.13, 10:59

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

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

Автор: Ardi 17.09.13, 11:49

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

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

Автор: Vofka 17.09.13, 12:01

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

Автор: python 17.09.13, 12:36

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

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

Автор: Vofka 17.09.13, 12:39

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

Автор: Ardi 17.09.13, 12:47

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

Автор: Vofka 17.09.13, 12:51

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

Автор: Zaval 17.09.13, 13:49

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

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

Автор: python 17.09.13, 13:53

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

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

Автор: Домовик 17.09.13, 14:20

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

Автор: Zaval 17.09.13, 14:39

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

Автор: python 17.09.13, 14:51

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

Автор: Vofka 17.09.13, 15:15

Почему?

Автор: Домовик 17.09.13, 15:50

я, наверное, не понимаю, что имеется в виду у вас.

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

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

если в программе определена будет описана логика возможных вариантов по "развитию" документа РН, тогда можно будет не только строить журнал "реализация", а можно будет выводить другие формы.


но нужно предусмотреть вариант частичных оплат, отгрук..

Автор: Zaval 17.09.13, 15:54

Более сложно выдергивать данные.
Скорее всего, это только начало. Юзерам понравится, начнут еще придумывать
Да и без этого, получится длиннющий РС, по которому будут одновременно топтаться все юзеры

Автор: Vofka 17.09.13, 16:10

Не вижу проблем с этим. За то в обмен не будет излишних данных.

В случае регистра с контактной информацией - его беда в том, что поля называются Поле1, Поле2 ... ПолеN. Регистр этот был бы нормальным если бы поля назывались человекопонтяно либо если бы ресурс был 1, а взамен было 1 дополнительное измерение, которое идентифицировало бы конкретную составляющую адреса. Да, может быть тогда запрос получится не просто "ВЫБРАТЬ * ИЗ Регистр", может быть он будет дольше выполняться, за то в таблице базы данных все данные будут согласованы и не будет мусора. Это мое мнение.

Автор: Домовик 17.09.13, 16:12

имея дерево состояний нельзя будет, к примеру, просто так пометить на удаление документ, на котором завязаны другие документы. потому-что они будут уровнем ниже в дереве. также нельзя будет ввести просто так РКО, когда будет БВ с таким же движением. так как это тоже будет "перескок" на другую ветку.



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

Автор: Zaval 17.09.13, 16:19

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

Автор: Домовик 18.09.13, 6:28

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

дерево это ж вид графа. значит просто граф. направленный граф.

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

т. е уже формируются понятия

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


вобщем, логику по которой бухгалтера отслеживают движения документов, можно также программно задать. Не только задавать механизми отслеживания.