должен ли документ менять справочники?

Ну да, а как иначе узнать в какой организации сейчас лицензия?

(2) Тогда правильным ответом будет - уберите поле организация из справочника

(4) не очень понятно

(3) Поддержу.
(4) Не знаю насчет ИТС, но...
2 справочника, 1 док-т. Текущий владелец лицензии виден в отчете со ссылкой на док-т. Для этого и есть (2) (регистр).

Документ не должен менять справочники.

(6) Да! Но двигается  - док-том. Поэтому - отчет. Ну, регистр.

(0) > должен ли документ менять справочники используемые в табличной части документа.

Такое вполне допустимо. Зависит от конкретной методики.
ИМХО, в данном конкретном случае - нет, не должен.

> правильно ли вообще что бы документы меняли справочники?

Однозначного ответа тут быть не может. Но лучше чтобы такого не было.

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

Справочники - это условно постоянные данные. А документ - это переменная.
Справочники должны менять те, кто за это ответственн

(13) Кто мешает в форме подбора сделать (11)?

(15) Справочник от слова "справка". Не строго?
И есть такие правила. Были, по крайней мере.
Справочник может выводить доп. инфу, но док-т справочник не меняет.
Правда, было это до появления 1С.

Регистр сведений уже предлагали?

(0) Не должен.
Справочник является хранилищем ПОСТОЯННОЙ или УСЛОВНО ПОСТОЯННОЙ информации.
Если что-то меняется - юзать в периодический регистр сведений!

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

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

Или сделать по другому при смене органиазции в справочнике, после утвердительного ответа на эту смену автоматически создавать документ передача, что бы вас не смущать:)

Или дописать еще и обработку подбора, что бы учитывать организацию из регистра а не справочника..:)

А то что получается, в справочнике лицензия у ООО Василек, а на самом деле в "Рогах с копытами".

если лицензия переходит от организации к организации, то логичней регистр сведений сделать

Как минимум вы теряете историю операций и сегодня распечатанный документ, сделанный вчера, показывает ерунду.

(22) да все уже сделано, вопрос в том, что Программист ТС ленивый, и не хочет сделать так, как правильно, а идет по пути наименьшего сопротивления.
Это как выбирать данные из ТЧ документа, а не из регистра.
Результат вроде один, но....

(0) > правильно перезаписывать элемент справочника с указанием новой организации так как лицензия всегда принадлежит какой то организации

Документ1 от 01.01.18 заполнил в справочнике Организация1
Документ2 от 10.10.18 заполнил в справочнике Организация2

Потом взяли и перепровели Документ1 (Документ2 больше не трогали). На регистры это никак не повлияет - сведения и остатки на нужные даты останутся корректными. А что будет в справочнике? А в справочнике будет фигня в виде Организация1.

Или ты неверно формулируешь проблему, или твой коллега заблуждается.
Одним из обязательных условий при проектировании документов и регистров является сохранение корректности данных при движении обратным ходом (проведение задним числом и т.п.). Для этих целей в 1С понапридумывали всякую муть типа последовательностей, которые необходимо контролировать. Но, во-первых, в последовательности не включают тупо все объекты подряд. А во-вторых (и самых главных) последовательности не умеют контролировать справочники. Они только за регистрами умеют следить.

(0) Более правильно - хранить историю. Перезаписывать данные в справочнике - плохой вариант. Потому как обязательно встанет вопрос: "А что там у нас было на определенную дату?".

(26) "Верионирование" или "История данных" отвечают на такой вопрос, либо даже тупо в ТЧ самого объекта хранить историю смены его реквизита-организации

(29) Это плохой, никуда не годный вариант. если бы ты был моим подчинённым - я бы лишил тебя премии за такое предложение

(28) Регистр накопления не предназначен для хранения периодической информации
Как и говорили выше, вам нужен периодический регистр сведений

(32) А накопление тебе зачем?

(33) накопления уже есть

автор, ты вообще типовые видел? Возьми, например, основное средство и посмотри как сделано. И главное программисту подскажи где надо посмотреть.
PS просто интересно - какая ЗП у программиста?)

(32) если уже есть, откуда получить данные, зачем еще один регистр делать? для удобства  если только

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

(27) > есть где прочитать про сохранение корректности литература?

Где-то я с этим сталкивался. Но где именно не скажу. Не факт что в документации (может какие-то отдельные статьи или курсы).
Но вообще-то это здравая логика подсказывает. Любое телодвижение пользователя должно возвращать корректный результат (в том числе проведение документов задним числом). Во всех исключительных случаях (когда результат некорректен) либо такие действия должны быть запрещены пользователю, либо нужен настроенный механизм каким-то образом их контролировать (например, при помощи последовательностей).

регистр сведений, не?

(40) передача безвозмездная (дарение) или по договору безвозмездного пользования (ссуды)?

по идее передача НМА особо ничем не будет отличаться от передачи ОС, если у вас подобное практикуется.

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

(30) Хз о чем ты

(43) Ты предсказуем

(32) > какие лицензии за какой организацией закреплены.

Логично, что такая информация нужна.

> сколько рабочих мест на каждой организации?

А это зачем? Организация имеет 20 десятипользовательских  лицензий (всего - 200 штук). Как эта информация связана с количеством рабочих мест? Откуда вы знаете как именно эти лицензии активированы (по компам или по сеансам)? Откуда вы знаете на каких серверах установлены эти лицензии - может 100 лицензий на одном серваке и ещё 100 - на другом. И есть пользователи, которые тусят на одном сервере, есть те, кто тусит на втором, и есть те, кто лазят на оба сервера. А может вообще половина из этих лицензий на полочке лежит неактивированными.

Короче говоря, какая-то каша в голове ваших постановщиков. Походу дела вы сами не знаете - что вы хотите учитывать и для чего. Если не в состоянии показатели состояния (регистры сведений) от показателей остатков и оборотов (регистры накопления) отличить.

Вывести в периодический РС, реквизит "Организация" в форме объекта лицензии скрыть, на его место добавить текущее значение регистра с кнопащкой "История" рядом. Документ при проведении пишет в этот РС новые значения.

И жизнь наладится.

Кстати, да, а на кой ляд РН вообще?

(0) вопрос должен ли документ менять справочники используемые в табличной части документа.
Должен ли человек на форуме задавать абстрактные вопросы?

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

По теме "отбор в списках по реквизиту" - это удобно и быстро, особенно хорошо, что это доступно на неуправляемых формах. Но делается это всё равно через регистр сведений, куда пишет документ. Никакие пляски с историей в ТЧ справочника не обеспечивают целостность данных. Запись в регистр регистратором  - это надёжность, простота и прозрачность. А подпиской / менеджером записи / периодической перезаписью (предпочтительно) элементов справочника по изменениям в регистре сведений - это единственный мне известный верный и простой способ выполнить задуманное.

(52) Что за периодическая перезапись?

(49) Да, да, да! Перечитай внимательно (37) и ответь на вопрос - на кой ляд нужен регистр накопления?
Если уже есть регистр сведений, отражающий сведения о лицензии (количество РМ, тип, организация, период действия и т.п.), то наличие РН - как минимум ставит вопрос об избыточности (дублировании).

Хотя конечно, чтобы полноценно рассуждать на эту тему необходимо видеть постановку на реализацию и текущую модель - структуру регистров и связанных объектов. Нельзя исключить, что вам действительно нужны за каким-то лешим оба регистра.

(54) Так остаток чтоб получать.
Несколько же записей у одной и той же организации, хочется в сумме видеть сколько.

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

(56) Как это ты срезом РС собрался получать итог?

(57) а агрегатные функции в запросе что работать не будут?

(58) Так в срезе-то только последняя запись будет (по каждой комбинации измерений). А лицензии-то на одну и ту же организацию могут быть куплены в несколько заходов, т.е. несколько записей.

В срезе будет состояние лицензий на текущую дату,а что еще надо?

Про типовой ЗУП 3.0. уже говорили?
Должен ли менять документ справочник, должен ли документ менять документ в закрытом периоде.
На мой взгляд если идет спонтанное развитие конфигурации то все возможно. И все регламентируется не правилами, а приоритетом в текущем списке задач. Если топик стартер хочет что-то изменить в системе он должен описать задание и добавить его в список разработки.
+1 к спрятать в справочнике поле организация и выводить его из регистра.

(60) Отменили / перепровели документ покупки задним числом - состояние изменилось

(0) Есть ли RLS по этому справочнику? Или это самописка? Аналогия со справочником расходы будущих периодов, основные средства.
Документ - отражение хозяйственной операции, вы передали лицензии от организации 1. Пакет документов был отправлен почтой и успешно утерян\украден\сгорел по пути, организация 2 их не получила. На каком основании менять реквизит?

Правильно отражать поступление, списание, каждый раз при поступлении создавать новый элемент справочника.

Вот захотят бухгалтера видеть в УПП инвентарный номер ОС в ОСВ по счету 01 и приходится добавлять реквизит и заполнять его при проведении. А желание вполне у них адекватное.

(64) Вроде в универсальный отчет "теплые ламповые" доп. реквизиты типовых (на ПВХ и регистре сведений которые) на ОФ штатно подтягиваются, не?

Вместо справочника Регистр сведений периодический.
Измерение: Лицензия.
Ресурс:Организация.
Реквизит: Документ передачи лицензий

(59) рс основные спецификации номенклатуры работает и не жужжит же. Хочешь по номенклатуре, хочешь на дату

(71) Ты о чем? Он про получение итога срезом, бгг

(70) Ну если надо фиксировать как выбытие, так и прибытие с отсрочкой, то без "товаров в пути" и двух записях, очевидно, никак. Хотя вон бери пример с товарных регистров линейки ЕРП - два ресурса "В наличии" и "К отгрузке", бгг

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

(74) Скажи это товарищу из (60) )

(12) я видел конфы, в справочниках, которых хранятся цены... на вопрос почему так - ответ, пришел мальчик - сделал так - показал нам, мы довольны... все работает.

(0) может, если предусмотреть откат ситуации при распроведении актуального документа, и прочие манипуляции с последовательностью.

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

Из минусов, вероятность конфликта блокировки элемента справочника в момент редактирования его пользователем.

Все зависит от того, готов ли заказчик платить за правильность и легкость последующих разработок.

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

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

А если каждый показатель тягать из регистра на текущую дату - динамический список вешается от таких нагрузок.

Либо теряем отборы в динамеческом списке и придется самому реализовывать настррйки динамического списка :)

А зачем постоянно что-то тягать в динамический список? он что постоянно на экране где-то крутится? тем более если все это в РС хранится, то списки из этих РС нужны только как отчеты и при редкоих событиях передачи лицензий. Не умрут...

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

Я как то задавался вопросом, почему для запроса по периодическому регистру к последнему состоянию происходят какие то доп.расчеты. С точки зрения, что это отдельная таблица, то вроде ничего лишнего не должно быть. Но оно почему то все равно запускает тормозные расчеты соразмерные с выборкой срезов на прочие моменты. Очень похоже на кривые мозги у тех, кто делает платформу.

(49) Тогда, если есть РН, не нужен РС. Вообще, постановка задачи корявая малость, если у тебя каждая лицензия - отдельный объект, обязательно принадлежащий какой-то одной организации в момент времени, то РН ни к чему (по аналогии это ОС). Если лицензия может в двух экземплярах, например, принадлежать одной организации, а в пяти - другой, то РН как раз-таки нужен, по сути эта лицензия - обычный ТМЗ со всеми вытекающими.

(83) "Расчет для проведения при отмене последнего - запросом по документам, который из них остается последним."

- имхо бяка. правильнее сделать еще один документ передачи в "обратном" направлении.

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

(0) Делаете периодический регистр сведений, вот его и пусть документ меняет.

А насчет изменения справочника... ситуация: документ провели задним числом. Что у вас в справочнике будет? Фигня! Кому вопрос зададут? Программисту.

(19) Только отчет будет неправильный. Т.к. будет показывать текущее значение реквизита, а остальные реквизиты - по состоянию на прошлый период.

(65) в УПП не подтягиваются, но это полбеды. Кто будет заполнять это значение после принятия к учету ОС вручную в допреквизите? Это какая-то сомнительная автоматизация.

Доп реквизиты ничем не отличаются от обычных (в рамках данной задачи)

Я не очень понимаю,почему народу не нравится периодический регистр сведений?
Если документ делает движения,то они на какую то дату,и при отмене документа запись на эту дату исчезает и остается предыдущая запись,причем,это автоматически происходит-для этого регистры сведений и придумывали.
тут только одна проблема-в регистре нельзя указать организацию,с которой идет передача,т.к.она определяется по срезу на момент проведения документа-с другой стороны,нет маразма,когда сначала передали с организации А на Б,а потом с В на Г,и в отчете отрицательные значения-но это будет,если кто-то захочет регистр накопления впендюрить.

(93) "в регистре нельзя указать организацию,с которой идет передача"

Кто мешает сделать ещё реквизит и считать его при записи?

(93) Потому что на РС не получить итог без обращения к основной таблице регистра

(95) если на текущую дату - то можно

(96) Походу ты не прочел или невнимательно прочел (59). Или ты  в РС собрался писать каждый раз нарастающий итог?

(97) разные лицензии - это разные строки

(98) А Лондон - столица Великобритании

(99) Начинай уже думать )))