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

(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) Короче не зная досконально предметку (сколько там видов услуг и будут ли новые в будущем или сложные изменения) заранее продумать архитектуру/метаданные не получится.

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

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

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

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

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