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

(38) передача пересмотрена.

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

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

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

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

(30) Хз о чем ты

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

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

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

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

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

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

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

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

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

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

(47) смотри (37)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(63) самописка по учету лицензий

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

(56) как правильно организовать момент времени между списанием из одной организации и принятием в другую

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

хотят иметь справочник лицензий с номерами программных продуктов. остальное всё в регистр сведений
как узнать какие лицензии передали в конкретную организацию до момента подтверждения получения? аналог ордерного склада в УТ делать?:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(100) Не стоит оно того)

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

(93) потому что есть типовые отчеты, в которых можно обращаться к реквизитам через точку. А если прикрутить сбоку регистр сведений - то в отчет уже не выведешь.
Конечно, можно этот регистр спроектировать так, чтобы были как бы допреквизиты и прописать это в свойстве объекта. Тогда в отчетах на СКД допреквизит можно будет вывести. Но в старых системах типа УПП это не прокатит (там многие отчеты сделаны на построителе) - нужно будет пилить отчеты.

(102) Что суммировать собрался?

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

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

Сама по себе постановка вопроса противоречит методологии вендора.
Один из способов реализации - Остаточный РН.
Документом передачи текущий остаток закрываем в 0, на другую оргу - вешаем

И отчеты красивые будут

Измерения организация и сама лицензия. нну ресурс число 0 - нету 1 на организации.
Зато можно средствами СКД все отчеты которые в моем больном мозгу придумываются реализовать.

А с РС там придется изобретать велосипеды

Как показала практика - неявное изменение одной ссылочной сущности другой это очень очень не здорово и ведет к куче ошибок.
В конкретно данной задаче, если больше нет саркального смысла в реквизите Организация в справочнике Лицензии, вообще бы его удалил. (конфа не написана, считаю ее самопиской).
Получение организации текущей лицензии - запрос к оперативным остаткам это быстро
Отчеты - всякие графики перехода лицензий и тд - все будет строится тривиальнейшими запросами + СКД.

Ну а если совсем подумать о производительности - то оборотный регистр. На каждый день аренды - ставим единичку.
Но тогда с продажами надо будет какой то другой искать вариант.
Да будет дольше запись, будет больше данных, но аналитика: "Остаток на каждый день" (у кого в какой день была какая лицензия, по ней скорее всего по факту будут вестить какие то мероприятия) будет получатся простой выборкой из реальной таблицы. Так же будет очень тривиально получить средне дневное количество арендованных лицензий и тд

Все зависит от того как дальше эта информация будет использоваться

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

(114) Так это прокатит только если каждый элемент справочника - это физически отдельная лицензия / комплект (или аппаратный ключ). А если у них аппаратные ключи без разделения, т.е. элемент справочника один (ключ на 10), и таких ключей много, то не получится на РС без свистопляски как в (106), например

Может быть сделать через РС, в котором будут присутствовать сама лицензия, организация...
(а документ делает движения по регистру)

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

Это я понимаю. Я не понимаю нафига дублировать информацию.
Простейший запрос к РС (где уже есть вся инфа), даст аналогичный результат. Мутить регистр накопления только за ради посмотреть "сколько лицензий у контрагента" - бред.

(0) не правильно. Если писать просто в справочник, то:
1. никто потом не поймет, почему в этом элементе значение именно такое
2. при проведении задним числом весь учет пойдет по звезде
3. отмена проведения по идее должна что-то делать с тем, что было сделано при проведении, но ничего делаться не будет

В данном случае нужен периодический подчиненный РС с одним измерением. Документ должен складывать записи в него.

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

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

Во-вторых, решение о заполнении этого реквизита при проведении - тоже, мягко говоря, сомнительное.

(118) +100 Ну вот хоть одно вменяемое четкое и ясное мнение по теме за последние полсотни постов.

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

Как именно они себе это представляют?
У пользователя куплены основные поставки УТ, БП и ЗиУП.
Одна 10-типользовательская лицензия, одна 20-типользовательская, и 10 однопользовательских.
К каким именно программным продуктам должна быть привязана каждая из этих лицензий?

Походу у вас реальная каша в голове. Куча хотелок, но никто не понимает для чего, что и кому это всё нужно.

(115) Этого в ТЗ нет. Считаем что это не надо.
(118) Периодический РС - так себе идея, могу придумать пяток отчетов по где придется писать простыню и она будет не тривиальна (Например какое количество лицензий у нас будет занято через месяц). РС не даст такой информации тривиальным запросом - обороты дадут.
(117) 1с в стандартах разработки говорит - если для быстрого получения данных в отчете Вам нужен регистр - делайте его.

Так же для выставления счетов за использованные лицезии скажем за месяц будет проще получить обороты, нежели рожать данные из РС

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

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

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

(0) [при проведении... перезаписывать элемент справочника]
Отмена проведения должна отменять действия при проведении. То есть справочник придется возвращать в прежнее состояние. Что на это скажет программист?

+(127) По-православной методике от 1С надо писать эту информацию в периодический регистр сведений и из него же получать. Тогда соблюдется возможность обратного хода.

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

Поменяйте программиста, он(а) еще не отошел от периодических реквизитов в 1с 7.7.

(129) Пи...ть надо за такое программирование.

(130) Ну в 77 периодические реквизиты были примерно как регистр сведений
https://its.1c.ru/db/metod8dev/content/2588/hdoc

(131) За 15 лет существования 8-ки он мог бы и допереть до этого.

Уже несколько курьезных ситуаций написали, которые могут встать в полный рост при реализации через запись справочника (отмена проведения, проведение задним числом). Причем ее не сразу можно будет заметить, если работы с лицензиями не каждый день ведутся. Вопрос: почему ТС до сих пор не настучал программисту этими ситуациями, чтобы он сделал по-людски?

(133)ТС последний раз отписывался вчера утром, видимо убедил программиста аргУментами. А в теме до сих пор программисту уже нос ломают, коленки стреляют)))

(125) Исходя из опыта похожих задач - даю более 90% вероятности что такие отчеты потребуются.
А с РС на таких задачах - уже наелся.

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

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

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

(137) В любом случае правильнее работать с регистрами. Если правильно настроить - то количество будет узнаваться простейшими отчетами.

(138) с этим согласен. вопрос на каком регистре меньше кода при написании отчетов? как суммировать данные по регистрам сведений? как суммировать лицензии на базовые поставки?
как актуализировать регистры при добавлении в лицензии другой тип поля по которому нужно суммировать.
пример 1 базовая лицензия на конфу. 1 одна лицензия на поставку и 1 на рабочее место. БП +5 это 1 лицензия на поставку и 5 на рабочее место. Допустим они захотят ввести учет лицензий по  sql; нужно ли дописывать функционал или как правильно вывести отчет сколько у меня лицензий на рабочие места если у меня 1 лицензия "БП+5" 2 лицензии "БП базовая" и 1 лицензия на SQL сервер