Имя: Пароль:
1C
1С v8
Вопрос по проектированию универсального документа
,
0 ligatr
 
21.02.19
17:36
Есть задача создать документ по расчету стоимости РАЗНЫХ услуг ЖКХ(тепло, электроэнергия, вода, стоки, мусор) в том числе телефония и интернет.
Пробовал создать универсальный документ но колонок становится слишком много (их не удобно заполнять) ну и конечного алгоритм обработки становится сложнее чем обычно.
Как в этом случае лучше поступить?
Создать разные документы в конфигурации или создать несколько ТЧ или ...?
72 palsergeich
 
21.02.19
23:02
(70) это лучше чем под текущие реалии подобрать идеальную модель, а через пол года ее ломать.
73 Скиурус
 
21.02.19
23:03
(47) >>Какие умные слова мы знаем.
А про NoSQL вы слышали хоть краем уха?
Или возмущение потому что нельзя будет все через ж... запросами делать?

Я слышал, что NoSQL переводится с индейского как "чувак, который не осилил SQL". Ну а применение MapReduce для целей учета финансовых документов на платформе 1С это уже что-то патологическое. Хорошо если это просто троллинг.
74 Йохохо
 
21.02.19
23:03
(67) а там предметок 7 и 7 постановщиков задач, и для (68) зарешает скорость разработки и модульность
75 Garykom
 
гуру
21.02.19
23:12
(73) Методология 1С с проведением документов по регистрам ~ MapReduce.
Все прочие (системы для "учета финансовых документов") в лучшем случае вьюхи делают или даже каждый раз итоги по таблицам заново считают.
76 Garykom
 
гуру
21.02.19
23:15
(75)+ Кстати регистры это весьма значительное отступление от "1ю нормальную форму"
77 Скиурус
 
21.02.19
23:21
(75) Методология проведения 1С - сначала собрать все данные в кучу, потом кучу поделить на отдельные движения по регистрам. Это строго противоположно смыслу map reduce. Не говоря уж о том, что все это происходит на классическом SQL.

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

PS. Не позорься.
78 Garykom
 
гуру
21.02.19
23:28
(77) Дублирование информации (одно и то же и в документах и в регистрах) нельзя назвать нормализацией (приведением к 1НФ)
79 Garykom
 
гуру
21.02.19
23:36
(77)
Для каждого регистра (из множества)
1. Перебираем все документы и все строки/реквизиты, отбираем те что надо поместить данный регистр =  Map
2. Отобранные значения обрабатываем последовательно (суммируем или вычитаем или еще что) = Reduce

Хочешь сказать что "Документы-Регистры" это не тоже самое что и MapReduce ?
80 Скиурус
 
21.02.19
23:39
(78) 1 нормальная форма абсолютно никак с дублированием информации не связана, никоим образом ему не препятствует. Можно сколько угодно дублировать любые данные в любых таблицах и не нарушать первую нормальную форму.

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

P.S. Я заканчиваю дискуссию, мне не о чем говорить с человеком, который даже не в состоянии прочитать на какой-нить википедии смысл употребляемых им слов.
81 Garykom
 
гуру
21.02.19
23:41
(80) Из вики

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

Дублирование это не избыточность????
82 palsergeich
 
21.02.19
23:48
(81) Нет.
Избыточность это нечто большее чем дублирование
83 palsergeich
 
21.02.19
23:51
Информационная избыточность – термин из теории информации, означающий превышение количества информации, используемой для передачи или хранения сообщения, над его информационной энтропией.

Избыточность это ну если прям совсем грубо - при дублировании у тебя со временем данные расходятся.
В 1с событие проведения это нивелирует
84 Garykom
 
гуру
21.02.19
23:52
(83) Ну да в документах одно а в регистрах слегка другое - невозможная ситуация в 1С ?
И потенциально она ну никак не может возникнуть?
85 palsergeich
 
21.02.19
23:54
(84) Запросто, достаточно открыть какой либо регистр себестоимости.
Но значит арзхитекторы 1с посчитали это необходимыми энтропию допустимой.
86 palsergeich
 
21.02.19
23:56
Но в общем виде по стандартам в регистры должна идти информация из табличных частей.
все остальное, кхм, проектное решение (c)
87 Йохохо
 
22.02.19
00:07
уже пятница? (83) так при дублировании энтропия возрастет в ln2, как бы избыточность. Или по чему там в теории информации логарифмируют?
88 palsergeich
 
22.02.19
00:12
(87) по двойке, все верно.
89 palsergeich
 
22.02.19
00:14
Избыточность приводит к увеличению времени передачи сообщений, уменьшению скорости передачи информации, излишней загрузки канала, вместе с тем, избыточность необходима для обеспечения достоверности передаваемых данных, т.е. надежности СПД, повышения помехоустойчивости. При этом, применяя специальные коды, использующие избыточность в передаваемых сообщениях, можно обнаружить и исправить ошибки.
90 palsergeich
 
22.02.19
00:15
Я не вижу в текущей модели превышения количества над энтропией)
91 palsergeich
 
22.02.19
00:17
Даи все мы прекрасно знаем зачем это сделано.
Таблице документов одни индексы, таблице ТЧ  - другие, регистру 3и.
Так что все ок же.
92 Йохохо
 
22.02.19
00:24
(90) так первая форма она про атомарность, а не про сингулярность
93 palsergeich
 
22.02.19
00:28
(92) а я ничего именно про первую форму и не говорил.
94 Злопчинский
 
22.02.19
00:31
я бы сильно подумал про (видуслуги(ссылка), единица, количество,сумма) - писали выше.
видуслуги-ссылка - по этому реквизиту из справочника "один видуслуги - ко многим - чтототам-каквариантсслканаалгоритмрасчета" собирается стоимость. Причем "чтототам" может ссылаться на очередной "видуслуги" из этого же справочника. При тащательной продумке архитектуры и реализации должно получитьяс чтото вменяемое для сопровождения/доработки/развития, и достаточно универсальное, которое может пополняться плугинами-алгоритмами для сложных случаев.
.
вариант "АРМ" где за фасадом 30 разных документов, в котором каждом 20 разных реквизитов - это будет стопудово неподьемно для сопровождения/разработки.
95 Йохохо
 
22.02.19
00:34
(94) будет слой на форме, где 30 флажков "это за киловатт" "это за кубометр", а вокруг формы невидимые поля с формулами и их будет легион)
96 palsergeich
 
22.02.19
00:36
(94) тот же фасад но в другой абстракции.
И он абсолютно точно так же плохо поддерживаем.
Та конфа в которой я сижу именно так и сделана, изменения вносить та ещё ебань.
Уж лучше бы кодом, чем часть кода - динамический, а часть статический
97 palsergeich
 
22.02.19
00:39
Зато да, те случаи которые были заложены на этапе проектирования да, можно быстро поправить.
А вот НДС 20 вылился в полугодовой проект вендору , и они умудрились ещё и срок сорвать потому что сами не помнят где на каком уровне ещё это может повлиять.
98 ILM
 
гуру
22.02.19
04:19
Есть же дзен, есть осознанность, есть бритва Оккама. У вас только задача. Подумайте немного. Есть параметры, есть алгоритмы, есть результат. Что будете хранить в документе, а что в справочниках и регистрах сведений. Какие отчёты будете делать, какие печатные формы будут. Немного подумать, и будет вам счастье. Осознай что нужно и получишь путь к цели.
99 ligatr
 
22.02.19
09:53
Господа! Так как мнений много, то предлагаю проголосовать как правильно в моем случае поступить.
1) Универсальный документ для всех видов услуг и разных типов расчета
2) Отдельный документ для разных видов расчета
3) Предложите другой вариант
100 Garykom
 
гуру
22.02.19
10:08
(99) Расчетных счетов сколько и какое железо в наличии?
101 ligatr
 
22.02.19
10:24
(100) расчетный счет 1, железо слабое, нагрузка низкая
102 Garykom
 
гуру
22.02.19
11:27
(101) Под расчетными счетами я подразумевал лицевые счета, короче сколько клиентов по которым услуги считаем.
103 PCcomCat
 
22.02.19
11:45
Я не вижу смысла плодить документы. Стопудово есть какая-то логика, которую можно объединить в алгоритмы.
104 OldCondom
 
22.02.19
11:54
(103) а как же документы в типовых? Поступление/приобретение товаров, поступление доп. услуг, прочее оприходование товаров?
105 Лефмихалыч
 
22.02.19
12:06
(103) потому, что ни разу не видела в продуктиве уёжищ, подобных тому, что затеял автор
106 Лефмихалыч
 
22.02.19
12:09
+(105) основная проблема будет:
1. "опять, пытались улучшить воду и поломали к херам мусор и тепло" и " - Вася, у тебя электроэнергия скопитилась! - это потому, что я стоки продувал."
2. " - Вася, ну долбаный насос, когда мы сделаем таски по теплу?! - А хер его знает, тырщ начальник, - мне еще мусор не протестили, а там всё в одном."
107 Лефмихалыч
 
22.02.19
12:10
не видеть смысла в разделении бизнес логики на документы - это все равно, что не видеть смысла в процедурах  функциях и весь код херать в одну функцию СделатьВсё, кишащую готами.
108 Valerik0101
 
22.02.19
12:11
Можно посмотреть, для примера, в сторону блока бюджетирования в ерп/ка
Значения нефинансовых показателей, произвольные данные и т.д. Или как в экземплярах бюджета сделано, хотя они мне не нравятся.
Что-то по аналогии под себя подогнать.
109 Йохохо
 
22.02.19
12:15
люди делятся на два типа, одни уже не хотят рефакторить универсальный документ, другие еще не пробовали
110 Garykom
 
гуру
22.02.19
12:16
(107) Угу поделить разные виды начислений на разные виды документов самое логичное.
Независимое исправление/доработка если что не портя другие начисления.

Вот с правильными квитанциями придется повозиться, вот их я бы оформил в виде этого отдельного универсального документа, который по сути собирает данные из регистров и хранит в себе то что выставили на некую дату в неизменном виде (даже если регистры потом поправили).
Т.е. документ-квитанция это просто снимок регистров на некую дату, он ничего не считает и не меняет.
111 PCcomCat
 
22.02.19
12:32
(104) Ну из вашей логики, тогда в типовой тоже "уёжище": поступление товаров, услуг, оборудования, комиссия - всё в одном документе.
Главное алгоритмы. Наговнокодить можно в любом из исполнений.
На вкус и цвет все фломастеры разные!
(105) "уёжищ" не видела. Видела нормальное исполнение.
112 sqr4
 
22.02.19
12:34
(110) Виды начислений тут не причем. Вода по счетчику = Показание * тариф. Тоже самое с электричеством, тоже самое с отоплением если есть индивидуальный счечтик. Вода по нормативу = Норматив * Показатель * Тариф - Тоже самое для электричества, мусора и т.д
т.е один и тот же вид может начислять по разному в зависимости от настроек. Таким образом если разделить доки на воду, электричество, отопление и т.д, то будет просто куча одинаковых документов. Профит от этого маленький.
Была идея разделить по методам начисления - по счетчику - нормативу и т.д. Но тут в одном доме может быть по одной услуге разные виды расчета, и делать несколько доков на один дом, ну не совсем то.

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

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

Тогда можно отказаться от ТЧ совсем или всего одну ТЧ с показателями а основное в реквизитах самого дока.
Вот не пофиг что документы будут плодиться, зато исправлять легко не надо целыми "домами" перепроводить чтобы одну квартиру исправить
114 Вафель
 
22.02.19
12:47
(113) разницы никакой 1 док на дом или квартиру
115 Вафель
 
22.02.19
12:47
с точки зрения расчета по услугам
116 Вафель
 
22.02.19
12:48
+ кудато нужно будет девать общедомовые
117 sqr4
 
22.02.19
12:49
НУ вообщем идей то множество и все они имеют место быть. Ну только не надо делить доки на воду, электричество и отопление)
118 Вафель
 
22.02.19
12:50
(117) почему бы и нет?
119 sqr4
 
22.02.19
12:51
в (112) я вроде бы описал)
120 Garykom
 
гуру
22.02.19
12:55
(116) Общедомовые в отдельных домовых доках и затем своя часть в каждом доке квартиры
121 sqr4
 
22.02.19
12:56
(120) Есть вероятность, что ОДН начнут начислять до индивидуальных)
122 Garykom
 
гуру
22.02.19
12:56
(120)+ Я агитирую отказаться от длительного проведения доков с кучей строк в ТЧ и вместо этого сделать проведение множества документов, каждый из которых проводится очень быстро!
123 Ник080808
 
22.02.19
12:57
Интересно, почему разработчики зупа не придумали отдельный документ на каждый вид расчета - оклад по дням один документ, Оклад по часам другой, сдельная - другой. все расчеты впихнули в один документ.
124 Garykom
 
гуру
22.02.19
12:58
(121) А вот это надо предусмотреть что сначала а что потом начисляется.
Возможно да сначала ОДН а индивидуальные ругаются если ОДН еще не готовы
125 sqr4
 
22.02.19
13:52
(122) что то я не уверен что проведение тыщи доков будет быстрее дока с тч в тыщу строк.
126 palsergeich
 
22.02.19
13:55
(123) потому что они сделали регистр расчета с тонной логики.
127 Garykom
 
гуру
22.02.19
13:58
(125) В курсе про параллельную обработку?
128 sqr4
 
22.02.19
14:00
(127) ага
129 sqr4
 
22.02.19
14:02
(122) Хотя да полюбому лучше, если одного кого то надо пересчитать, других можно не трогать, а с огромным доком так не выйдет
130 Злопчинский
 
22.02.19
14:13
(95) каких флажков? есть определенные готовые профили "видусуги" - набираешь нужные в документ и все.
131 Вася Теркин
 
22.02.19
14:34
(0) Не читал обсуждение. Но, если уж универсальный. Я бы вообще создал РС с измерениями "ИмяТЧ", "ИмяПараметра" и ресурсом "Значение1", "Значение2", "Значение3".

И в него бы писал. Во первых, в запросах быстрее будет использоваться, во вторых, можно заливать из сторонних источников.
132 zelyak
 
22.02.19
14:40
(0)

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

Есть уже стандартные устоявшиеся решения для расчета квартплаты, к примеру от компании "Инфокрафт".
Решение предполагает подсистему, а не 1 один документ.
Писать самому будет долго и нужно будет собрать все грабли которые уже устранены у профи.
Я не рекламирую, просто это равноценно купить платформу 1С и пытаться полностью самому написать, к примеру, блок бухгалтерского учета - безумство и отвага.
133 Cyberhawk
 
22.02.19
15:06
(131) "в запросах быстрее будет использоваться" // Быстрее по сравнению с ТЧ?
134 Garykom
 
гуру
22.02.19
15:16
(131) (133) Я так и знал что будут запросами по формулам считать. А потом удивляться чего это оно все так тормозит...
135 Вафель
 
22.02.19
15:36
(127) там расчет сложный, но не проведение.
тыщу строк просто в регистр переложить - плевое дело
136 Garykom
 
гуру
22.02.19
15:42
(135) Так про что и речь, если расчет разделен на разные документы то можно эти расчеты параллельно выполнять  прикольно да?
А вот с одним документом параллельно работать сложновато однако
137 Вафель
 
22.02.19
15:43
(136) в пределах 1 документа так же можно все параллелить
138 Вафель
 
22.02.19
15:44
но не думую что сильно нужно. проще по домам параллелить.
а если всего 1 дом. там и нагрузки то никакой не будет
139 Garykom
 
гуру
22.02.19
15:49
(137) Ну давай расскажи как ты будешь параллельно один документ одновременно из двух мест в базу записывать.
140 Вафель
 
22.02.19
15:58
(139) мы расчет собираемся параллелить или запись?
141 Krendel
 
22.02.19
16:03
(140) И еще непонятно, ТС имел ввиду расчет стоимости тарифа или расчет потребителю? подразумеваю что расчет тарифов
142 Skylark
 
22.02.19
16:22
Мне всё время хочется спросить - у вас в конфигураторе метаданные платные что ли?

Вы посмотрите сколько в типовых одних только ролей, не говоря уже про регистры сведений, а вы стесняетесь лишний документ создать.
143 ligatr
 
22.02.19
16:29
Резюмирая все сказанное:
1)"правильного" варианта не существует
2) развивать и поддерживать такую конфигурации проще если делать отдельными документами
3) количество ошибок в случае доработок (а они обязательно будут) в универсальном документе будет больше
Короче мне кажется что лучше делать разными документами
144 Garykom
 
гуру
22.02.19
16:31
(140) И то и другое.
Даже расчет на одном доке неудобно параллелить, ибо как делить что уже посчитано из строк а что еще нет?
И куда это писать сколько посчитано и как передавать между потоками. Ну и самое главное результат вычислений как обратно в документу записать параллельно?

Допустим в документе есть в строках Кол-во и Тариф, надо умножить одно на другое и посчитать Сумму (чтобы потом при проведении в регистры ее).
145 KSN
 
22.02.19
16:32
(0) Посмотри в Управлении холдингом документ Оперативный план. Очень универсально сделан на динамически собираемой кросс-таблице. Все пишется в одну табличную часть в зависимости от вида операции и количества разнообразных настроек.
146 Skylark
 
22.02.19
16:32
(143) + если потребуется обмен данными с внешними системами, то отдельные документы существенно проще в этом плане
147 ligatr
 
22.02.19
16:44
(146) потребуется
148 Skylark
 
22.02.19
16:54
(147) Вот представь тебе нужно выгрузить сведения по воде, например. Берешь документ по воде, простой запрос к нему с нужными отборами и данные для выгрузки в кармане + для синхронизации УИД документа.
А если у тебя один общий забубенный документ, то можно с выборкой данных и синхронизацией так поплясать...
149 palsergeich
 
22.02.19
17:05
(148) Вы слишком все усложняете.
Весь учёт можно сделать на регистре сведений Измерение 1...измерение10 Ресурс1...Ресурс10
Все остальное - слишком сложно.
И не надо никаких документов в принципе.
150 Valerik0101
 
22.02.19
17:12
(143) Завтра добавиться расчет ассенизаторских услуг, дезинфекции, мойки окон, уборки бассеина, полив цветов и т.д. и т.п.
На все делать отдельный документ?
Имхо - отдельные документы - это не верный вариант. Староверцы какие-то советуют это )
151 Emery
 
22.02.19
17:13
(28) > голимое клюшкодавство

Это называется «за деревьями не видеть леса». Кто у нас здесь с полностью оригинальным подходом к «восьмерке»? Пальцев одной руки хватит? А юзать типовое любой версии и страдать как от пережевывания кактуса это оно?
152 Злопчинский
 
22.02.19
17:22
(144) каждая строка документа - отдельный документ. И распаралеливай
153 Ник080808
 
22.02.19
17:26
(143) Когда будет 20 документов и на каждую услугу вместо добавления операции будешь писать новый документ со всеми механизмами будешь плакать и говорить нафига я не послушал и не сделал один документ)
154 Ник080808
 
22.02.19
17:26
(150) +100500
155 Вафель
 
22.02.19
17:27
(153) так код расчета все равно прописывать
156 Ник080808
 
22.02.19
17:29
(155) код расчета, а не код документа. Для документа буш прописывать код вида расчета + код документа;
157 Garykom
 
гуру
22.02.19
17:37
(150) (154) Откройте для себя копи-пасте для метаданных.
Так сложно копию документа создать для каждого из "ассенизаторских услуг, дезинфекции, мойки окон, уборки бассеина, полив цветов и т.д. и т.п. " ?
158 Garykom
 
гуру
22.02.19
17:41
(157)+ Вот если эти новые "услуги" должны сами пользователи заводить и коэффициенты/формулы для расчета прописывать тут уже сложнее и да лучше одним доком.

Но вот разные услуги один хрен в разных документах одного вида заводить с указанием вида услуги (как вид операции в типовых) от которого форма меняется.
159 Вафель
 
22.02.19
17:46
(158) ты еще скажи что они и формулы будут сами писать
160 Вафель
 
22.02.19
17:47
лучше всего по типам расчета.
и привязка услуга - вид расчета.
и мастер документ
161 Garykom
 
гуру
22.02.19
17:57
(159) Почему бы и нет? Для видов цен формулы же прописывают а для бонусных программ в Рознице2 аж СКД заюзали прикольно так.
162 Ник080808
 
22.02.19
17:57
(157) копипаст существующего это понятно, но завтра нужно будет прикрутить функционал стандартный для всех документов и сиди играйся в копипаст кода.
(158) а работа пользователю вообще ляпута. Вот начислили они по абоненту 20 документов. а потом возникла необходимость откорректировать по абоненту данные. Открыл документ 1 исправил, провел. открыл документ №2 исправил, провел закрыл. После 10 документа пользователь берет канцелярский нож и идет искать программиста
163 Garykom
 
гуру
22.02.19
18:01
(162) >Открыл документ 1 исправил, провел. открыл документ №2 исправил
Ты понимаешь что это не сильно отличается от открытия одного документа и перехода по строкам в ТЧ ?

И то и другое идиотизм если не один-два документа/строки исправлять и должно выполняться некими обработками специальными, где можно задать что, где и на что исправляем и натравить. Как групповая обработка и изменение.
164 Garykom
 
гуру
22.02.19
18:02
(162) >но завтра нужно будет прикрутить функционал стандартный для всех документов и сиди играйся в копипаст кода

А почему этот общий/одинаковый код заранее не вынесен в общие модули. Ну или рефакторинг проведи и вынеси для удобства внесения исправлений.
165 Йохохо
 
22.02.19
18:12
(163) опять тебе первая нормальная прилетела
166 Ник080808
 
22.02.19
18:19
(163) сильно отличается. Документы в одном журнале или в 20? ок. допустим один журнал документов. нужно отобрать по абоненту нужные документы. Так вот исправление по строкам отличается на открытие и запись документов умноженные на количество документов. а на слабом железе это может вылиться в полчаса час разницы по времени.
По поводу обработки специальные тебе придется прописывать для всех документов и при добавлении документа в систему нужно будет во всех этих обработках прописывать, это если обработчик есть общий, а если универсальная групповая обработка тебе нужно добавить в отбор все виды документов что бы обработать все сразу.
(164) А почему этот общий/одинаковый код заранее не вынесен в общие модули. - он то вынесен, вот только нужно прописать вызов этого кода во всех документах. я такой фигней маялся, когда в самописку нужно было внести изменение и пришлось сидеть и тыцять мышкой каждый документ в дереве и вставлять в нужное место вызов общей процедуры. и нужно же потом это все протестить на всех 20 документах. И не упустить - а вдруг ты пропустил какой документ.
167 Garykom
 
гуру
22.02.19
18:20
(165) Какая нафик разница если для одного вида документа строки ТЧ разных документов один хрен в одной таблице физически лежат в 1С ?
168 Йохохо
 
22.02.19
18:23
(167) атомарность изменений
169 ILM
 
гуру
22.02.19
18:24
Мой опыт работы в ЖКХ был с 1996 года по 2001 год. То чем является сейчас система "квартоплат", имеет старт от моей разработки, первую выгрузку лицевых счетов, и справочников, делали по нашим данным. Разделение на лицевой счет и потребителя, первыми сделали тоже мы, потом сделали алгоритмы начислений и плагины перерасчета с нужной даты, расчета пени и расчетов по счетчикам за периоды или когда окончился поверочный период, но у клиента есть 30 дней расчета по среднему потреблению. И т.д. и т.п. Так потом сделали всю систему не только для ВиК, но и на все услуги ЖКХ. Пять лет жизни отдано. В программе все алгоритмы расчета были в одном большом дереве, и у услуги ставился код алгоритма, далее брались параметры 1-n и считалось начисление, и если был долг, то считалась пеня, и пеня на пеню.   Так вот начисление велось одним "документом" по всем услугам. Один набор был параметров по услуге плюс код алгоритма. Если передавал данные сам клиент, то  в момент передачи параметров делалось начисление.  Поменялось событие (счетчик, прописка, разделение счета, слияние счета и т.д. то менялся код алгоритма, если не было нужного то за пару часов добавляли новый. Номер кода типовых алгоритмов операторы знали наизусть. Не думаю, что любая реализация будет сильно отличаться от этой.  Если бы делал сейчас в 1С то подошли бы планы видов расчета и регистры расчета. А так уже все полезное выше написали.
170 Garykom
 
гуру
22.02.19
18:27
(166) Короче не зная досконально предметку (сколько там видов услуг и будут ли новые в будущем или сложные изменения) заранее продумать архитектуру/метаданные не получится.

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

И да главная фишка разделения разных услуг.
А с чего вы взяли что разные услуги в одно время будут начисляться/считаться а?
Может сначала посчитали для всех воду, затем интернет и т.д.
Если в одном доке все услуги то это как реализовать?
171 Сияющий в темноте
 
23.02.19
15:06
Для пользователя должен быть один журнал со всеми документами,а также удобная форма работы с ними,причем,можно одну форму на несколько документов натянуть.

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

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