Есть задача создать документ по расчету стоимости РАЗНЫХ услуг ЖКХ(тепло, электроэнергия, вода, стоки, мусор) в том числе телефония и интернет.
Пробовал создать универсальный документ но колонок становится слишком много (их не удобно заполнять) ну и конечного алгоритм обработки становится сложнее чем обычно.
Как в этом случае лучше поступить?
Создать разные документы в конфигурации или создать несколько ТЧ или ...?

(0) разные

Зависит от зависимости сущностей. Можно иногда просто по виду операции скрывать или показывать колонки

колонок уже более 10,сейчас уже так и делаю

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

Разные ТЧ.

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

№|ВидУслуги|ПараметрыУслуги|...

А ПараметрыУслуги это Соответствие например сериализуемое в строку или еще как.

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

Типа
Основная ТЧ
Электроэнергия Т1   500 квт по тарифу 1.14 сумма 570,00

Вспомогательная ТЧ
Показания счетчика на начало 11500
Показания счетчика на конец  12000
Разница в показаниях 500
Тариф 1,14
и т.п.

(7) Можно и так две ТЧ, но в этом случае со связью по ключу программное заполнения/обработка документов усложняются сильно

(8) Конечно усложняется. Но что мешает реализовать где-нибудь в модуле объекта/менеджера вспомогательные процедуры упрощающие таковую обработку? На вход можно подавать хоть ТЗ с 1000 колонок, которая в итоге будет раскладываться в две ТЧ.

В ряде конфигураций, такой документ вообще не содержит ничего, кроме движений..

А может сделать несколько ТЧ в зависимости от вида услуг и показывать их в зависимости от выбора пользователя?

А вообще, я бы порекомендовал изучить ЗУП и его "виды расчёта". Мне кажется, это наиболее близко к ЖКХ

(11) Отталкивайся от печатных форм (квитанций) для клиентов.

Если там в одной таблице - можно одну ТЧ, если разные таблицы то лучше разные ТЧ

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

(14) Это имеет смысл если надо по этим параметрам в документах искать.

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

зачем по ним искать?

(16) Правильно поэтому нафуй отдельную ТЧ и (5) все засовываем в одно поле

(17)+ https://programmist1s.ru/znachenievstrokuvnutr-i-znachenieizstrokivnutr/
или
http://v8.1c.ru/o7/201501json/index.htm

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

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

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

Вопрос конечно интересный и ответ достоин целой статьи. Лет десять назад я как раз этим занимался, но потом подзабросил.

Если кратко, то:

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

2. Ориентироваться нужно не на форму списка, а на форму элемента.

3. Лично мне более привлекательны не ТЧ и не документы, а моделирование документов с помощью основного и подчиненных справочников.

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

В свое время у меня была самописная конфигурация на 1С77 «Учет ресурсов». Мне нравилась, но типовая конфа (в данном случае ПУБ-7.7) оказалась более функциональной, хотя местами и менее удобной и с приходом нового главбуха была перевнедрена. Если бы это было нужно лично мне, то я бы развивал свою программу на основе изложенных принципов. Зато мою «зарплату» главбух перевнедрить не смогла, и конфа пашет, как рабочая лошадка, до сих пор. Там тоже все «1С:Несовместимо» и полностью оригинально.

P.S. Поискал в Интернете ссылки на самого себя и вот что нашел:

«Господин ПЖ» в 2009 году сделал здесь на меня ссылку (
Проектирование: Забористая трава... Натуральный учет ). В этой теме «Ненавижу 1С», в посте № 39 оставил запись: « а картинка красивая http://www.sql.ru/forum/actualthread.aspx?tid=697184&pg=2#7693188 ».
Там эта «картинка» расположена в посте https://www.sql.ru/forum/697184-2/naturalnyy-uchet#7693188 .
В общем, если было бы достаточно внешнего стимула, то эта тема и конфигурация могли развиваться и дальше, ибо актуальности не потеряли до сих пор. Естественно не конкуренции ради с серьезными фирмами, а что-нибудь попроще, «для себя».

(0) Посмотрите в ЗУП 3 документ "Изменение плановых начислений". Там 3 связанных табличных части. Визуально редактируется только одна ТЧ, которая дополняется произвольным набором связанных колонок(т.е. в одной строке могут быть 100500 видов расчетов со всеми показателями). Однако, это довольно сложно и громоздко реализовано. Я примерно неделю потратил, что только разобраться, как оно работает(для специфической доработки).

Универсальный документ - зло.
Делайте АРМ.

А за ним множество максимально простых документов.
Это намного проще в разработке и поддержке

Иначе получите дичайшее легаси.

(22) только 1с может себе позволить иметь в багтрекере по готовому решению 300+ ошибок, которые не исправляются годами, а Вы нет

(0) универсальный документ - это, как бег в мешке: по началу весело, но рано или поздно упадешь и разобьешь харю.
Делай разные документы, не телепи мозг.

(21) голимое клюшкодавство

(28) Без нескольких ТЧ в доках в 77 сложно было да

(0) Если уж очень хочется универсальности, то реквизит типа ХранилищеЗначения. Туда запихнуть можно что угодно: сколько угодно реквизитов и таблиц. Но придется пожертвовать многим: запросами, доступом к реквизитам. Можно организовать регистр сведений, в котором хранить ссылку на объект, вид принадлежности реквизита (шапка, табличная часть такая-то), наименование реквизита, значение. Но тоже будут жертвы.

(30) http://s5.pikabu.ru/post_img/2014/06/19/5/1403154705_1339773392.jpg

(31) Ты еще в (5) почитай "В ячейку можно записывать целиком ТЗ" или "нафуй отдельную ТЧ ... все засовываем в одно поле" из (17) :D

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

(32) это how know

(31) Я вот эту люблю: https://cloud.mail.ru/public/54ea/p3wbQAhDx

(33) Что за симка и что за переезд? Ты точно в ту ветку написал?

(26) Если перефразировать, кто тут без технического долга, бросьте в фирму 1С камень. Все реально, только времени много понадобится на выпиливание. Но, конечно, такие "эксклюзивы" без предоплаты/гарантии и полной заинтересованности заказчика лучше не делать.

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

(38) Не отрицаю, перфекционизм никто не отменял.

(39) Но это скорее всего функционал, не связанный с изменениями законодательства.

(36) точно. Когда пойдут уточнения, сроки улетят в трубу, теряем клиента. Когда посмотрят код - работодателя

(41) вы пьяны, сударь?

(41) Ясно, понял, спс за разъяснения ))

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

Простейшие примеры халатности, что можно было бы выявить при желании
https://bugboard.v8.1c.ru/error/000051071.html
https://bugboard.v8.1c.ru/error/000050993.html
https://bugboard.v8.1c.ru/error/000050421.html
https://bugboard.v8.1c.ru/error/000048687.html
4 из 20 на первых 2х страницах никак не связаны с отраслевой спецификой.
Дальше не смотрел

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

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

Кстати, "более 10 колонок", если их сразу на пользователя не вываливать, ну ни разу не кажется большим числом. Собственно, все многообразие коммунальных платежей по определению вмещается в рамки утвержденной формы платежного поручения, а реквизитов в платежке не так чтобы очень много.

(46) >Я бы людей, которые нарушают 1ю нормальную форму, гнал из профессии ссаными тряпками

Какие умные слова мы знаем.

А про NoSQL вы слышали хоть краем уха?
Или возмущение потому что нельзя будет все через ж... запросами делать?

Какой смысл хранить эти параметры/коэффициенты/показатели отдельно а не вместе?
Они на другие "счета" не влияют и действуют только внутри документа для него одного.
Все вычисления происходят для каждого документа отдельно, не затрагивая другие и вместе со всей строкой, наоборот очень удобно и быстро, минимум обращений к БД получается.

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

(47) распредели квартальные 100р на тех у кого нет счетчика в такой модели. Когда сделаешь, они передумают и уточнят, что нет онлайн счетчика и учесть тех кто уехал т.е. меньше 2 киловатт. На каждый чих простыни неподдерживаемого кода

(48) ТЗ ячейке это один из вариантов и да не самый лучший.
Лучше просто строковое поле в ТЧ и внутри хранить JSON с нужными данными.

(49) Не вижу никаких проблем распределить и тем более без простыней кода/запросов когда в одном пытаются универсально все на всех сразу засунуть.

Чтобы распределить на каждого надо знать общие/суммарные показатели (не забываем что "меньше 2 киловатт" тоже распределится но на других кто не уехал) их лучше хранить отдельно готовыми а не получать каждый раз сводно.

Ну и банальный цикл по "документам" берем нужные для каждого коэффициенты и зная общие высчитываем сколько из "квартальные 100р" на каждого будет.
В т.ч. если "меньше 2 киловатт" = 0

(51)+ Кстати метода https://ru.wikipedia.org/wiki/MapReduce сюда ложится просто идеально!

(52)+ В смысле при проведении "документа" не забываем в регистры суммарные показатели писать

(51) "отдельно готовыми" это и есть тот звоночек который фо хум зе бел толлс

(54) Скажи что мешает в процедуре проведения взять значение (строковое) из ячейки, получить несколько значений (нужных типов) из него и засунуть их в нужные регистры?

Вы уже в отраслевку скатились.
Универсальность как правило неподдерживаема, любое изменение может вывести систему из равновесия.
ИМХО, тут одно принятие архитектурного решения не на один день)
Я за АРМ с большим количеством документов за фасадом. Легко работать, легко поддерживать, легко потом из одного арм сделать много.
(52) Такой распределенный СКД, где значение каждой группировки на отдельной ноде считается и потом это склеивается, но боюсь при корреляции данных, а тут она будет - неприменимо.

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

Угу это реально шустро и параллельно

(57)+ https://ru.wikipedia.org/wiki/CouchDB изучал в свое время, прикольная штука для подобных задач

(57) но голоса в моей голове говорят, что там будет межгруппировочная корреляция

(59) Пример бы подобной корреляции

(60) Я с жкх не работаю, но по текущему направлению:
Комиссия может быть процентом от суммы оплат - авансы, но авансы не все, а некоторые)))

А может быть фиксированным значением, а может быть процентом от всех оплат без учета авансов

(61) В смысле комиссия для одного зависит от оплаты другими?
Так это же сводное по всем, причем тут группы?

(63) Все оплаты - некоторые авансы, это один из сценариев

(63)+ Да есть вариант что группа = дом например, но в этом случае нужны отдельные итого (регистры) с учетом домов

(65) По этому я и говорю, что одна архитектура тут не на один день продумывания

(64) А понял что некоторые вперед платят и нельзя их как оплату засчитывать это авансы.

(66) Согласен что не зная досконально предметку нифига не спроектировать даже хотя бы приемлимо или хорошо а не сразу идеально

Короче имхо ваять подобные системы на 1С не желательно.
Лучше взять нечто получше, побыстрее. И навыками обладать поболее чем только запросы и СКД ))

(22) +100500
(0) делай универсальный настраиваемый документ

А завтра выйдет новое постановление в сфере ЖКХ и идеально связный и продуманный набор превратится в тыкву.
По этому как можно меньше явных связей, декларативное описание, за фасад там будет проще в наших нелегких буднях.
Нежели пот текущие реалии подобратьидеальную модель, а через пол года ее ломать.
(67) ЭЭЭ, я еще не начал рассказывать про то как это реально платится, я только про план оплат начал рассказывать, при реальных оплатах там еще веселее) (68) Да и не на 1с не сахар. Ибо все меняется в этой сфере.

вообще это смахивает на начисление зарплаты. я бы за базу расчеты брал зуповские

(70) это лучше чем под текущие реалии подобрать идеальную модель, а через пол года ее ломать.

(47) >>Какие умные слова мы знаем.
А про NoSQL вы слышали хоть краем уха?
Или возмущение потому что нельзя будет все через ж... запросами делать?

Я слышал, что NoSQL переводится с индейского как "чувак, который не осилил SQL". Ну а применение MapReduce для целей учета финансовых документов на платформе 1С это уже что-то патологическое. Хорошо если это просто троллинг.

(67) а там предметок 7 и 7 постановщиков задач, и для (68) зарешает скорость разработки и модульность

(73) Методология 1С с проведением документов по регистрам ~ MapReduce.
Все прочие (системы для "учета финансовых документов") в лучшем случае вьюхи делают или даже каждый раз итоги по таблицам заново считают.

(75)+ Кстати регистры это весьма значительное отступление от "1ю нормальную форму"

(75) Методология проведения 1С - сначала собрать все данные в кучу, потом кучу поделить на отдельные движения по регистрам. Это строго противоположно смыслу map reduce. Не говоря уж о том, что все это происходит на классическом SQL.

(76) Регистры - отступление от 3НФ, а не от 1.

PS. Не позорься.

(77) Дублирование информации (одно и то же и в документах и в регистрах) нельзя назвать нормализацией (приведением к 1НФ)

(77)
Для каждого регистра (из множества)
1. Перебираем все документы и все строки/реквизиты, отбираем те что надо поместить данный регистр =  Map
2. Отобранные значения обрабатываем последовательно (суммируем или вычитаем или еще что) = Reduce

Хочешь сказать что "Документы-Регистры" это не тоже самое что и MapReduce ?

(78) 1 нормальная форма абсолютно никак с дублированием информации не связана, никоим образом ему не препятствует. Можно сколько угодно дублировать любые данные в любых таблицах и не нарушать первую нормальную форму.

(79) Разумеется, это не то же самое, что и MapReduce. Вообще даже близко не стояло.

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

(80) Из вики

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

Дублирование это не избыточность????

(81) Нет.
Избыточность это нечто большее чем дублирование

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

Избыточность это ну если прям совсем грубо - при дублировании у тебя со временем данные расходятся.
В 1с событие проведения это нивелирует

(83) Ну да в документах одно а в регистрах слегка другое - невозможная ситуация в 1С ?
И потенциально она ну никак не может возникнуть?

(84) Запросто, достаточно открыть какой либо регистр себестоимости.
Но значит арзхитекторы 1с посчитали это необходимыми энтропию допустимой.

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

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

(87) по двойке, все верно.

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

Я не вижу в текущей модели превышения количества над энтропией)

Даи все мы прекрасно знаем зачем это сделано.
Таблице документов одни индексы, таблице ТЧ  - другие, регистру 3и.
Так что все ок же.

(90) так первая форма она про атомарность, а не про сингулярность

(92) а я ничего именно про первую форму и не говорил.

я бы сильно подумал про (видуслуги(ссылка), единица, количество,сумма) - писали выше.
видуслуги-ссылка - по этому реквизиту из справочника "один видуслуги - ко многим - чтототам-каквариантсслканаалгоритмрасчета" собирается стоимость. Причем "чтототам" может ссылаться на очередной "видуслуги" из этого же справочника. При тащательной продумке архитектуры и реализации должно получитьяс чтото вменяемое для сопровождения/доработки/развития, и достаточно универсальное, которое может пополняться плугинами-алгоритмами для сложных случаев.
.
вариант "АРМ" где за фасадом 30 разных документов, в котором каждом 20 разных реквизитов - это будет стопудово неподьемно для сопровождения/разработки.

(94) будет слой на форме, где 30 флажков "это за киловатт" "это за кубометр", а вокруг формы невидимые поля с формулами и их будет легион)

(94) тот же фасад но в другой абстракции.
И он абсолютно точно так же плохо поддерживаем.
Та конфа в которой я сижу именно так и сделана, изменения вносить та ещё ебань.
Уж лучше бы кодом, чем часть кода - динамический, а часть статический

Зато да, те случаи которые были заложены на этапе проектирования да, можно быстро поправить.
А вот НДС 20 вылился в полугодовой проект вендору , и они умудрились ещё и срок сорвать потому что сами не помнят где на каком уровне ещё это может повлиять.

Есть же дзен, есть осознанность, есть бритва Оккама. У вас только задача. Подумайте немного. Есть параметры, есть алгоритмы, есть результат. Что будете хранить в документе, а что в справочниках и регистрах сведений. Какие отчёты будете делать, какие печатные формы будут. Немного подумать, и будет вам счастье. Осознай что нужно и получишь путь к цели.

Господа! Так как мнений много, то предлагаю проголосовать как правильно в моем случае поступить.
1) Универсальный документ для всех видов услуг и разных типов расчета
2) Отдельный документ для разных видов расчета
3) Предложите другой вариант

(99) Расчетных счетов сколько и какое железо в наличии?

(100) расчетный счет 1, железо слабое, нагрузка низкая

(101) Под расчетными счетами я подразумевал лицевые счета, короче сколько клиентов по которым услуги считаем.

Я не вижу смысла плодить документы. Стопудово есть какая-то логика, которую можно объединить в алгоритмы.

(103) а как же документы в типовых? Поступление/приобретение товаров, поступление доп. услуг, прочее оприходование товаров?

(103) потому, что ни разу не видела в продуктиве уёжищ, подобных тому, что затеял автор

+(105) основная проблема будет:
1. "опять, пытались улучшить воду и поломали к херам мусор и тепло" и " - Вася, у тебя электроэнергия скопитилась! - это потому, что я стоки продувал."
2. " - Вася, ну долбаный насос, когда мы сделаем таски по теплу?! - А хер его знает, тырщ начальник, - мне еще мусор не протестили, а там всё в одном."

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

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

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

(107) Угу поделить разные виды начислений на разные виды документов самое логичное.
Независимое исправление/доработка если что не портя другие начисления.

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

(104) Ну из вашей логики, тогда в типовой тоже "уёжище": поступление товаров, услуг, оборудования, комиссия - всё в одном документе.
Главное алгоритмы. Наговнокодить можно в любом из исполнений.
На вкус и цвет все фломастеры разные!
(105) "уёжищ" не видела. Видела нормальное исполнение.

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

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

(112) >делать несколько доков на один дом, ну не совсем то

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

Тогда можно отказаться от ТЧ совсем или всего одну ТЧ с показателями а основное в реквизитах самого дока.
Вот не пофиг что документы будут плодиться, зато исправлять легко не надо целыми "домами" перепроводить чтобы одну квартиру исправить

(113) разницы никакой 1 док на дом или квартиру

с точки зрения расчета по услугам

+ кудато нужно будет девать общедомовые

НУ вообщем идей то множество и все они имеют место быть. Ну только не надо делить доки на воду, электричество и отопление)

(117) почему бы и нет?

в (112) я вроде бы описал)

(116) Общедомовые в отдельных домовых доках и затем своя часть в каждом доке квартиры

(120) Есть вероятность, что ОДН начнут начислять до индивидуальных)

(120)+ Я агитирую отказаться от длительного проведения доков с кучей строк в ТЧ и вместо этого сделать проведение множества документов, каждый из которых проводится очень быстро!

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

(121) А вот это надо предусмотреть что сначала а что потом начисляется.
Возможно да сначала ОДН а индивидуальные ругаются если ОДН еще не готовы

(122) что то я не уверен что проведение тыщи доков будет быстрее дока с тч в тыщу строк.

(123) потому что они сделали регистр расчета с тонной логики.

(125) В курсе про параллельную обработку?

(127) ага

(122) Хотя да полюбому лучше, если одного кого то надо пересчитать, других можно не трогать, а с огромным доком так не выйдет

(95) каких флажков? есть определенные готовые профили "видусуги" - набираешь нужные в документ и все.

(0) Не читал обсуждение. Но, если уж универсальный. Я бы вообще создал РС с измерениями "ИмяТЧ", "ИмяПараметра" и ресурсом "Значение1", "Значение2", "Значение3".

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

(0)

"чукча будет не читатель - чукча будет писатель"

Есть уже стандартные устоявшиеся решения для расчета квартплаты, к примеру от компании "Инфокрафт".
Решение предполагает подсистему, а не 1 один документ.
Писать самому будет долго и нужно будет собрать все грабли которые уже устранены у профи.
Я не рекламирую, просто это равноценно купить платформу 1С и пытаться полностью самому написать, к примеру, блок бухгалтерского учета - безумство и отвага.

(131) "в запросах быстрее будет использоваться" // Быстрее по сравнению с ТЧ?

(131) (133) Я так и знал что будут запросами по формулам считать. А потом удивляться чего это оно все так тормозит...

(127) там расчет сложный, но не проведение.
тыщу строк просто в регистр переложить - плевое дело

(135) Так про что и речь, если расчет разделен на разные документы то можно эти расчеты параллельно выполнять  прикольно да?
А вот с одним документом параллельно работать сложновато однако

(136) в пределах 1 документа так же можно все параллелить

но не думую что сильно нужно. проще по домам параллелить.
а если всего 1 дом. там и нагрузки то никакой не будет

(137) Ну давай расскажи как ты будешь параллельно один документ одновременно из двух мест в базу записывать.

(139) мы расчет собираемся параллелить или запись?

(140) И еще непонятно, ТС имел ввиду расчет стоимости тарифа или расчет потребителю? подразумеваю что расчет тарифов

Мне всё время хочется спросить - у вас в конфигураторе метаданные платные что ли?

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

Резюмирая все сказанное:
1)"правильного" варианта не существует
2) развивать и поддерживать такую конфигурации проще если делать отдельными документами
3) количество ошибок в случае доработок (а они обязательно будут) в универсальном документе будет больше
Короче мне кажется что лучше делать разными документами

(140) И то и другое.
Даже расчет на одном доке неудобно параллелить, ибо как делить что уже посчитано из строк а что еще нет?
И куда это писать сколько посчитано и как передавать между потоками. Ну и самое главное результат вычислений как обратно в документу записать параллельно?

Допустим в документе есть в строках Кол-во и Тариф, надо умножить одно на другое и посчитать Сумму (чтобы потом при проведении в регистры ее).

(0) Посмотри в Управлении холдингом документ Оперативный план. Очень универсально сделан на динамически собираемой кросс-таблице. Все пишется в одну табличную часть в зависимости от вида операции и количества разнообразных настроек.

(143) + если потребуется обмен данными с внешними системами, то отдельные документы существенно проще в этом плане

(146) потребуется

(147) Вот представь тебе нужно выгрузить сведения по воде, например. Берешь документ по воде, простой запрос к нему с нужными отборами и данные для выгрузки в кармане + для синхронизации УИД документа.
А если у тебя один общий забубенный документ, то можно с выборкой данных и синхронизацией так поплясать...

(148) Вы слишком все усложняете.
Весь учёт можно сделать на регистре сведений Измерение 1...измерение10 Ресурс1...Ресурс10
Все остальное - слишком сложно.
И не надо никаких документов в принципе.

(143) Завтра добавиться расчет ассенизаторских услуг, дезинфекции, мойки окон, уборки бассеина, полив цветов и т.д. и т.п.
На все делать отдельный документ?
Имхо - отдельные документы - это не верный вариант. Староверцы какие-то советуют это )

(28) > голимое клюшкодавство

Это называется «за деревьями не видеть леса». Кто у нас здесь с полностью оригинальным подходом к «восьмерке»? Пальцев одной руки хватит? А юзать типовое любой версии и страдать как от пережевывания кактуса это оно?

(144) каждая строка документа - отдельный документ. И распаралеливай

(143) Когда будет 20 документов и на каждую услугу вместо добавления операции будешь писать новый документ со всеми механизмами будешь плакать и говорить нафига я не послушал и не сделал один документ)

(150) +100500

(153) так код расчета все равно прописывать

(155) код расчета, а не код документа. Для документа буш прописывать код вида расчета + код документа;

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

(157)+ Вот если эти новые "услуги" должны сами пользователи заводить и коэффициенты/формулы для расчета прописывать тут уже сложнее и да лучше одним доком.

Но вот разные услуги один хрен в разных документах одного вида заводить с указанием вида услуги (как вид операции в типовых) от которого форма меняется.

(158) ты еще скажи что они и формулы будут сами писать

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

(159) Почему бы и нет? Для видов цен формулы же прописывают а для бонусных программ в Рознице2 аж СКД заюзали прикольно так.

(157) копипаст существующего это понятно, но завтра нужно будет прикрутить функционал стандартный для всех документов и сиди играйся в копипаст кода.
(158) а работа пользователю вообще ляпута. Вот начислили они по абоненту 20 документов. а потом возникла необходимость откорректировать по абоненту данные. Открыл документ 1 исправил, провел. открыл документ №2 исправил, провел закрыл. После 10 документа пользователь берет канцелярский нож и идет искать программиста

(162) >Открыл документ 1 исправил, провел. открыл документ №2 исправил
Ты понимаешь что это не сильно отличается от открытия одного документа и перехода по строкам в ТЧ ?

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

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

А почему этот общий/одинаковый код заранее не вынесен в общие модули. Ну или рефакторинг проведи и вынеси для удобства внесения исправлений.

(163) опять тебе первая нормальная прилетела

(163) сильно отличается. Документы в одном журнале или в 20? ок. допустим один журнал документов. нужно отобрать по абоненту нужные документы. Так вот исправление по строкам отличается на открытие и запись документов умноженные на количество документов. а на слабом железе это может вылиться в полчаса час разницы по времени.
По поводу обработки специальные тебе придется прописывать для всех документов и при добавлении документа в систему нужно будет во всех этих обработках прописывать, это если обработчик есть общий, а если универсальная групповая обработка тебе нужно добавить в отбор все виды документов что бы обработать все сразу.
(164) А почему этот общий/одинаковый код заранее не вынесен в общие модули. - он то вынесен, вот только нужно прописать вызов этого кода во всех документах. я такой фигней маялся, когда в самописку нужно было внести изменение и пришлось сидеть и тыцять мышкой каждый документ в дереве и вставлять в нужное место вызов общей процедуры. и нужно же потом это все протестить на всех 20 документах. И не упустить - а вдруг ты пропустил какой документ.

(165) Какая нафик разница если для одного вида документа строки ТЧ разных документов один хрен в одной таблице физически лежат в 1С ?

(167) атомарность изменений

Мой опыт работы в ЖКХ был с 1996 года по 2001 год. То чем является сейчас система "квартоплат", имеет старт от моей разработки, первую выгрузку лицевых счетов, и справочников, делали по нашим данным. Разделение на лицевой счет и потребителя, первыми сделали тоже мы, потом сделали алгоритмы начислений и плагины перерасчета с нужной даты, расчета пени и расчетов по счетчикам за периоды или когда окончился поверочный период, но у клиента есть 30 дней расчета по среднему потреблению. И т.д. и т.п. Так потом сделали всю систему не только для ВиК, но и на все услуги ЖКХ. Пять лет жизни отдано. В программе все алгоритмы расчета были в одном большом дереве, и у услуги ставился код алгоритма, далее брались параметры 1-n и считалось начисление, и если был долг, то считалась пеня, и пеня на пеню.   Так вот начисление велось одним "документом" по всем услугам. Один набор был параметров по услуге плюс код алгоритма. Если передавал данные сам клиент, то  в момент передачи параметров делалось начисление.  Поменялось событие (счетчик, прописка, разделение счета, слияние счета и т.д. то менялся код алгоритма, если не было нужного то за пару часов добавляли новый. Номер кода типовых алгоритмов операторы знали наизусть. Не думаю, что любая реализация будет сильно отличаться от этой.  Если бы делал сейчас в 1С то подошли бы планы видов расчета и регистры расчета. А так уже все полезное выше написали.

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

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

И да главная фишка разделения разных услуг.
А с чего вы взяли что разные услуги в одно время будут начисляться/считаться а?
Может сначала посчитали для всех воду, затем интернет и т.д.
Если в одном доке все услуги то это как реализовать?

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

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

нумерацию,конечно,общую.