Доброго времени суток дамы и господа!

Пишу самописную конфигурацию для учёта обращений персонала. Функционал простенький, но с реализацией возникли проблемы.

При создании документа обращения производится запись в подчинённый периодический регистр сведений.
Далее другим документом должны рассматриваться обращения по отбору и проставляться им доп реквизиты. Для этого реализована подгрузка в табличную часть сведений по обращениям с незаполненными полями из регистра сведений.
Необходимо при проведении документа по рассмотрению обращений дозаписывать записи в регистр сведений по рассмотренным обращениям дополненными полями.
Хотел использовать процедуру ПриПроведенииНаСервере, но она не может обратиться к текущим полям табличной части(содержащим подгруженные из регистра обращения) в документе рассмотрения, т.к. ТекущиеДанные на клиенте.
Также немного не ясно как сделать отбор из регистра по записям из табличной части документа рассмотрения.

Заранее спасибо за помощь и потраченное время!
---
Зачем вам подчиненный регистр ?, сделайте независимый, и пишите уже туда хоть десятью документами, если вам нужно только передать данные из одного документа в другой, ( типа справочной информации) , а насколько я понял вам это и нужно...
Как вариант регистр накопления остаточный, приход один документ, допустим количество(ресурс) + 1 делает документ, при рассмотрении другой документ делает -1(расход) , выборка в таком случае по остаткам собирается...Реализации ваших задач куча..на самом деле...
---
Раз уж вам свойства надо заполнять раздельно, я бы сделал регистр, где свойство - отдельное измерение с предопределенными значениями "СрокРеализации", "ОтветственныйЗаРеализацию" и т.д. Тогда всё что надо решается, но работать будет менее удобно и кода больше, но правильнее и 1с-style.

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

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

При ресурсе - так работает срез последних в кадровой истории сотрудников, например.
Если нужны актуальные сотрудники на данный момент, то задается дополнительный отбор в ГДЕ.
---
Срез последних таки может содержать две записи, В общем случае - да. При использовании параметров виртуальной таблицы - нет.
Если нужны актуальные сотрудники на данный момент, то задается дополнительный отбор в ГДЕ. Вот именно. А перед этим виртуальная таблица строится по всем абсолютно сотрудникам.
В кадрах немного другая логика - количество сотрудников в фирме не растет с такой же скоростью, что и потенциальные "обращения клиентов в день". Соответственно - разная динамика роста количества записей в виртуальной таблице среза последних.
Если совместить прикладную логику (количество записей) и оптимальность запроса (использование точных отборов в виртуальной таблице) - я в данном случае за измерение.
Придется при установке нового статуса, предыдущую запись удалять и создавать новую - это определенный геморрой. Совсем нет. Надо просто перед проведением документа установить проверку текущего статуса обращения с отказом.
---
по сути тебе бы посмотреть как работает РМК, явно твой случай. Берешь свой док, запихиваешь в него все нужные для движения тебе реквизиты, вояешь не сколько форм типо: Поступление заявки, работа с заявкой и закрытие заявки, делее уже исходя из созданных тобой ролей приемщик видит одну форму, решала проблемы другую форму, и ну и кто закрывает другую форму, а движуху в твоем РС делает один док, как было озвучено в (2), и усе васякот.
---
Тогда возникает вопрос - а нафига тогда именно периодический регистр, если на каждом этапе документ тупо перетирает свои же записи?
---
для более удобного формирования отчётов по периоду
---
Для этого есть дата документа-регистратора.
---
к сожалению такой вариант не удобен. в таком случае придётся рассматривать каждый документ. В моём варианте в документ рассмотрения в табличную часть загружается сразу список обращений.
---
Вот и я говорю - каждый делает свои отдельные записи. Тогда и периодический регистр в тему, и срез последних по измерению "Рассмотрено" (Булево) - все в тему.
---
Вот у меня именно так и сделано сейчас, но как выбирать только не рассмотренные не могу понять.
Ведь Булево приписывается только к строке рассмотрения, а не к обращению.
---
А должно быть как минимум два измерения - "Обращение" (Справочник) и "Рассмотрено" (Булево). Вот и выбирай в запросе по условию Рассмотрено = ЛОЖЬ...
В чем проблема-то? И что значит "приписывается"?
---
Ну вот смотрите например колонки выглядят так:
Регистратор | НомерДокумента | Краткое содержание | Срок реализации | Рассмотрено
Обращение | 0000000001 | Суть вопроса | |
Рассмотрение | 0000000001 | Суть вопроса | 30/10/2020 | Истина

Как при обращении к регистру следующим обращением исключить уже рассмотренные?
---
Ужас. Создайте справочник "Обращение". Дату, номер, содержание, срок рассмотрения - все запихать туда.
В регистре оставить только два измерения - Обращение и Рассмотрено.
---
точно справочник? может документ?
---
Да хоть ПВХ. Дело ваше. Я же точно вашу логику и дальнейшие действия не знаю. Ваша предметная область, вы хозяин.
---
Логика в том, чтобы существовал документ рассмотрения и этому документу нужно получать все поля из документа обращения. Но только по не рассмотренным.
---
А проблема-то в чем? Вы не умеете пользоваться запросами и получать поля из других документов и справочников?
---
интересно, если я бы начал изучать код

где бы остановился :)

в понимании связей, логики, объектов, свойств и.......
---
Получить поле запросом не проблема. Думаете корректно обращаться каждый раз к перебору документов, а не записей в РС?
---
ШТОА?
Ну ок. Давайте уже свой код.
А то мы на разных языках говорим... Вы почему-то вдруг результат запроса называете перебором документов или записей РС...
---
подозреваю что это будет *овнокод :)
---
А что еще можно увидеть в случае, когда программист не знает принципов работы объектов метаданных, но при этом создает свою конфигурацию?
---
осталось подождать и увидеть результат
---
Так я получаю записи в документ рассмотрения на примере документа "Идеи", есть ещё другого типа документы с аналогичным функционалом, но другими полями, но мне хотя бы на одном документе правильную архитектуру понять:

```1c
    Процедура ЗаполнитьНаСервере()

    Запрос = Новый Запрос;
    Запрос.Текст =
    "ВЫБРАТЬ
    | Идеи.Номер КАК Номер,
    | Идеи.ДатаРегистрации КАК ДатаРегистрации,
    | Идеи.КраткоеОписаниеИдеи КАК КраткоеОписаниеИдеи,
    | Идеи.АвторИдеи КАК АвторИдеи,
    | Идеи.ТабельныйНомер КАК ТабельныйНомер,
    | Идеи.РешениеТехническогоСовета КАК РешениеТехническогоСовета,
    | Идеи.СрокРеализации КАК СрокРеализации,
    | Идеи.ОтветственныйЗаРеализацию КАК ОтветственныйЗаРеализацию,
    | Идеи.ОтветственныйЗаОбратнуюСвязь КАК ОтветственныйЗаОбратнуюСвязь,
    | Идеи.Комментарий КАК Комментарий,
    | Идеи.Подразделение КАК Подразделение
    |ИЗ
    | РегистрСведений.Идеи КАК Идеи
    |ГДЕ
    | Идеи.СрокРеализации = ДАТАВРЕМЯ(1, 1, 1)
    | И Идеи.Рассмотрено = ЛОЖЬ
    | И Идеи.Подразделение = &Подразделение
    |
    |УПОРЯДОЧИТЬ ПО
    | Номер";
    Запрос.УстановитьПараметр("Подразделение", Объект.Подразделение);

    РезультатЗапроса = Запрос.Выполнить();

    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();

    Объект.Идеи.Очистить();

    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
    НовСтр = Объект.Идеи.Добавить();
    ЗаполнитьЗначенияСвойств(НовСтр, ВыборкаДетальныеЗаписи);

    КонецЦикла;

    КонецПроцедуры
```

А вот как корректно дальше отразить эти записи, чтобы записи по данным документам повторно не заполнялись в другом документе рассмотрения - вопрос.
---
Вот эти вот предварительные ласки
```1c
    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
    Объект.Идеи.Очистить();
    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
    НовСтр = Объект.Идеи.Добавить();
    ЗаполнитьЗначенияСвойств(НовСтр, ВыборкаДетальныеЗаписи);
    КонецЦикла;
```
 заменить на мужское
```1c
    Объект.Идеи.Загрузить(РезультатЗапроса.Выгрузить());
```

А по сути даже разбирать не хочу. Какой-то Excel-style, а не регистр сведений. Я даже боюсь увидеть его фактическую структуру...
---
ну так закройте браузер и продайте компьютер. Здесь форум, для общения и решения вопросов, что за женственные эмоциональные всплески?

Вся компания 1С по Вашему пишет "эксельстайл", регистры типовых видели хоть раз, например ЗУП или ЗИК?

Эмоций много, подколов много - конструктива минимум. Это нормально когда кто-то знает что-то меньше других. Главное желание разобраться. Низко кичиться своим уровнем знаний и порицать знающих меньше.
---
Спасибо, взоржал.
---
да всё лишь бы людям коням было хорошо...
---
del
---
https://pro1c.org.ua/index.php?showtopic=6113

-----------------------------

много полезной информации для разработчика своей конфигурации
---
Раз уж вам свойства надо заполнять раздельно, я бы сделал регистр, где свойство - отдельное измерение с предопределенными значениями "СрокРеализации", "ОтветственныйЗаРеализацию" и т.д. Тогда всё что надо решается, но работать будет менее удобно и кода больше, но правильнее и 1с-style.

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

В документе при проведении
1. получаете срез последних на дату документа (тут лучше использовать МоментВремени или Границу, а не дату).
2. Делаете новую запись и заполняете поля полученными уже существующими на момент проведения данными из регистра.
3. Дополняете поля данными из этого документа.
4. Записываете полученную комбинацию как новую запись регистра.
---
сделал именно так, но потом при получении нового запроса
для заполнения не рассмотренных документов по срезу последних запрос собирает всё равно всех, не важно есть ли документ с таким же измерением или нет. Из-за добавленного поля с типом Булево он считает их одинаковыми и выгружает всё.
---
Всё, разобрался, всем спасибо!
Нужно было поле с типом булево переместить в реквизиты РС.