Передача данных из регистра в реквизит справочника по условию
Добрый день
Подскажите пожалуйста как сделать передачу данных суммарного показателя из регистра накоплений или регистра сведений в реквизит формы
Конфигурация самописная, ЗУПа нет что бы глянуть код там.
Есть документы ОтпускСотрудников, он фиксирует в 2 регистрах данные по количеству дней
Вроде с этим проблем не было все получилось
Но теперь проблема перенести итоги в справочник сотрудников.
Хотелось отразить общее количество затраченных дней отпуска в 1 месте в карточке сотрудника, но чет вообще не идет.
Конфиг прилагаю
Документы.ОтпускСотрудников
РегистрСведений.СведенияПоОтпускам
РегистрНакоплений.РасходПоОтпускам
Справочники.Сотрудники.Реквизит Количество потраченных дней вот сюда цель добавить сумму по регистру
Буду очень благодарен за помощь и разъяснения, только учусь.
Подскажите пожалуйста как сделать передачу данных суммарного показателя из регистра накоплений или регистра сведений в реквизит формы
Конфигурация самописная, ЗУПа нет что бы глянуть код там.
Есть документы ОтпускСотрудников, он фиксирует в 2 регистрах данные по количеству дней
Вроде с этим проблем не было все получилось
Но теперь проблема перенести итоги в справочник сотрудников.
Хотелось отразить общее количество затраченных дней отпуска в 1 месте в карточке сотрудника, но чет вообще не идет.
Конфиг прилагаю
Документы.ОтпускСотрудников
РегистрСведений.СведенияПоОтпускам
РегистрНакоплений.РасходПоОтпускам
Справочники.Сотрудники.Реквизит Количество потраченных дней вот сюда цель добавить сумму по регистру
Буду очень благодарен за помощь и разъяснения, только учусь.
Прикрепленные файлы:
Konfig.cf
По теме из базы знаний
- Перенос данных из УПП 1.3 / КА 1.1 в БП 3. Переносятся документы, справочники и начальные остатки
- Пример создания в КД 2.1 правил выгрузки данных регистра «Лицевые счета работников» из ЗУП 2.5 в справочник «Банковские счета» БП 3.0. Подробно, ясно и просто.
- Универсальная печатная форма для справочника и документа по своему шаблону, сделанному в ms word: Кадровые, Торговые, Делопроизводственные, Бухгалтерские, Управляющие
- Блокировка элементов справочников от изменений
- Универсальный обмен данными между конфигурациями через http-сервис
Найденные решения
Что у вас творится при сочетании этих 2-х регистров с одним видом документа боюсь даже подумать.
А о том, что такое "суммарный показатель" регистра сведений не буду даже догадываться.
Поэтому просто примем на веру, что вы все же можете получить данные из ваших регистров по тому, кто, что и когда отгулял/будет гулять.
У вас же все работает?
Ведь работает?
Да?
1. Не путайте реквизит справочника и динамические данные.
Почитайте, что рекомендуется хранить в справочниках, а что в документах, регистрах и т.п.
Чтобы долго не спорить - хранить число потраченных дней в справочнике можно, но не надо, совсем, никогда.
2. Вы же учитесь, поэтому запомните, что "карточки" есть у пользователей, у вас же формы.
3. Исходя из п.1 - создайте реквизит ФОРМЫ (не путать с реквизитом справочника), например, вида "надпись" и при создании формы на сервере выводите сюда данные запроса к вашим регистрам.
Это не очень хороший совет,, т.к. в таком случае придется решать, как часто обновлять (считай дергать базу) этот самый реквизит. Особо "забавно" это делать, если кто-то открыл форму и ушел в закат.
Да и разово тоже большой вопрос - т.к. эти данные могут понадобиться не только чтобы не всем, но и не всем всегда :)
4. Подумайте зачем нужны отчеты, ежели "всё можно в карточке показать", боюсь запутать совсем, но никто не мешает выводить явно/или неявно (как в п.3) отчет в форме того же справочника, но тогда надо уметь готовить этот рататуй.
А о том, что такое "суммарный показатель" регистра сведений не буду даже догадываться.
Поэтому просто примем на веру, что вы все же можете получить данные из ваших регистров по тому, кто, что и когда отгулял/будет гулять.
У вас же все работает?
Ведь работает?
Да?
1. Не путайте реквизит справочника и динамические данные.
Почитайте, что рекомендуется хранить в справочниках, а что в документах, регистрах и т.п.
Чтобы долго не спорить - хранить число потраченных дней в справочнике можно, но не надо, совсем, никогда.
2. Вы же учитесь, поэтому запомните, что "карточки" есть у пользователей, у вас же формы.
3. Исходя из п.1 - создайте реквизит ФОРМЫ (не путать с реквизитом справочника), например, вида "надпись" и при создании формы на сервере выводите сюда данные запроса к вашим регистрам.
Это не очень хороший совет,, т.к. в таком случае придется решать, как часто обновлять (считай дергать базу) этот самый реквизит. Особо "забавно" это делать, если кто-то открыл форму и ушел в закат.
Да и разово тоже большой вопрос - т.к. эти данные могут понадобиться не только чтобы не всем, но и не всем всегда :)
4. Подумайте зачем нужны отчеты, ежели "всё можно в карточке показать", боюсь запутать совсем, но никто не мешает выводить явно/или неявно (как в п.3) отчет в форме того же справочника, но тогда надо уметь готовить этот рататуй.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Что у вас творится при сочетании этих 2-х регистров с одним видом документа боюсь даже подумать.
А о том, что такое "суммарный показатель" регистра сведений не буду даже догадываться.
Поэтому просто примем на веру, что вы все же можете получить данные из ваших регистров по тому, кто, что и когда отгулял/будет гулять.
У вас же все работает?
Ведь работает?
Да?
1. Не путайте реквизит справочника и динамические данные.
Почитайте, что рекомендуется хранить в справочниках, а что в документах, регистрах и т.п.
Чтобы долго не спорить - хранить число потраченных дней в справочнике можно, но не надо, совсем, никогда.
2. Вы же учитесь, поэтому запомните, что "карточки" есть у пользователей, у вас же формы.
3. Исходя из п.1 - создайте реквизит ФОРМЫ (не путать с реквизитом справочника), например, вида "надпись" и при создании формы на сервере выводите сюда данные запроса к вашим регистрам.
Это не очень хороший совет,, т.к. в таком случае придется решать, как часто обновлять (считай дергать базу) этот самый реквизит. Особо "забавно" это делать, если кто-то открыл форму и ушел в закат.
Да и разово тоже большой вопрос - т.к. эти данные могут понадобиться не только чтобы не всем, но и не всем всегда :)
4. Подумайте зачем нужны отчеты, ежели "всё можно в карточке показать", боюсь запутать совсем, но никто не мешает выводить явно/или неявно (как в п.3) отчет в форме того же справочника, но тогда надо уметь готовить этот рататуй.
А о том, что такое "суммарный показатель" регистра сведений не буду даже догадываться.
Поэтому просто примем на веру, что вы все же можете получить данные из ваших регистров по тому, кто, что и когда отгулял/будет гулять.
У вас же все работает?
Ведь работает?
Да?
1. Не путайте реквизит справочника и динамические данные.
Почитайте, что рекомендуется хранить в справочниках, а что в документах, регистрах и т.п.
Чтобы долго не спорить - хранить число потраченных дней в справочнике можно, но не надо, совсем, никогда.
2. Вы же учитесь, поэтому запомните, что "карточки" есть у пользователей, у вас же формы.
3. Исходя из п.1 - создайте реквизит ФОРМЫ (не путать с реквизитом справочника), например, вида "надпись" и при создании формы на сервере выводите сюда данные запроса к вашим регистрам.
Это не очень хороший совет,, т.к. в таком случае придется решать, как часто обновлять (считай дергать базу) этот самый реквизит. Особо "забавно" это делать, если кто-то открыл форму и ушел в закат.
Да и разово тоже большой вопрос - т.к. эти данные могут понадобиться не только чтобы не всем, но и не всем всегда :)
4. Подумайте зачем нужны отчеты, ежели "всё можно в карточке показать", боюсь запутать совсем, но никто не мешает выводить явно/или неявно (как в п.3) отчет в форме того же справочника, но тогда надо уметь готовить этот рататуй.
(2)Спасибо большое за разъяснения
По регистрам у меня вроде все прописывается, без дублей, ровно по каждому документу. Сидел проверял ну я так думаю, может я неуч еще тот)))
А за реквизит формы и справочника спасибо, просто думал, что так удобнее для пользователя, не нужно постоянно открывать отчет, а оказывается она гонять запросы будет по базе каждый раз при открытии как я понял.
Спасибо большое еще раз за растолкование, до СКД не дошел но мелком проходил помню как там искать.
А все регистры я делал по урокам, единственное не понимаю различия между "в пределах секунд" и "в пределах года" периодичность что ведется это я понял но в чем различие не понимаю)
По регистрам у меня вроде все прописывается, без дублей, ровно по каждому документу. Сидел проверял ну я так думаю, может я неуч еще тот)))
А за реквизит формы и справочника спасибо, просто думал, что так удобнее для пользователя, не нужно постоянно открывать отчет, а оказывается она гонять запросы будет по базе каждый раз при открытии как я понял.
Спасибо большое еще раз за растолкование, до СКД не дошел но мелком проходил помню как там искать.
А все регистры я делал по урокам, единственное не понимаю различия между "в пределах секунд" и "в пределах года" периодичность что ведется это я понял но в чем различие не понимаю)
(4)
У вас в РС есть служебный реквизит "Период".
Гранулированность записей в т.ч. зависит от настройки периодичности.
Например, если установлена периодичность "Год", то Период = 01.03.2027 равен Период = 15.12.2027 - для наглядности считайте, что оба этих периода будут храниться как 01.01.2027.
Если остальные значения ключа будут также равны, например, Пользователь = Иванов, то система не даст вам добавить новую запись.
(4)
Ну, если в событии "при создании", то да, но никто не мешает создать, например, отдельную страницу на форме, назвать ее скажем "текущее состояние" и выводить туда данные только при смене текущей страницы на эту - это кривовато, но рабочий вариант.
И если надо заполнить только несколько показателей, то СКД вам вообще не понадобится.
Достаточно получить нужные данные запросом.
Но в учебных целях - да. Лучше сделать через одно место, но освоить СКД.
не понимаю различия между "в пределах секунд" и "в пределах года"
У вас в РС есть служебный реквизит "Период".
Гранулированность записей в т.ч. зависит от настройки периодичности.
Например, если установлена периодичность "Год", то Период = 01.03.2027 равен Период = 15.12.2027 - для наглядности считайте, что оба этих периода будут храниться как 01.01.2027.
Если остальные значения ключа будут также равны, например, Пользователь = Иванов, то система не даст вам добавить новую запись.
(4)
а оказывается она гонять запросы будет по базе каждый раз при открытии как я понял.
Ну, если в событии "при создании", то да, но никто не мешает создать, например, отдельную страницу на форме, назвать ее скажем "текущее состояние" и выводить туда данные только при смене текущей страницы на эту - это кривовато, но рабочий вариант.
И если надо заполнить только несколько показателей, то СКД вам вообще не понадобится.
Достаточно получить нужные данные запросом.
Но в учебных целях - да. Лучше сделать через одно место, но освоить СКД.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот