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

ник подходящий

Жирновато.

2 года 4 месяца.
Мне кажется шутник.
Или же Очередной открыватель родился?

Да и константой можно справочник заменить.
И вообще на бумажке вести учёт, понавыдумают тут программ...

Регистры напопления нужны, чтобы напоплять.

(0) Новые регистры в 1с появились?

А разве ветку Запрос не выполняется уже закрыли?
Или ты решил, что там тема не достаточно тупая для троллинга, и надо бы вбросить на вентилятор тему пожирнее?

Я н пойму. Ты набухался или просто тяжелый день вчера выдался?

Суть регистра накопления
v8: Чем Регистры сведений отличаются от Регистров накопления?

(0) Весь функционал есть в блокноте (бумажном), справочники, как и весь 1С излишни.

(0) зачем вообще что-то хранить в базе? можно вести файловый архив: выделяешь на диске определенное место, каталог, затем по каждому документы отдельный файл(создал документ - записал файл с уникальным айда документа), каждая перезапись документа - перезапись файла, там же и историю изменений можно хранить, очень удобно считаю. Плюс каждый день создавать папку с датой, тем самым создавая физическую периодичность.
По аналогии можно хранить и справочники и константы в отдельных папках соответствующие файлы.
Я считаю в базе вообще ничего не должно храниться, все во внешних файлах. Имхо так эффективнее.

(0) таких идейных тут за 20 лет было оочень много.

блин, я думал что такие вымерли еще в клюшках...

регистры нужны чтобы из движений автоматом получать итоги

(0) Сравните как быстро создадутся, допустим, 100тыс элементов справочника.

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

(10) это ты практически NoSQL переизобретаешь

(0) Для напопления же и нужны.
Подзадолбал уже

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

(0)
>Справочником, кстати, и документ можно заменить, и константу, и вообще что угодно.
Просто размышления 1С-ника, который SQL таблицы ниразу не открывал.
В 1С разделение идет по назначению объектов, а не можно\нельзя.

У нас в начале 2000х 2 парня поработали в нашем фране 2-3 месяца потом сколотили себе команду и написали зарплату на справочниках в организации гос аэронавигация.
Тогда и типовых то не было в республиках. Вот после таких и приходилось внедрять свои  ЗИКи да ЗУПы.

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

(20) А как же типовой документооборот, где Документ = Справочник?

(21) Компоповкой же!

(22) в ЗУПе тоже приколов всяких разных с синонимами объектов. видишь одно название, на самом деле сучность по-другому названа

кнопочкой специальной приходится пользоваться ... Информация для технического спецЫалиста

Запрос не выполняется
Уже представляю реализацию РН на справочниках от ТС

(0) Чтобы понять "зачем" - ты должен сам пройти этот путь.

Делай на справочниках. По ходу дела сам поймешь почему регистры.

(24) кнопка = для меня самая полезная вещь, которую добавили в платформе за последние 5 лет :)

Мой любимый вопрос - инцидент в системе техподдержки - это документ или справочник? )))

(28) Справочник конечно. Это же НСИ - база типовых инциндентов с их типовыми решениями =]

(0) можно, но сейчас уже не нужно, все объекты в 1с отличаются функционалом, это результат "эволюции", которым пользоваться удобнее, чем тем что был 20 лет назад. а кто то так и сейчас делает как ты говоришь, из за своей безграмотности. а еще раньше так работали и грамотные, потому что ничего больше не было, это их и натолкнуло, на то что надо бы развиваться и уходить от рутины. накопление - механизм, встроенный в платформу. сам говоришь, что можно "потом суммировать данные по каждому конкретному периоду в реквизите группы" - можно, но за тебя это уже сделали хлебнувшие радости люди, придумали регистр. это далеко не единственный плюс регистров. + их 4 вида.

(29) Это назывется  - угадай какое решение придумал автор

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

(29) Ага, типовой... "Я тут нажала и мы отправили 100500 миллионов налогов".
Абсолютна типовая ситуация ))

(32) > и бьёт морду кому ни попадя
Так вот почему Дениса этот вопрос так заботит... =)

> все пишут заявление в полицию
А вот это уже бизнес-процесс

Предлагаю тогда такое определение:
"Если инцидент требует каких-то движений, то это документ. Если не требует - справочник" =)

(33) а "запрос изменения" как думаете?

(34) Опять ты о своём наболевшем?
(35) Если инцидент не требует движений - это вообше ничто.

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

(28) >> инцидент в системе техподдержки - это документ или справочник?

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

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

Кстати у меня вот я как заметил личные проблемы, создаю РС когда нужно делать справочник, но я борюсь с собой =)

(39) О - я вижу и Вы любите РС вместо справочников.

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

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

(0) Дяденька, а вы точно не Калимулин?
Ну, замени РН справочниками. Потом для удобства работы оформи это как абстракцию более высокого уровня и назови ее РН. Круг замкнется.

(41) >> и Вы любите РС вместо справочников.

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

Вспоминается случай перевода одной разработки с 7.7 на 8.0. Так там заказчик принципиально требовал реализовать ему семёрочные периодические реквизиты справочника на справочниках. И ни в коем случае никаких регистров сведений не использовать. И сколько-то времени эта ересь прожила, пока не была всё таки переписана на периодические регистры сведений.

(40) >> создаю РС когда нужно делать справочник.

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

Вспоминается случай перевода одной разработки с 7.7 на 8.0. Так там заказчик принципиально требовал реализовать ему семёрочные периодические реквизиты справочника на справочниках. И ни в коем случае никаких регистров сведений не использовать. И сколько-то времени эта ересь прожила, пока не была всё таки переписана на периодические регистры сведений.

А разве нельзя было в справочник внедрить РС чтоб клиент даже не понял. Обычно так ведь и выглядит.

(45) >> разве нельзя было в справочник внедрить РС чтоб клиент даже не понял.

Конечно можно было. И в итоге именно так и было сделано. Но с согласия заказчика и чтобы не раздражать пользователей сменой интерфейса.
Даже кнопочки и формы похожие были нарисованы для редактирования "периодических реквизитов" (на самом деле - записей РС).
А просто обмануть заказчика нельзя было т.к. тот умел открывать конфигуратор и сам следил за разработкой. Его любимой фразой было что-то типа "Я тут самый главный программист и я решаю - как и что мы будем делать". Самый худший вариант - когда заказчик или начальник из бывших программистов.

(46) С такими заказчиками надо сразу прощатся.
Или надо промыть им мозги если он воспримчив к изменениям.

(47) >> С такими заказчиками надо сразу прощаться.

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

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

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

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

Пятничной теме быть?...