Имя: Пароль:
1C
1С v8
Вопрос по проектированию универсального документа
, ,
0 ligatr
 
21.02.19
17:36
Есть задача создать документ по расчету стоимости РАЗНЫХ услуг ЖКХ(тепло, электроэнергия, вода, стоки, мусор) в том числе телефония и интернет.
Пробовал создать универсальный документ но колонок становится слишком много (их не удобно заполнять) ну и конечного алгоритм обработки становится сложнее чем обычно.
Как в этом случае лучше поступить?
Создать разные документы в конфигурации или создать несколько ТЧ или ...?
1 Dmitry1c
 
21.02.19
17:36
(0) разные
2 ДенисЧ
 
21.02.19
17:38
Зависит от зависимости сущностей. Можно иногда просто по виду операции скрывать или показывать колонки
3 ligatr
 
21.02.19
17:42
колонок уже более 10,сейчас уже так и делаю
4 ligatr
 
21.02.19
17:45
(2) у каждого вида услуг еще разные типы расчета (по счетчикам, по площади, по формуле, по тарифу) исходя из этого колонок будет очень много
5 Garykom
 
гуру
21.02.19
17:49
Разные ТЧ.

Или группируй инфу в колонках, например по виду услуги.
Т.е. одну и ту же колонку используешь вместо того чтобы плодить их пустые в разных строках.
В ячейку можно записывать целиком ТЗ например или еще что типа по сути несколько параметров в одной ячейке.
6 Garykom
 
гуру
21.02.19
17:52
№|ВидУслуги|ПараметрыУслуги|...

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

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

Вспомогательная ТЧ
Показания счетчика на начало 11500
Показания счетчика на конец  12000
Разница в показаниях 500
Тариф 1,14
и т.п.
8 Garykom
 
гуру
21.02.19
17:54
(7) Можно и так две ТЧ, но в этом случае со связью по ключу программное заполнения/обработка документов усложняются сильно
9 azernot
 
21.02.19
17:56
(8) Конечно усложняется. Но что мешает реализовать где-нибудь в модуле объекта/менеджера вспомогательные процедуры упрощающие таковую обработку? На вход можно подавать хоть ТЗ с 1000 колонок, которая в итоге будет раскладываться в две ТЧ.
10 sqr4
 
21.02.19
17:56
В ряде конфигураций, такой документ вообще не содержит ничего, кроме движений..
11 ligatr
 
21.02.19
17:58
А может сделать несколько ТЧ в зависимости от вида услуг и показывать их в зависимости от выбора пользователя?
12 azernot
 
21.02.19
17:58
А вообще, я бы порекомендовал изучить ЗУП и его "виды расчёта". Мне кажется, это наиболее близко к ЖКХ
13 Garykom
 
гуру
21.02.19
18:09
(11) Отталкивайся от печатных форм (квитанций) для клиентов.

Если там в одной таблице - можно одну ТЧ, если разные таблицы то лучше разные ТЧ
14 Вафель
 
21.02.19
18:13
можно параметры услуги хранить в отдельной тч вида
ид услуги - параметр - значение
15 Garykom
 
гуру
21.02.19
18:15
(14) Это имеет смысл если надо по этим параметрам в документах искать.

Или для тех то не умеет сериализацию/десериализацию, ибо проще в поле засунуть в скрытой колонке.
16 Вафель
 
21.02.19
18:17
зачем по ним искать?
17 Garykom
 
гуру
21.02.19
18:21
(16) Правильно поэтому нафуй отдельную ТЧ и (5) все засовываем в одно поле
18 Garykom
 
гуру
21.02.19
18:23
19 gantonio
 
21.02.19
18:24
опиши вначале формулы расчета - увидишь, что они отличаются.
потом регулярность ввода и порядок так же может вмешаться.
если речь вообще о коммуналке в жилье то там полезет много нюансов которые потребуют фиксации дополнительных данных и не дай бог в таком документе.
20 gantonio
 
21.02.19
18:30
например энергия это кв и мощность .. хорошо если получишь одну цифру , и не дай бог если есть лимиты.
ТБО , Вода, Стоки - тут все просто
хотя стоки зависят от втоков .. и как бы связаны.
Но это если с арендой ..
а в коммуналки ..есть льготы, которые очень странные.
интернет и телефон это вообще сложно, так как тарифов много и услуга это или время или объем пакета.
а может быть просто сумма о которой договорились.
И еще есть время от которого может быть зависимость.
21 Emery
 
21.02.19
18:44
(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 .
В общем, если было бы достаточно внешнего стимула, то эта тема и конфигурация могли развиваться и дальше, ибо актуальности не потеряли до сих пор. Естественно не конкуренции ради с серьезными фирмами, а что-нибудь попроще, «для себя».
22 d4rkmesa
 
21.02.19
19:46
(0) Посмотрите в ЗУП 3 документ "Изменение плановых начислений". Там 3 связанных табличных части. Визуально редактируется только одна ТЧ, которая дополняется произвольным набором связанных колонок(т.е. в одной строке могут быть 100500 видов расчетов со всеми показателями). Однако, это довольно сложно и громоздко реализовано. Я примерно неделю потратил, что только разобраться, как оно работает(для специфической доработки).
23 palsergeich
 
21.02.19
20:03
Универсальный документ - зло.
Делайте АРМ.
24 palsergeich
 
21.02.19
20:05
А за ним множество максимально простых документов.
Это намного проще в разработке и поддержке
25 palsergeich
 
21.02.19
20:07
Иначе получите дичайшее легаси.
26 palsergeich
 
21.02.19
20:13
(22) только 1с может себе позволить иметь в багтрекере по готовому решению 300+ ошибок, которые не исправляются годами, а Вы нет
27 Лефмихалыч
 
21.02.19
20:47
(0) универсальный документ - это, как бег в мешке: по началу весело, но рано или поздно упадешь и разобьешь харю.
Делай разные документы, не телепи мозг.
28 Лефмихалыч
 
21.02.19
20:48
(21) голимое клюшкодавство
29 Garykom
 
гуру
21.02.19
20:49
(28) Без нескольких ТЧ в доках в 77 сложно было да
30 PCcomCat
 
21.02.19
20:59
(0) Если уж очень хочется универсальности, то реквизит типа ХранилищеЗначения. Туда запихнуть можно что угодно: сколько угодно реквизитов и таблиц. Но придется пожертвовать многим: запросами, доступом к реквизитам. Можно организовать регистр сведений, в котором хранить ссылку на объект, вид принадлежности реквизита (шапка, табличная часть такая-то), наименование реквизита, значение. Но тоже будут жертвы.
31 Лефмихалыч
 
21.02.19
21:06
32 Cyberhawk
 
21.02.19
21:09
(31) Ты еще в (5) почитай "В ячейку можно записывать целиком ТЗ" или "нафуй отдельную ТЧ ... все засовываем в одно поле" из (17) :D
33 Йохохо
 
21.02.19
21:14
(30) без тз и так будет жопа, что симку покупай от клиента. С универсальностью надо будет еще переезжать от бывшего работодателя
34 Лефмихалыч
 
21.02.19
21:15
(32) это how know
35 PCcomCat
 
21.02.19
21:15
(31) Я вот эту люблю: https://cloud.mail.ru/public/54ea/p3wbQAhDx
36 Cyberhawk
 
21.02.19
21:15
(33) Что за симка и что за переезд? Ты точно в ту ветку написал?
37 d4rkmesa
 
21.02.19
21:17
(26) Если перефразировать, кто тут без технического долга, бросьте в фирму 1С камень. Все реально, только времени много понадобится на выпиливание. Но, конечно, такие "эксклюзивы" без предоплаты/гарантии и полной заинтересованности заказчика лучше не делать.
38 Cyberhawk
 
21.02.19
21:18
(37) Но согласись, есть у некоторых людей и полностью завершенные разработки, т.е. прям конфетки
39 d4rkmesa
 
21.02.19
21:20
(38) Не отрицаю, перфекционизм никто не отменял.
40 d4rkmesa
 
21.02.19
21:21
(39) Но это скорее всего функционал, не связанный с изменениями законодательства.
41 Йохохо
 
21.02.19
21:26
(36) точно. Когда пойдут уточнения, сроки улетят в трубу, теряем клиента. Когда посмотрят код - работодателя
42 Лефмихалыч
 
21.02.19
21:27
(41) вы пьяны, сударь?
43 Cyberhawk
 
21.02.19
21:28
(41) Ясно, понял, спс за разъяснения ))
44 palsergeich
 
21.02.19
21:31
(33) имелось ввиду сделал, сдал, деньги получил и в закат, ибо поддерживать это кхм, то еще удовольствие.
(37) Все зависит от тультуры разработки.
Одно дело когда незапланированное поведение или переменную не так назвал, другое дело когда заявленный функционал не работает, потому что там запущены грубейшие ошибки.
На текущем месте работы - релиз продакшена раз в месяц. На прошлом раз в неделю. На позапозапрошлом по одной базе так же раз в месяц. Очень знаете ли учит сразу херни не делать.
45 palsergeich
 
21.02.19
21:47
Простейшие примеры халатности, что можно было бы выявить при желании
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х страницах никак не связаны с отраслевой спецификой.
Дальше не смотрел
46 Скиурус
 
21.02.19
22:05
(5) >>В ячейку можно записывать целиком ТЗ например или еще что типа по сути несколько параметров в одной ячейке.
Я бы людей, которые нарушают 1ю нормальную форму, гнал из профессии ссаными тряпками.

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

Кстати, "более 10 колонок", если их сразу на пользователя не вываливать, ну ни разу не кажется большим числом. Собственно, все многообразие коммунальных платежей по определению вмещается в рамки утвержденной формы платежного поручения, а реквизитов в платежке не так чтобы очень много.
47 Garykom
 
гуру
21.02.19
22:21
(46) >Я бы людей, которые нарушают 1ю нормальную форму, гнал из профессии ссаными тряпками

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

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

Какой смысл хранить эти параметры/коэффициенты/показатели отдельно а не вместе?
Они на другие "счета" не влияют и действуют только внутри документа для него одного.
Все вычисления происходят для каждого документа отдельно, не затрагивая другие и вместе со всей строкой, наоборот очень удобно и быстро, минимум обращений к БД получается.
48 palsergeich
 
21.02.19
22:28
(47) Скажу так если в ячейку ТЗ запихнуть ТЗ (а это можно сделать), то есть багля при серверном вызове при перерисиовке формы - краш клиентского приложения.
Никто и ничто не мешает это все хранить в одном документе без лишних обращений к БД, надо просто чуть больше подумать чем сделать реквизит и перетащить его на форму.
Но никаких принципиальных сложностей нет.
49 Йохохо
 
21.02.19
22:31
(47) распредели квартальные 100р на тех у кого нет счетчика в такой модели. Когда сделаешь, они передумают и уточнят, что нет онлайн счетчика и учесть тех кто уехал т.е. меньше 2 киловатт. На каждый чих простыни неподдерживаемого кода
50 Garykom
 
гуру
21.02.19
22:33
(48) ТЗ ячейке это один из вариантов и да не самый лучший.
Лучше просто строковое поле в ТЧ и внутри хранить JSON с нужными данными.
51 Garykom
 
гуру
21.02.19
22:37
(49) Не вижу никаких проблем распределить и тем более без простыней кода/запросов когда в одном пытаются универсально все на всех сразу засунуть.

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

Ну и банальный цикл по "документам" берем нужные для каждого коэффициенты и зная общие высчитываем сколько из "квартальные 100р" на каждого будет.
В т.ч. если "меньше 2 киловатт" = 0
52 Garykom
 
гуру
21.02.19
22:39
(51)+ Кстати метода https://ru.wikipedia.org/wiki/MapReduce сюда ложится просто идеально!
53 Garykom
 
гуру
21.02.19
22:39
(52)+ В смысле при проведении "документа" не забываем в регистры суммарные показатели писать
54 Йохохо
 
21.02.19
22:40
(51) "отдельно готовыми" это и есть тот звоночек который фо хум зе бел толлс
55 Garykom
 
гуру
21.02.19
22:43
(54) Скажи что мешает в процедуре проведения взять значение (строковое) из ячейки, получить несколько значений (нужных типов) из него и засунуть их в нужные регистры?
56 palsergeich
 
21.02.19
22:46
Вы уже в отраслевку скатились.
Универсальность как правило неподдерживаема, любое изменение может вывести систему из равновесия.
ИМХО, тут одно принятие архитектурного решения не на один день)
Я за АРМ с большим количеством документов за фасадом. Легко работать, легко поддерживать, легко потом из одного арм сделать много.
(52) Такой распределенный СКД, где значение каждой группировки на отдельной ноде считается и потом это склеивается, но боюсь при корреляции данных, а тут она будет - неприменимо.
57 Garykom
 
гуру
21.02.19
22:47
(56) >значение каждой группировки на отдельной ноде считается и потом это склеивается

Угу это реально шустро и параллельно
58 Garykom
 
гуру
21.02.19
22:48
(57)+ https://ru.wikipedia.org/wiki/CouchDB изучал в свое время, прикольная штука для подобных задач
59 palsergeich
 
21.02.19
22:48
(57) но голоса в моей голове говорят, что там будет межгруппировочная корреляция
60 Garykom
 
гуру
21.02.19
22:49
(59) Пример бы подобной корреляции
61 palsergeich
 
21.02.19
22:51
(60) Я с жкх не работаю, но по текущему направлению:
Комиссия может быть процентом от суммы оплат - авансы, но авансы не все, а некоторые)))
62 palsergeich
 
21.02.19
22:52
А может быть фиксированным значением, а может быть процентом от всех оплат без учета авансов
63 Garykom
 
гуру
21.02.19
22:53
(61) В смысле комиссия для одного зависит от оплаты другими?
Так это же сводное по всем, причем тут группы?
64 palsergeich
 
21.02.19
22:54
(63) Все оплаты - некоторые авансы, это один из сценариев
65 Garykom
 
гуру
21.02.19
22:54
(63)+ Да есть вариант что группа = дом например, но в этом случае нужны отдельные итого (регистры) с учетом домов
66 palsergeich
 
21.02.19
22:55
(65) По этому я и говорю, что одна архитектура тут не на один день продумывания
67 Garykom
 
гуру
21.02.19
22:56
(64) А понял что некоторые вперед платят и нельзя их как оплату засчитывать это авансы.

(66) Согласен что не зная досконально предметку нифига не спроектировать даже хотя бы приемлимо или хорошо а не сразу идеально
68 Garykom
 
гуру
21.02.19
22:59
Короче имхо ваять подобные системы на 1С не желательно.
Лучше взять нечто получше, побыстрее. И навыками обладать поболее чем только запросы и СКД ))
69 Ник080808
 
21.02.19
23:01
(22) +100500
(0) делай универсальный настраиваемый документ
70 palsergeich
 
21.02.19
23:01
А завтра выйдет новое постановление в сфере ЖКХ и идеально связный и продуманный набор превратится в тыкву.
По этому как можно меньше явных связей, декларативное описание, за фасад там будет проще в наших нелегких буднях.
Нежели пот текущие реалии подобратьидеальную модель, а через пол года ее ломать.
(67) ЭЭЭ, я еще не начал рассказывать про то как это реально платится, я только про план оплат начал рассказывать, при реальных оплатах там еще веселее) (68) Да и не на 1с не сахар. Ибо все меняется в этой сфере.
71 Ник080808
 
21.02.19
23:02
вообще это смахивает на начисление зарплаты. я бы за базу расчеты брал зуповские
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
Для пользователя должен быть один журнал со всеми документами,а также удобная форма работы с ними,причем,можно одну форму на несколько документов натянуть.

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

нумерацию,конечно,общую.
Независимо от того, куда вы едете — это в гору и против ветра!