Привет всем.
Рассудите, плиз, спор.

Есть ЖКХ-шная самописная конфигурация, от 1С там мало что осталось. Используется 1с++, куча прочих ВК, даже интерфейс 8-чный. Конфигурация уже используется одной крупной фирмой не первый год, но сейчас мы ее переписываем под другого заказчика, с совершенно другими требованиями. Сохранить конфигурацию близкой к первоначальной - задача не стоит, так как уже изменения очень значительные.

Поспорили я и мой руководитель о том, как устроить регистр в этой новой конфигурации.

Я 1с знаю пока средне, но считаю себя достаточно сильным СУБД-шником. Руководитель СУБД-шник средний, но опытный 1с-ник.
Руководитель на мое мнение говорит, что я не понимаю тут именно специфики 1С, поэтому интересно, что скажет мировой разум
Специально не пишу, чья где точка зрения, и попытаюсь изложить все точки зрения  и варианты объективно.

Есть регистр остатков Взаиморасчеты. Какие в нем Измерения и Ресурсы на данный момент не важно, пусть будет Измерение - ЛицевойСчет и Ресурс - Сумма, для простоты.
Есть также реквизит регистра - ВидОперации.
Это перечисление, элементы которого на данный момент: Начисление, Оплата, ВводОстатков, Перерасчет, Прочие.

Далее выделяю капсом документы, которые также имеют отношение к вопросу(чтобы не путать их с регистрами).
По ВидОперации = Начисление пишут документы НАЧИСЛЕНИЕ. По ВидОперации = Перерасчет пишет документ ПЕРЕРАСЧЕТ. По ВидОперации = Оплата - ПЛАТЕЖИ, по ВидОперации = ВводОстатков и ВидОперации = Прочие - КОРРЕКТИРОВКА.

Помимо регистра Взаиморасчеты, есть оборотные регистры Платежей, Начислений и Перерасчетов. В каждом из регистров есть реквизит (соответственно регистру) ТипНачисления, ТипОплаты, ТипПерерасчета.
Документ КОРРЕКТИРОВКА в регистры, кроме Взаиморасчетов, не пишет, это просто документ для изменения данных регистра Взаиморасчетов (типа ввода остатков).

В ЖКХ есть такая пакость, как коррекция по общедомовым приборам. Оно делается несколько раз в год, и может быть как положительным (доначисление), так и отрицательным (снятие начисления). Доначисление делается документов НАЧИСЛЕНИЕ с  ТипомНачисления = Коррекция. Снятие - документом ПЕРЕРАСЧЕТ с ТипомПерерасчета = Коррекция.

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

1) Один из нас говорит, что никаких изменений делать не надо, отчеты нужно получать из объединения регистра Взаиморасчетов с регистром Перерасчетов и Начислений, и считать данные для столбца СуммаКоррекцияПоОбщедомовому по этим регистрам.
Обоснование:
1.1) коррекция не отдельный класс операций, а только подвид перерасчетов и начислений.
1.2) Так в перспективе можно схлопнуть регистр Взаиморасчетов до меньшего количества записей
Агрумент против:
1.1) будет работать медленно
1.2) Могут не сойтись данные Остатка на конец, так как суммы берутся из разных регистров

2) Другой говорит, что надо ввести новое значение ВидОперации = Коррекция, и писать его в регистр Взаиморасчетов из модуля документов Перерасчет и Начисление, если ТипНачисления или ТипПерерасчета = Коррекция. Тогда не надо лезть в другие регистры.
Обоснование:
2.1) быстрый расчет всех отчетов
Аргумент против:
2.1) Непонятно, почему выделять именно вид перерасчетов Коррекция. А если потом захотят выделять во всех отчетах по взаиморасчетам другие виды перерасчетов или начислений -  например По изменению проживающих, еще добавлять?

Что скажете? На чьей вы стороне?

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

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

Цитата:

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