Взгляд программиста на 1С:Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК ред. 2.0

1. prodines 107 10.02.14 16:34 Сейчас в теме
Сейчас занимаюсь программированием конфигурации "1С:Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК (2.0.53.1) (http://www.vdgb-soft.ru/jsk/jkh/)" (далее - УУК)

Хотелось бы рассказать о своих впечатлениях - как программиста 1С.

Сначала о недостатках:

1. Бросается в глаза тот факт, что конфигурацию делали в условиях значительной нехватки времени. Писали её явно "по-живому", не имея времени хоть немного проработать её внутри.

2. Почему-то эта конфигурация должна обязательно встраиваться в типовую конфигурацию "Бухгалтерия 2.0". Почему её не сделали отдельной конфигурацией? Из-за этого клиент обречён, купив УУК, обязательно ещё и купить типовую бухгалтерию.

3. Создатели УУК, видимо, и не подозревали о том, что в 1С версии 8 существует такой объект языка, как регистры расчёта. Все расчеты построены исключительно на регистрах накопления - хотя, ясное дело, использовать вместо них регистры расчёта было бы гораздо логичнее.

4. С моей точки зрения, УУК имеет неоптимальную архитектуру в части структуры данных. На логическом уровне (пользователя) имеется иерархическая вложенность разнотипных данных - из-за этого во всех расчётных функциях приходится (авторам конфы) использовать многоуровневые вложенные циклы - вместо запросов. Это чрезвычайно усложняет программистское обслуживание конфигурации, а также пагубно влияет на быстродействие УУК (нет иного выхода, кроме как делать запросы в циклах). Всем известны примеры типовой организации иерархической вложенности разнотиповых данных - это тот же КЛАДР, например - который хранится как регистр сведений - в результате чего с ним удобно работать запросами.

5. В документе "Начисления" в шапке есть реквизит "Услуга" типа Справочник.КВП_Услуги. Элемент этого справочника имеет под 20 реквизитов - и часть из них влияет на характер проведения документа. При этом пользователи произвольно меняют реквизиты этого справочника - до и после проведения - поэтому после проведения никак нельзя определить, какие именно реквизиты были в справочнике в момент проведения. Мне пришлось лепить новый регистр сведений - куда записывать все реквизиты справочника на момент проведения.

6. (Мелкий недостаток) В документе "Начисления" есть 3 табличные части - одна из которых отображается в зависимости от вида операции - скрывая оставшиеся 2. Это плохо - лучше бы авторы сделали вкладки, как в реализации услуг, и на каждую вкладку вывели свою табличную часть.

7. В квитанции в макете табличного документа используются именованные области вместо секций - это и не наглядно, и метод табличного документа "Присоединить" не работает с именованными областями - а только с секциями.

С этой конфигурацией я работаю недавно, так что ещё могут быть новые впечатления. В принципе, она всё считает, как надо - но, по-хорошему, её следовало бы переписать с нуля - по более разумной архитектуре данных.
Ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. AllexSoft 10.02.14 17:14 Сейчас в теме
(1) prodines, к сожалению у "гигантов отрасли" типа БИТа, ВДГБ, Раруса и тд принято ТАК писать конфигурации, они их не тестируют даже, получили 1С:Совместимо и вперед продавать стране, а там уж что будет никому не надо.
ПС: Вам крупно повезло у вас вообще "взлетело" хоть что то
DoReMi; LeXXik; +2 Ответить
3. WEBBY 10.02.14 23:12 Сейчас в теме
Хотелось бы рассказать о своих впечатлениях - как пользователя 1С.
Поддержка у ВГДБ плохая очень, конфигурация сырая. Очень часто не успевают за законодательной сменой формул расчета тарифов.
Если есть возможность приобретайте другую конфигурацию для своего учета.
4. prodines 107 11.02.14 09:14 Сейчас в теме
(3) WEBBY,
Поддержка у ВГДБ плохая очень, конфигурация сырая. Очень часто не успевают за законодательной сменой формул расчета тарифов

Ещё бы! А как она может быть хорошей (поддержка), если поддерживать данную конфигурацию чрезвычайно трудно с точки зрения программиста 1С? Думаю, даже авторам конфигурации. Это настоящая китайская головоломка, или неимоверное хитросплетение программного кода. Вложенные до 4-5 уровней циклы, из которых вызываются тучи мелких функций (вызывающих другие функции и т.д.) - попробуй-ка в них разобраться! И всё это, очевидно, есть результат катастрофической нехватки времени при разработке конфигурации - когда сделали "на коленке" "абы работало" - и потом не переписали по-человечески. Да, предметная область реально непростая - и в одной квартире могут быть 2 хозяина, и счетчиков может быть до 3 штук - причём расчет может быть по норме, по среднему, и по показаниям, зачастую одна величина по пропорции делится на некие доли. Но всё равно структура данных могла бы быть гораздо проще.
5. Sanella_nt 11.02.14 09:26 Сейчас в теме
Такие конфигурации как правило выходят очень сырыми, сам не однократно исправлял косяки программистов, а скорее всего разрабатывают по методу итераций сначала сделали тяп ляп, а потом с каждым обновлением приводить в порядок это чудо, сейчас такой метод разработки ПО очень популярен, примеров можно привести уйму. И к сожалению первым пользователям такого ПО приходиться страдать.
6. Азбука Морзе 104 11.02.14 10:07 Сейчас в теме
...к сожалению первым пользователям такого ПО приходиться страдать.


Эту конфигурацию от ВГДБ внедрял 2010-11 годах. Проблемы, конечно, были, но судя по откликам их не только не исправили, но и усугубили. Первым пользователям еще повезло:)
10. prodines 107 11.02.14 14:08 Сейчас в теме
(6) Азбука Морзе,
Проблемы, конечно, были, но судя по откликам их не только не исправили, но и усугубили.

Поскольку архитектура метаданных в этой конфе очень сложна, то именно из этого и проистекают все огромные проблемы её программного обслуживания.
(7) AllexSoft,
надо писать свое и под себя, такие узконаправленные отраслевые вещи

Едва ли это выход. Вы же пойдёте тем же самым путём. Тут в ином проблема: в России труд программиста традиционно не ценится и просто непонимаем заказчиком - отсюда и сниженное финансирование на разработку - отсюда и такие дикие проблемы. С нуля трудно разработать оптимальную архитектуру - ведь предметная область неочевидна. Но другое дело после создания конфы - в этот момент уже отлично знаешь предметную область, и поэтому можешь её с нуля переписать (ради упрощения её программного обслуживания) - а вот это как раз не делается.
(9) AllexSoft,
эта работа как правило не благодарная...

Как минимум, она просто нелепая. Будь архитектура нормальной - то программная поддержка заметно упростилась бы.
7. AllexSoft 11.02.14 10:14 Сейчас в теме
Еще раз убедился что негативный опыт не только у меня.. надо писать свое и под себя, такие узконаправленные отраслевые вещи
8. Xatori111 18 11.02.14 10:26 Сейчас в теме
Сейчас занимаюсь обновлениями Общепита Проф (Рарус), могу так же не очень лестно отозваться об авторах этого чуда, очень много ошибок, причём довольно часто ошибки именно из за спешки разработки (Где то забыли переменную передать, где то не то передают). Ужас в общем :). Но будем радоваться, пока есть такие "Хорошие люди" и мы не останемся без работы.
9. AllexSoft 11.02.14 12:28 Сейчас в теме
(8) Xatori111, эта работа как правило не благодарная... тебе никто не скажет спасибо за то что ты поправил баги в типовом документе или отчете, любой заказчик скажет "ну мы же купили программу у вас, а она не работает"
IvanKh; Sibiryak; +2 Ответить
11. tsmgeorg@gmail.com 11.02.14 15:35 Сейчас в теме
Хочу поделиться своим опытом разработок в сегменте ЖКХ. Сразу скажу, что надо делить билинг ЖКХ, т.е расчеты с потребителями жилищно-коммунальных услуг и управленческий учет в сегменте ЖКХ. Работую в крупной строительной московской компании, где иерархия организаций строится следующим образом: Расчетно-кассовый центр, Управляющие компании (10 организация), и Поставщики услуг (более 50). Сразу говорю, нормальное программное обеспечение на рынке как для ведения расчетов с потребителями ЖКУ (Функции расчетно-кассового центра) так и для ведения учета управляющих компаний, ТСЖ и т.п. отсутствует. Для учета билинга есть следующие более менее нормальное ПО: Айлант: Управление ЖКХ, Бит Жилищно Коммунальное Хозяйство. Основого, чего нет в этих ПО, так это механизм перерасчетов (Как это реализовано в ЗУП), для реализации которого требуется глубокое знание механизма перерасчетов и непосредственно предметной области. Мы в частности работали на БИТ, но, честно никому не порекомендую покупать вообще что-то у них, дописывать мне приходилось практически все, начиная от механизмов по учету счетчиков заканчивая начислениями, разработкой практически с нуля модуль кассовых операций и т. п. В итоге мы перешли на другое ПО не на базе 1С "Стэк ЖКХ", разработчики которого уверяли нас, что у них есть механизмы перерасчетов. В итоге оказалось, что это ПО оказалось очередной "Шляпой", плюс они просят деньги за исправление их же ошибок зачастую). Например, как вы думаете, господа программисты, можно ли хранить различные сущности в одной таблице SQL, а сущности это различные виды документов к примеру и справочников? Думаю нормальный человек скажет что нельзя. В общем я могу ругаться бесконечно и говорить о косяках существующего на рынке программного обеспечения по учету расчетов с потребителями ЖКУ.....
Но, дорогие программисты, это еще не все. Для управленческого учета управляющих компаний, тсж для решения таких задач как бюджетирование, планирование, подомовой учет и т. п. тоже нет ни одного программного обеспечения ни у БИТА, ни у ВДГБ, ни у Айланта и т. п. не решает актуализированные задачи управляющих компаний и ТСЖ, а самое главное взаимодействие между ними, в том числе с расчетно-кассовым центром.
В итого в нашей компании пошли таким путем. Используем Стэк ЖКХ для учета билинга, для управленческого учета УК и ТСЖ используем самописную конфигурацию, которую дорабатываем и по сей день, так как сами понимаете ЖКХ есть ЖКХ, для бюджетирования используем Инталев.
В итоге, господа, пришел к выводу, что бабушки так же будут чухать управляющие компании, расчетно-кассовые центры и тсж, покак хотя бы там не наведется порядок, причем по всей России)))), а порядок будет, когда будет нормальный учет, а для этого нужно хорошее ПО, отвечающее всем требованиям. Так что хоть сам пиши с нуля :)))) Удачи в разработке в сегменте ЖКХ, коллеги))))
petrpk; SotNick; DoReMi; LeXXik; +4 Ответить
13. AllexSoft 11.02.14 15:45 Сейчас в теме
(11) m.cibikov@ekcd.ru, к сожалению такая же ситуация с энергетиками, водоканалами, строительством, общепитом, тур-бизнесом, гостиничным бизнесом это из того что я сам искал, пока работал в фране. И к сожалению нормальных конф на 1С нет( везде эти недоделки от БИТа, Раруса, ВДГБ ( их даже в руки брать не хочется
12. AllexSoft 11.02.14 15:42 Сейчас в теме
У меня в свое время была идея написать ПО для расчетного блока ЖКХ, даже были кролики которые готовы были быть бета-тестерами от безысходности ситуации, рассчитывалось и рассчитывается все в Excel до сих пор... у меня время не хватило, и были более интересные и прибыльные проекты
14. tsmgeorg@gmail.com 11.02.14 15:45 Сейчас в теме
(12) AllexSoft, Расчетный блок, это минимум что надо сделать на самом деле, а это офигенные трудозатраты
15. AllexSoft 11.02.14 15:48 Сейчас в теме
(14) m.cibikov@ekcd.ru, у меня есть своя конфа для отелей, там расчетный блок ничуть не меньше.. я знаю о чем говорю (обслуживал 4 УК по городу).. так можно и одному осилить, у меня разработка+вылавливание багов заняло примерно год
16. tsmgeorg@gmail.com 11.02.14 15:53 Сейчас в теме
(15) AllexSoft, Это хорошо, главное чтобы платили за это) Я полгода пишу управленческий модуль, наверное еще полгода. Я говорю про ситуацию в комплексе, и не про разработки для отелей), а это очень много работы, к тому же основное это не программирование, а хорошее знание предметной области, законодательства в сегменте ЖКХ.
17. tsmgeorg@gmail.com 11.02.14 15:54 Сейчас в теме
Ну к примеру, модули "Паспортный стол", "Учет счетчиков", "Учет лицевых счетов" и т.п, операция закрытия месяца я думаю за год одному можно написать если ничем другим не заниматься, я бы хотел, но кто кормить будет семью)
18. AllexSoft 11.02.14 16:13 Сейчас в теме
(17) m.cibikov@ekcd.ru, согласен, все упирается в трудозатраты в конечном итоге, ну и знание области... свою конфу например писал просто из личного интереса, по вечерам.. кстати по трудозатратам и сложности гостиничный комплекс автоматизировать можеть быть сложнее чем ЖКХ, в ЖКХ хоть и путанное но все же есть регламенты, законодательная база... а в российских гостиницах, санаториях, отелях кто на что горазд, "придумок" чудо-руководителей в разы больше, к сожалению ( особенно беда с теми же расчетами, прайсы все черт знает что.
19. prodines 107 18.02.14 15:43 Сейчас в теме
Документ "КВП_НачислениеУслуг". Позволяет провести одно и то же начисление - для одних и тех же лицевых счетов. Правда, при проведении всё-таки пишет предупреждение: "В документе <Начисление услуг 00000007 от 31.01.2014 11:59:58> для лицевого счета <00000013> уже произведено начисление по услуге <Эл.снабжение>!".

А вот в 1С:Зарплата и Управление Персоналом аналогичный по смыслу документ "Начисление зарплаты работникам организации" просто не даст заполнить подбором свою табличную часть при попытке ввести туда уже посчитанные данные - напишет что-то вроде "Данные для заполнения табличной части не обнаружены." А в этой конфе подбор позволяет заполнить табличную часть уже посчитанными данными.
20. prodines 107 20.02.14 15:08 Сейчас в теме
Новые чудеса: поскольку в УУК нет реквизита "расчетный период", как в ЗУПе, то за таковой принимается дата документа. Не очень удобно, ну ладно. Но дальше - веселей: расчетный период программа вычисляет как ПОСЛЕДНИЙ день месяца даты - тогда как в ЗУПе - как ПЕРВЫЙ. Есть разница?

Ещё один прикол - просто забавный: документ "КВП_КорректировкаНачислений". Имеет табличную часть. Вводим туда несколько строк, сохраняем, закрываем. Открываем снова - и - опа! - введённые строки сами собой переформатировались в дерево - и теперь уже надо работать с деревом. Вот такие чудеса. :)
21. prodines 107 26.02.14 14:49 Сейчас в теме
1. Документ "Установка льгот". Реквизит шапки - Лицевой счет - не записывается в движения документа. А зачем тогда вообще нужно было его делать? Нарушение принципа (архитектурной) связности программы.

2. Отчет "КВП_КвитанцииИзвещения". В обработчике "ПриОткрытии" вызывает аналогичную внешнюю обработку - имя которой задаётся в "Учетной политике ЖКХ". Зачем было делать такое непрозрачное решение? Думаю, что правильнее было бы вынести процедуру авто-выбора внешней обработки за пределы отчета. Нигде и никогда в стандартных конфигурациях я такого не видел - чтобы встроенный отчёт автоматически вызывал внешний - это делается извне отчета обычно. Зачем отступать от общепринятых канонов программирования?

3. Основной документ - начисление - в своих движениях не пишет для каждого лицевого счета, как ему был посчитан расход - по норме или по среднему. Зачастую трудно это понять - формальное начисление по среднему может при нехватке данных превратиться на самом деле в начисление по норме - поэтому надо бы явно писать в движениях документа - по среднему или по норме (для каждого лицевого счета). Сейчас буду прикручивать это.
22. Consultant_1C 171 26.02.14 15:46 Сейчас в теме
3. Создатели УУК, видимо, и не подозревали о том, что в 1С версии 8 существует такой объект языка, как регистры расчёта. Все расчеты построены исключительно на регистрах накопления - хотя, ясное дело, использовать вместо них регистры расчёта было бы гораздо логичнее.


Вы имеете в виду расчеты ЗП или расчет услуг ЖКХ ???

7. В квитанции в макете табличного документа используются именованные области вместо секций - это и не наглядно, и метод табличного документа "Присоединить" не работает с именованными областями - а только с секциями.


Почему ? 0_о
23. prodines 107 03.03.14 11:09 Сейчас в теме
(22) Consultant_1C,
Почему ? 0_о

Да, я действительно ошибся с этим утверждением - сделал специально пробный внешний отчёт и проверил - всё-таки метод "Присоединить" работает и с именованными областями. Хотя всё равно - именованные области - это крайне не наглядно - по сравнению с секциями.

По поводу справочника "КВП_Услуги": у него и есть реквизит типа "КВП_ВидУслуги" - я бы ещё добавил туда предопределённые значения: Отопление, ХВ Снабжение, и т.д. С предопределёнными было бы надёжней работать из запросов.
24. prodines 107 27.03.14 14:09 Сейчас в теме
В справочнике "УПЖКХ_Помещения" код имеет тип "Число" и служит для хранения номера квартиры. Также в справочнике есть реквизит "СтроительныйНомер" с типом "Строка" - там тоже хранится номер квартиры. Если у квартиры номер, допустим, "1а" (бывает такое), то его приходится записывать в поле "СтроительныйНомер" - потому что в код справочника его никак не запишешь - "1а" никак не приведёшь к числовому типу (без потерь информации).

Надо было делать код справочника тоже с типом "Строка" - а не с типом "Число". Из-за того, что код и строительный номер имеют разные типы, то в запросе невозможно их сравнить. А сравнивать их приходится постоянно - за номер квартиры я принимаю "СтроительныйНомер" (вдруг он содержит букву), а если "СтроительныйНомер" не заполнен - то я беру код справочника. Так вот, я не могу в запросе сделать определение номера квартиры - потому что запрос не поддерживает приведение типов - т.е. я не могу в запросе присвоить полю либо код, либо строительный номер - у них разные типы. Точнее, могу - но получится поле составного типа - и толку от него не будет.

Приходится заниматься идиотизмом - выгружать результат запроса в таблицу значений, в цикле делать преобразование числа в строку, и затем опять загружать полученную таблицу значений в запрос.
25. Maxsj_Payne 6 04.04.14 05:52 Сейчас в теме
Добрый день!

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


А почему вы не используете реквизит суффикс? Ведь он был создан как раз для таких целей. Если у вас номер квартиры: 1а,1-а,1/2,1 Цоколь и т.д., то 1 вы ставите в код, а остальное (а,-а,/2, Цоколь) в суффикс. При этом в наименовании квартиры будет стоять кв.1а.
Для вывода в отчеты или выгрузки пользуетесь так:

1. если нужно вывести кв.1а - берете из реквизита Наименование;
2. если нужно вывести 1а, - берете из реквизитов Код и суффикс (Код + Суффикс);
3. если нужно отсортировать по номеру квартиры и суффиксу, то так: Сортировать по Код,Суффикс

СтроительныйНомер при этом практически дублирует реквизит Наименование.
33. prodines 107 10.04.14 10:50 Сейчас в теме
(25) Maxsj_Payne,
А почему вы не используете реквизит суффикс?

Вы невнимательно прочитали то, что я написал.
2. если нужно вывести 1а, - берете из реквизитов Код и суффикс (Код + Суффикс);

Да нельзя это сделать. Потому что "Код" имеет тип "Число" (об этом я писал), а "Суффикс" имеет тип "Строка" - поэтому если в запросе сделать "Код + Суффикс" - то, скорее всего, выскочит ошибка времени исполнения, а если и не выскочит - то получим поле составного типа (Число Или Строка) - и толку от этого ноль.

Хоть Суффикс, хоть СтроительныйНомер использовать - без разницы. Корень зла в том, что "Код" ни в коем случае не следовало делать типа "Число" - а только типа "Строка".
39. Maxsj_Payne 6 29.04.14 07:51 Сейчас в теме
(33) prodines,

Да нельзя это сделать. Потому что "Код" имеет тип "Число" (об этом я писал), а "Суффикс" имеет тип "Строка" - поэтому если в запросе сделать "Код + Суффикс" - то, скорее всего, выскочит ошибка времени исполнения, а если и не выскочит - то получим поле составного типа (Число Или Строка) - и толку от этого ноль.

Ну почему тогда не написать так: Строка(Код)+Суффикс? Что в этом плохого?
Код был сделан числом я так понимаю, для того, чтобы квартиры сортировались хорошо, ведь строковый тип будет сортировать так (1,10,12,13...,2,20,21...). А для пользователей важно быстро находить лицевые счета по номеру квартиры. Я думаю разработчики исходили из этой логики.
41. prodines 107 06.05.14 14:20 Сейчас в теме
(39) Maxsj_Payne,
Ну почему тогда не написать так: Строка(Код)+Суффикс? Что в этом плохого?

Это невозможно. В запросе невозможно. Запросы не поддерживают преобразования типов. И я выше написал уже об этом.
26. Maxsj_Payne 6 04.04.14 06:02 Сейчас в теме
Кто пользуется в программе типовой обработкой Выгрузка реестров платежей?

Я не знаю как сейчас, может уже разработчики и исправили это, но 3 года назад было так:

Когда запускали выгрузку по всем лицевым счетам (15 000 л/с), обработка по каждой сохраняемой в файл строке выводила эту строку в поле служебных сообщений. При этом выгрузка выполнялась порядка 30-40 минут.
Я посчитал, что эта информация лишняя, зачем мне, а тем более пользователям, такой объем информации на экране, ведь я все равно не читаю, лучше тогда прогресс бар поставить, чтобы процент выполнения видеть. Закомментировал вывод на экран этих сообщений. Выгрузка стала выполнятся в течении 5-7 минут.
27. F1215 04.04.14 07:55 Сейчас в теме
Поддерживаяю Конфигурация с огромными багами и ошибками
28. tsar 04.04.14 15:10 Сейчас в теме
В сфере ЖКХ обратите внимание на "1С:Предприятие 8. Расчет квартплаты и бухгалтерия ЖКХ", сайт http://www.kv-plata.ru/products
Вроде, достойная конфигурация. С точки зрения кода не знаю, особо не всматривался, но функционал хороший, при внедрении дописывать практически ничего не приходилось.
29. prodines 107 08.04.14 11:30 Сейчас в теме
(28) tsar, а чем Ваш пост отличается от просто рекламы, а?

Регистр сведений "КВП_СостояниеПомещения". Измерения - "Объект" с типом "СправочникСсылка.УПЖКХ_Помещения", ресурсы - Состояние (ПеречислениеСсылка.КВП_СостоянияПомещения), КатегорияКвартиры (ПеречислениеСсылка.КВП_КатегорииКвартир). Регистр сведений - Непериодический, Независимый.

Вопрос - ЗАЧЕМ?

Зачем было делать этот регистр сведений? Ведь достаточно было просто в справочник "Справочники.УПЖКХ_Помещения" просто добавить 2 реквизита, соответствующих ресурсам этого регистра - и всё.

Я бы понял ещё, если бы этот регистр был периодическим - так нет же, он непериодический!
31. tsar 09.04.14 13:59 Сейчас в теме
(29) prodines, Наверно ни чем :). Просто рассказал про конфу с которой приходилось работать и, возможно, услышать отзывы от других людей, кто с ней сталкивался.
30. rjhonson 08.04.14 12:48 Сейчас в теме
Полезная статья по актуальной тематике. Да действительно, внедренные и отраслевые решения имеют массу отрицательного. Поэтому прежде чем использовать их необходимо очень тщательно изучить
32. prodines 107 10.04.14 09:16 Сейчас в теме
Я уже писал ранее, что в этой конфигурации очень часто используются циклы вместо запросов. Я же считаю, что запросы должны иметь приоритет над циклами - т.е. везде, где циклы можно заменить запросами, это должно делаться. Потому что циклы:

1. Снижают производительность.
2. Затуманивают программный код.
3. Ухудшают масштабируемость кода. Например, когда рассчитывается тариф для одного лицевого счета (а тариф может зависеть от количества приживающих, характера точек потребления ресурса, степени благоустройства и пр.), то применяется некая функция "foo()" - с циклами внутри. Потом возникает задача сделать то же самое - но уже для всех лицевых счетов здания. Если бы foo() была на запросах, а не на циклах - то достаточно было бы слегка переделать запрос - чтобы приспособить foo() к пакетному применению. А так приходится просто тупо в цикле вызывать foo() - что снижает производительность и создает искусственное нагромождение кода.

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

Документ "КВП_НачислениеУслуг". Модуль объекта, процедура "РаспределитьПропорционально".

		
                ЛицевыеСчета = СтрокаВетки.Строки.НайтиСтроки(ПараметрыОтбора, Истина);
...
                СписокОбъектов = Новый СписокЗначений;
		ОбщийРасходПоИПУ = 0;
		Для Каждого СтрокаЛС ИЗ ЛицевыеСчета Цикл
			
			// Расход для распределения ОДН не уменьшается в случаях:
			//
			// 1. Индивидуальное потребление коммунального ресурса рассчитано по формуле №3 постановления 354 по показаниям коллективного прибора учета.
			// 2. Расход ОДН рассчитывается по норме по формуле 15 постановления 354 при отсутствии коллективных ПУ (на здание и подъезды).
			
			ОбщийРасходПоИПУ = ОбщийРасходПоИПУ + ?(НЕ РасчетПоФормуле3и14(СтрокаЛС.ТипРасчета) И Не РасчетПоФормуле15, СтрокаЛС.ПоказаниеСч, 0);
			МассивДолейПоложительныйРасход.Добавить(СтрокаЛС.Доля);
			МассивДолейОтрицательныйРасход.Добавить(СтрокаЛС.ДоляОтрицательныйРасход);
			СписокОбъектов.Добавить(СтрокаЛС.Объект);
		КонецЦикла;
Показать


Этот кусок кода в цикле подсчитывает сумму расходов индивидуальных приборов учёта Цикл обходит часть дерева, полученного ранее в другом запросе - за пределами этой функции. Очевидно, что эту сумму можно было бы подсчитать здесь также в запросе - просто как итог по индивидуальным расходам. Ещё там создаётся массив долей попутно - но это вообще можно было бы не делать - а в запросе добавить ещё одно рассчитываемое поле - "Доли".
35. tsar 10.04.14 16:17 Сейчас в теме
(32) prodines, Может немного не в тему, но всё же. В своё время был прикол с одной конфой под 7.7 от Раруса. В приходной накладной при изменении розничной цены товара что-то страшное происходило. Там все данные табличной части документа уходили в ТЗ, что-то там с этим ТЗ делалось и потом обратно эти данные садились в ТЧ документа. Обрабатывалась таким образом именно вся табличная часть, хотя цену меняешь только в одной строке. А прикол в том, что у нас накладные часто были большие (по 2000 строк), загружались из txt-файлов от поставщиков. Вот из-за этой хрени ввод розничной цены 1-ой позиции занимало 2 минуты - ввёл цену и ждёшь сидишь:)
34. prodines 107 10.04.14 15:32 Сейчас в теме
Обнаружен новый прикол: необоснованное переименование имён временных таблиц запроса.

Пример:

Документ "КВП_НачислениеУслуг", модуль объекта.

Функция ПолучитьТекстЗапросаПоПоказаниямИндивидуальныхПУ()

ВЫБРАТЬ
.....
ПОМЕСТИТЬ ТаблицаЗакрепленныхПУНаЛС
......
;
ВЫБРАТЬ
.....
ИЗ
   ТаблицаЗакрепленныхПУНаЛС КАК ТаблицаСчетчиковЛС
.....
КонецФункции
Показать


За каким хреном, спрашивается, потребовалось переименовывать "ТаблицаЗакрепленныхПУНаЛС" в "ТаблицаСчетчиковЛС"? Чтобы сбить с толку таких, как я? :) И таких переименований ещё несколько в этом запросе. Есть, правда, и места, где нет таких переименований.

Так программировать нельзя - нарушая негласные принципы культурного оформления кода. Такие вещи просто повергают в изумление - они воспринимаются как совершенно неожиданные ловушки, оставленные в коде авторами программы, всё это сбивает с толку и вызывает скептическое отношение к подобным творениям.
36. prodines 107 14.04.14 13:20 Сейчас в теме
Очередная порция веселья от разработчиков конфигурации.

1. Документ "КВП_НачислениеУслуг". Модуль формы:

//Обработчик события "ПриВыводеСтроки" дерева значений "ДеревоУслуг"
Процедура ДеревоУслугПриВыводеСтроки(Элемент, ОформлениеСтроки, ДанныеСтроки)
	
	Если ДанныеСтроки.Родитель = Неопределено Тогда
		
		ТекущийЛС = ДанныеСтроки.ЛицевойСчет;
		СтрокаЛС = мТаблицаДанныхЛС.Найти(ТекущийЛС, "ЛицевойСчет");
		Если НЕ СтрокаЛС = Неопределено И ТипЗнч(ТекущийЛС) = Тип("СправочникСсылка.КВП_ЛицевыеСчета") Тогда
			ОформлениеСтроки.Ячейки.Здание.УстановитьТекст(СтрокаЛС.Здание);
			ОформлениеСтроки.Ячейки.Квартира.УстановитьТекст(СтрокаЛС.Помещение);
			ОформлениеСтроки.Ячейки.Владелец.УстановитьТекст(СтрокаЛС.Владелец);
			ОформлениеСтроки.Шрифт = Новый Шрифт(ОформлениеСтроки.Шрифт, , , Истина);
		КонецЕсли;
		
		Если (ДанныеСтроки.Ном%2) > 0 Тогда
			ОформлениеСтроки.ЦветФона = Новый Цвет(255, 251, 240);
		Иначе
			ОформлениеСтроки.ЦветФона = Новый Цвет(255, 255, 255);
		КонецЕсли;
		ОформлениеСтроки.Ячейки.Тариф.ТолькоПросмотр         = Истина;
		ОформлениеСтроки.Ячейки.Количество.ТолькоПросмотр    = Истина;
		ОформлениеСтроки.Ячейки.Начислено.ТолькоПросмотр     = Истина;
		ОформлениеСтроки.Ячейки.Договор.ТолькоПросмотр       = Истина;
		
	Иначе
Показать


Ну это просто клиника! Устанавливать в обработчике вывода строки табличной части документа некие смысловые величины - это нонсенс. Главное, есть же там запрос, который формирует контент, загружаемый в ТЧ - так нет же, почему-то в тот запрос данный код не вошёл - а он выделен в отдельный - безграмотный, корявый, нарушающий все каноны правильного программирования кусок.

А вот как выглядит обработчик "ПриПолученииДанных":

//Обработчик события "ПриПолученииДанных" дерева значений "ДеревоУслуг"
Процедура ДеревоУслугПриПолученииДанных(Элемент, ОформленияСтрок)
	
	СписокЛС = Новый СписокЗначений();
	Для Каждого СтрокаОформления Из ОформленияСтрок Цикл
		СписокЛС.Добавить(СтрокаОформления.ДанныеСтроки.ЛицевойСчет);
	КонецЦикла;
	
	мТаблицаДанныхЛС = ПолучитьПараметрыЛицевыхСчетовДляВыводаВТаблицах(СписокЛС, Дата, мЗапросДанныхЛС);
	
КонецПроцедуры
Показать


Нет слов просто. «В детстве таких, как Вы, я убивал на месте. Из рогатки.» (Остап Бендер). Походу писали эту конфу во франче вчерашние студенты на коленке - однозначно.

2. Документ "УПЖКХ_ВводПоказанийСчетчика". Имеет реквизит шапки "Услуга". И имеет реквизит табличной части "Услуга". Причём в форме документа реквизит ТЧ "Услуга" не отображается. Заполняется реквизит ТЧ "Услуга" при перевыборе реквизита шапки "Услуга" и нажатии кнопки ТЧ "Заполнить".

Вопрос: зачем? Зачем было лепить в табличную часть реквизит "Услуга", если он и так уже есть в шапке. А в движения документа попадает, внимание, как вы думаете что? Правильно - реквизит ТЧ "Услуга", а не одноимённый реквизит шапки. Если этого не знать, и просто сменить реквизит шапки "Услуга" и перепровести документ - то услуга в его движениях не изменится! И последующее начисление не пройдёт, соответственно.

Вот так-то работают суровые йошкар-олинские программисты 1С.
37. prodines 107 17.04.14 15:46 Сейчас в теме
Пытаюсь реализовать в этой программе расчет по формуле 9 постановления 354. Да, эта программа - абсолютно безумна, разобраться в ней досконально не-автору - невозможно, т.к. программа неоправданно переусложнена. Хочется плюнуть и написать заново нормальную программу - вместо этого издевательства над здравым смыслом.
38. prodines 107 25.04.14 10:22 Сейчас в теме
Документ "УПЖКХ_ВводПоказанийСчетчика". Табличная часть "Главная", реквизит "Коэффициент". У него разрядность - 3, а этого оказалось недостаточно для точного распределения расхода одного счетчика по нескольким лицевым. А я смотрю - какого черта полезли неправильные расходы по таким лицевым, причём расхождения на небольшие числа?

Увеличил разрядность дробной части с 3 до 15, а то же самое в колонке "Доля" табличного поля "ДеревоПоказаний". И всё стало нормально - расход стал распределяться точно.

Из этой истории можно сделать следующий вывод: зачем хранить в документе расчётные коэффициенты, участвующие в расчётной пропорции? Идеологически более правильно эти коэффициенты каждый раз рассчитывать (при вычислениях) в запросе - тем более, что длина дробной части у чисел в запросе значительно больше.
40. LeXXik 29.04.14 11:13 Сейчас в теме
Тоже занимался внедрением конфигураций ЖКХ, и могу сказать следующее: никто не совершенен! Не видел ни одной конфы, где всё было бы реализовано по-человечески! Хоть Камин:Квартплата, хоть ВДГБ:ТСЖиУК. Сервер, по слухам, более или менее, но я его в руках не держал. А у остальных где-нибудь, да что-то вылезет косячное. В общем, надо, видимо, что-то своё реализовывать - тогда и винить некого будет. )))
42. tsmgeorg@gmail.com 07.05.14 17:09 Сейчас в теме
Хочу поделиться своим опытом разработок в сегменте ЖКХ. Сразу скажу, что надо делить билинг ЖКХ, т.е расчеты с потребителями жилищно-коммунальных услуг и управленческий учет в сегменте ЖКХ. Работую в крупной строительной московской компании, где иерархия организаций строится следующим образом: Расчетно-кассовый центр, Управляющие компании (10 организация), и Поставщики услуг (более 50). Сразу говорю, нормальное программное обеспечение на рынке как для ведения расчетов с потребителями ЖКУ (Функции расчетно-кассового центра) так и для ведения учета управляющих компаний, ТСЖ и т.п. отсутствует. Для учета билинга есть следующие более менее нормальное ПО: Айлант: Управление ЖКХ, Бит Жилищно Коммунальное Хозяйство. Основого, чего нет в этих ПО, так это механизм перерасчетов (Как это реализовано в ЗУП), для реализации которого требуется глубокое знание механизма перерасчетов и непосредственно предметной области. Мы в частности работали на БИТ, но, честно никому не порекомендую покупать вообще что-то у них, дописывать мне приходилось практически все, начиная от механизмов по учету счетчиков заканчивая начислениями, разработкой практически с нуля модуль кассовых операций и т. п. В итоге мы перешли на другое ПО не на базе 1С "Стэк ЖКХ", разработчики которого уверяли нас, что у них есть механизмы перерасчетов. В итоге оказалось, что это ПО оказалось очередной "Шляпой", плюс они просят деньги за исправление их же ошибок зачастую). Например, как вы думаете, господа программисты, можно ли хранить различные сущности в одной таблице SQL, а сущности это различные виды документов к примеру и справочников? Думаю нормальный человек скажет что нельзя. В общем я могу ругаться бесконечно и говорить о косяках существующего на рынке программного обеспечения по учету расчетов с потребителями ЖКУ.....
Но, дорогие программисты, это еще не все. Для управленческого учета управляющих компаний, тсж для решения таких задач как бюджетирование, планирование, подомовой учет и т. п. тоже нет ни одного программного обеспечения ни у БИТА, ни у ВДГБ, ни у Айланта и т. п. не решает актуализированные задачи управляющих компаний и ТСЖ, а самое главное взаимодействие между ними, в том числе с расчетно-кассовым центром.
В итого в нашей компании пошли таким путем. Использу управляющие компании, расчетно-кассовые центры и тсж, покак хотя бы там не наведется порядок, причем по всей России)))), а порядок будет, когда будет нормальный учет, а для этого нужно хорошее ПО, отвечающее всем требованиям. Так что хоть сам пиши с нуля :)))) Удачи в разработке в сегменте ЖКХ, коллеги))))
65. prodines 107 14.05.14 15:09 Сейчас в теме
(42) m.cibikov@ekcd.ru, а что такое "управленческий учет в сегменте ЖКХ"?
43. tsmgeorg@gmail.com 07.05.14 17:27 Сейчас в теме
Сейчас веду разработку, разрабатываю регламенты на операцию "Закрытие месяца" расчетно-кассовых центров.
1. Функциональная схема процедуры закрытия месяца
Закрытие месяца – специальная процедура, гарантирующая неизменность объектов учета за данный месяц при любых последующих изменениях. Перед закрытием месяца все первичные документы, справочники и их параметры, учетные данные должны быть введены и выверены. Процедура закрытия месяца состоит из ряда регламентных операций, соответствующих определенным разделам ведения оперативного учета. Закрытие месяца производится отдельными регламентными действиями в определенной последовательности. Результаты проведения регламентных операций фиксируются в «Акте по итогам работы за месяц» по соответствующим разделам оперативного учета


2. Разделы ведения оперативного учета
Операционный учет ведется по следующим разделам:
1. Ведение справочников жилого и нежилого фонда и их параметров;
2. Учет лицевых счетов;
а) Открытие/закрытие лицевого счета
Б) Учет параметров лицевых счетов
3. Учет проживающих;
а) Ведение справочника проживающих и его параметров
б) Регистрационный учет проживающих
4. Учет услуг;
а) Ведения справочников услуг и их параметров
в) Учет подключений/отключений жилищно-коммунальных услуг
б) Учет ставок и тарифов жилищно-коммунальных услуг
5. Учет счетчиков;
а) Ведение справочников счетчиков и их параметров
б) Учет подключения/отключения счетчиков
г) Учет показаний по счетчикам
6 Начисление жилищно-коммунальных услуг
7. Оплата жилищно-коммунальных и разовых услуг
а) Наличные платежи
б) Безналичные платежи
в) Другие способы оплаты
- Агентские платежи
- Платежи принципалу
8. Взаиморасчеты с принципалами и поставщиками;
9. Учет и уведомление о дебиторской задолженности по лицевым счетам.








Порядок выполнения процедуры «Закрытия месяца» по разделам ведения оперативного учета.

1. Ведение справочников жилого и нежилого фонда и их параметров:
а) Проверка заполнения площадей
2. Учет лицевых счетов:
а) Проверка корректности открытия/закрытия и деления лицевых счетов:
б) Проверка корректности заполнения параметров лицевого счета.
3. Учет проживающих:
а) Корректности заполнения документов регистрации/снятия с регистрации проживающих;
4. Учет услуг:
а) Проверка корректности подключения/отключения услуг на лицевых счетах;
б) Проверка корректности заполнения ставок и тарифов на предоставляемые услуги.
5. Учет счетчиков
а) Обнаружение значений ввода показаний счетчика, выходящих из диапазона допустимых;
б) Проверка корректности подключения/отключения счетчиков;
в) Проверка корректности заполнения параметров счетчиков.
6. Начисление жилищно-коммунальных услуг
а) Проверка корректности начисления по оплате по группе услуг «Разовые»;
б) Обнаружение ситуаций и их исправление по задублированным начислениям
в) Обнаружение и исправление ситуаций, где суммы начислений больше предельного значения
г) Обнаружение и исправление ситуаций по не рассчитанным актам снятия качества
в) Обнаружение и исправление ситуаций, по произведенным начислениям на группы услуг

7. Оплата жилищно-коммунальных услуг
а) Проверка корректности распределения платежных документов по услугам на лицевых счетах
б) Проверка корректности распределения платежных документов по двухсторонним договорам (Сторонние платежи). Данные платежи не должны попадать в оплату ЖКУ
в) Обнаружение и исправление ситуаций, где сумма переплаты больше предельного значения.
8. Взаиморасчеты с принципалами и поставщиками *
а) Проверка корректности заполнения управляющих компаний и договоров.
б) Проверка корректности заполнения поставщиков
в) Проверка заполнения прямых договоров с поставщиками;
9. Учет и уведомление о дебиторской задолженности по лицевым счетам
а) Обнаружение и уведомление жителей в случае, если сумма долга больше предельного значения


* - Договора с УК и поставщиками, а так же поставщики могут быть установлены, но дополнительно необходимо своевременно запускать обработку по запуску
44. пользователь 12.05.14 17:42
Сообщение было скрыто модератором.
...
45. пользователь 12.05.14 17:43
Сообщение было скрыто модератором.
...
46. пользователь 12.05.14 17:43
Сообщение было скрыто модератором.
...
47. пользователь 12.05.14 17:44
Сообщение было скрыто модератором.
...
48. пользователь 12.05.14 17:44
Сообщение было скрыто модератором.
...
49. пользователь 12.05.14 17:44
Сообщение было скрыто модератором.
...
50. пользователь 12.05.14 17:45
Сообщение было скрыто модератором.
...
51. пользователь 12.05.14 17:45
Сообщение было скрыто модератором.
...
52. пользователь 12.05.14 17:46
Сообщение было скрыто модератором.
...
53. пользователь 12.05.14 17:46
Сообщение было скрыто модератором.
...
54. пользователь 12.05.14 17:46
Сообщение было скрыто модератором.
...
55. пользователь 12.05.14 17:46
Сообщение было скрыто модератором.
...
56. пользователь 12.05.14 17:47
Сообщение было скрыто модератором.
...
57. пользователь 12.05.14 17:47
Сообщение было скрыто модератором.
...
58. пользователь 12.05.14 17:47
Сообщение было скрыто модератором.
...
59. пользователь 12.05.14 17:47
Сообщение было скрыто модератором.
...
60. пользователь 12.05.14 17:47
Сообщение было скрыто модератором.
...
61. пользователь 12.05.14 17:48
Сообщение было скрыто модератором.
...
62. пользователь 12.05.14 17:48
Сообщение было скрыто модератором.
...
63. пользователь 12.05.14 17:48
Сообщение было скрыто модератором.
...
64. tsmgeorg@gmail.com 12.05.14 17:49 Сейчас в теме
Если кто-то заинтересуется в автоматизации механизмов управляющих компаний, можете писать из задавать вопросы мне.
66. prodines 107 21.05.14 11:41 Сейчас в теме
Одно для меня ясно - данная ВДГБ-конфигурация по своему внутреннему программному устройству перешла критический порог сложности, после которого её дальнейшая доработка теряет смысл. Эту конфигурацию следует переписать с нуля. Попытки вносить в неё доработки приводят лишь к нарастанию хаоса и потере контроля над поведением конфигурации. Она уже словно тришкин кафтан - латаешь её в одном месте - а она расползается в другом.

Причины, по которым это произошло (переход через критический порог сложности), следующие:

1. Главная причина - очевидная нехватка времени, выделенного на разработку. Жадность заказчиков, проще говоря.
2. Плохая продуманность структуры метаданных.
3. Использование циклов вместо запросов.
4. Явно было 2 или более разработчика этой конфигурации - которые не находили с собой общий язык в отношении оптимизации кода. Каждый лепил, как мог - "лишь бы работало". Получилось в итоге нагромождение курятников вместо дворца.
5. Разработчики конфигурации явно не имели опыта работы с 1С:Зарплата.
67. prodines 107 30.05.14 12:02 Сейчас в теме
Если на один счетчик закреплено более одного лицевого счета, то его показания нужно делить между этими лицевыми счетами. В данной конфигурации такое разделение осуществляется на этапе ввода показаний. Я считаю это идеологически неверным - подобное разделение должно производиться только в расчетном документе - а не в документе "Ввод показаний счетчика".
68. tsar 30.05.14 12:27 Сейчас в теме
(67) prodines, А почему на этапе расчётов? Мне кажется, при разделении при вводе показаний удобнее сразу проконтролировать корректность распределения. И при выполнении расчётов за период будет меньше нагрузки - это и так как правило не быстрая штука, чтоб её ещё нагружать распределение коммунальных счётчиков.
69. prodines 107 04.06.14 11:33 Сейчас в теме
(68) tsar,
А почему на этапе расчётов?

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

Разделение показаний на этапе ввода показаний в ВДГБ-конфигурации осуществляется как раз для этого, неизвестного мне случая. Вот что написано в комментариях в программном коде там:

// Когда на помещение открыто несколько л/с и один прибор учета установлен на эти лицевые счета,
// или когда один прибор учета установлен на несколько помещений,
// то распределение расхода по лицевым счетам/помещениям происходит на этапе ввода показаний.
// Если на одно помещение открыто несколько л/с и прибор учета установлен на помещение,
// то для распределения расхода по лицевым счетам необходимо учитывать доли.

Это как раз описание неизвестного мне случая. Мне это непонятно - если на одно и то же помещение зарегистрировано более одного лицевого счета - что это, если не коммунальная квартира? Никаких таких "долей" в Постановлении 354 не предусмотрено. Если у изолированной квартиры более одного собственника - по-моему, она при этом автоматически становится коммуналкой.

Впрочем, вот комментарий юриста: http://osincev.org/services/jilishnie-spori/Spori_o_razdele_licevih_schetov/

А если говорить о коллективном счетчике в коммунальной квартире, то характер распределения его показаний не известен на этапе ввода. Он становится известным только на этапе расчёта.
70. prodines 107 06.06.14 16:08 Сейчас в теме
Прошу знатоков в расчете ЖКХ подсказать мне:

У меня вопрос по перерасчетам. Вопрос такой: бывают ли ситуации, когда перерасчет общедомового потребления влечёт за собой перерасчет всех индивидуальных начислений? Ответ - да или нет, и я не знаю точно, какой ответ.

Возможный пример: в доме нет общедомового счетчика ГВ. В доме отключили горячую воду на 2 недели. Но расчет сделали сначала так, что будто не было никакого отключения, а теперь нужно сделать перерасчет. Как я понимаю, общедомовое потребление нужно однозначно перерассчитать. Но надо ли при этом перерассчитать для каждого абонента его долю в ОДН (общедомовые нужды)? Есть формула 15 в Постановлении 354 - и по ней однозначно не скажешь. Аналогично - для случая оказания услуг ненадлежащего качества.
71. tsar 08.06.14 15:22 Сейчас в теме
(70) prodines, да на сколько я знаю в законодательстве однозначно не сказано, как и в какие периоды делать перерасчёт. На своём опыте могу сказать - если по каким-то причинам необходимо пересчитать ОДН (то ли отключение ГВС было, то ли пришёл один собственник и принёс справку, что его пол месяца не было и ему надо обнулить и индивидуальные начисления и ОДН), то пересчёт просто учитывается в следующем периоде. Т.е. в текущем периоде заново не делаем расчёт, а просто это всё учитывается в следующем месяце. Если за один период 2 раза раздать квитанции разные, то не отобьётесь от жильцов потом:)
72. F1215 16.06.14 21:54 Сейчас в теме
73. Maxsj_Payne 6 17.06.14 07:25 Сейчас в теме
Коллеги, на неделе столкнулся с такой проблемой, что отчет по оплатам и Сводная ведомость выдают разные итоги по сумме оплат за период. Начал проверять сводную ведомость, оказалось, что в ней по некоторым лицевым счетам выводится задвоенные начисления и оплаты, из-за этого и происходит расхождение. Пока не хватило времени найти в чем причина задвоения, но вариантов нет, буду искать. Может кто уже сталкивался с этой проблемой?
74. TanisIntec 5 04.07.14 06:53 Сейчас в теме
(73) Maxsj_Payne, насколько я помню по оплатам есть приколюха что в него закрытые лиц. счета не берутся даж если он чтото платил
75. Maxsj_Payne 6 08.07.14 06:50 Сейчас в теме
(74) TanisIntec, Сейчас вроде бы попадают, отчет сводная ведомость выдает такие же данные, только некоторые начисления и оплаты задваивает.
76. TanisIntec 5 08.07.14 13:30 Сейчас в теме
но конфа тот еще геморой =)
77. _wlad_ 10.09.14 17:15 Сейчас в теме
Кто-нибудь пытался сделать выгрузку Электронного паспорта многоквартирного дома? Например из того же Айланта?

Кто смог найти XSD-схему для файла выгрузки?
79. GodFather_1 24.10.14 14:56 Сейчас в теме
(77) _wlad_, ходят слухи что эл. паспорта вовсе отменят. в связи с введением в строй ГИС ЖКХ, на однмо из семинаров в Москве сказали, что скоро 731 постановление и 1468 в корне будут переписаны
78. Nibblis 06.10.14 23:36 Сейчас в теме
Где-то читал аналитику на тему ошибок в программных продуктах - почерпнул оттуда интересный вывод. На самом деле безупречных программ вообще не существует, и программ без ошибок тоже, никто из матерых фирм производителей софта никогда не заявит что у них нет ошибок, речь может идти только о скорости и объеме их исправления, лучшие фирмы исправляют 99% ошибок, те кто отстают меньший объем в меньшие сроки.

Постфактум глядя на огромный продукт можно много говорить о том, как можно было бы сделать лучше, но гораздо сложнее спроектировать безупречную архитектуру в самом начале развития программы. в итоге конечная архитектура не играет роли, главное ведь как он сам работает. Программы с большим количеством пользователей обременены огромным обязательством - производитель программы не может резко менять всю архитектуру, потому что на неё уже завязаны данные пользователей, обученные операторы и т.д. Резкая смена курса катастрофе подобна - да код к примеру обновится станет красивым и гладким, но внешне для пользователей это:
во первых не будет заметно
во вторых им зачастую придется переучиться и убить кучу времени на это
в третьих зачастую смена архитектуры подразумевает не преемственность данных и обращение к истории данных может стать уже более проблематичным.
На самом деле в их (ВДГБ) программе уже были большие изменения которые устраняли пережитки прошлого так сказать - это зачастую происходило для пользователей незаметно - так как при обновлении на определенный релиз был незаметный внутренний перенос - так что я не сказал бы что ничто никуда не движется. да и судя по 'портянкам новостей и обновлений' программа активно развивается.

По опыту работы в сфере ЖКХ скажу, что законы честно говоря очень мутные не детализированы в мелочах, да каждый конкретный клиент думает, что прав только он и верна лишь его конкретная трактовка закона или так считает группа людей. но есть и другие группы людей которые считают неоспоримо верной другую трактовку - поэтому программы для ЖКХ кто бы что не говорил просто не могут быть простыми. Я видел программки более компактные, про которые обычно говорят, что они очень простые и понятные пользователю, но если сунуться в дебри, когда в квартире живет инвалид на инвалиде, да ещё это и многодетная семья, сверху куча разных соц. норм и прочие особенности учета, да еще то включаются, то отключаются счетчики то тут все эти экселевские программки встают колом и без сложных расчетов здесь не обойтись.
Tishu; IvanKh; mindcannon; +3 Ответить
80. GodFather_1 24.10.14 15:07 Сейчас в теме
Использование регистров расчета кстати нисколько не очевидно в задаче расчета коммунальных услуг. расчетные регистры здесь только кажутся очевидными. Расчетные регистры удобны только режимом вытеснения - аналог в сфере ЖКХ это корректировки, но и тут не всё так очевидно, чаще расчеты намного сложнее простого вытеснения.

Так что не вижу смысла лезти в код больших продуктов, знали бы вы как пишут код Индусы - но тем не менее все мы работаем в продуктах написанных их руками :-) я о Windows
81. sggolovnya 20.01.15 12:53 Сейчас в теме
правлю и дорабатываю ВДГБ: Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК. Конфигурация для 1С:Бухгалтерии 8 с 2012 года, переписала практически всю сейчас более менее работает и все равно натыкаешься на ошибки разработчиков вплоть до синтаксических как начинаешь делать что-то чего раньше не делал - очень сырая была в то время, сейчас не знаю, не обновлялись, поскольку конфа сильно переписана
84. Maxsj_Payne 6 03.06.15 09:04 Сейчас в теме
(81) sggolovnya, Переписывали расчетные модули или все же интерфейсные части?
Просто если совсем не обновлять, то я представляю сколько вам пришлось обновлять, и в дальнейшем еще. Ведь законы меняются, появляются новые виды расчетов. Как вы с этим справляетесь?
82. KingX 10.02.15 15:31 Сейчас в теме
Привет всем! Извиняюсь за спам! Но помогите решить проблему, вот в этом топике http://forum.infostart.ru/forum60/topic88611/?PAGEN_1=2 Вторая страница в конце. Очень прошу!
83. _Mary_ 20.04.15 12:29 Сейчас в теме
Не много работала с данной конфигурацией, пока только могу сказать, что она имеет множество мелких недостатков. Особенно не нравится, что она встраивается в бухгалтерию, а не идет отдельной конфигурацией. Будем надеяться, что в будущих версиях их исправят :)
85. Veronika12 20.07.15 11:31 Сейчас в теме
Я как рядовой бухгалтер хочу поделиться своими впечатлениями работы в данной программе. Приобрели в 2011 г. для небольшого ТСЖ. Идея данной программы неплохая, но работать в данной программе очень тяжело. Согласна с программистами, что ошибка разработчиков, что это не отдельная конфигурация. Всегда с ужасом ждем последующего обновления, т.к. каждый раз новые ошибки. Это хорошо - если есть в штате программист, но как правило в ТСЖ, ЖСК нет программистов и бухгалтер пытается как-то в ней работать самостоятельно. Разработчики никогда не отвечают на вопросы, уходят от ответов. В 2015 г. несколько раз открывала новые базы, но как начинается новое обновление, то постоянно после обновления - критические ошибки. Начиная с релиза 3.0.39.8 вообще не возможно обновиться. Лично мой совет бухгалтерам - не приобретать данную программу, если нет IT специалистов в штате.
starkovmail; LeXXik; +2 Ответить
86. Maxsj_Payne 6 21.07.15 18:42 Сейчас в теме
(85) Veronika12, Если нет своего IT специалиста, то лучше вообще не покупать никакие отраслевые решения. Либо иметь бюджет на привлечение фрилансеров, внештатных программистов или специалистов из франчайзи. Проблемы с обновлениями решаются так: в конфигурации ВДГБ ведется только учет коммунальных услуг, а в 1С:бухгалтерия раз в месяц формируются документы: по реализации товаров и услуг, оплатам. Вы так не пробовали?
87. AlPi 68 26.11.15 16:44 Сейчас в теме
Доброго дня, уважаемые коллеги. Мы также пользуемся этим продуктом, причем в расширенном виде, т.к. дополнительно приобрели их шаблон сайта http://www.vdgb-soft.ru/jsk/site_jkh/, поэтому хочу поделиться впечатлениями.
Плюсов, наверное, очень много в программе, но я как и большинство из Вас являюсь стороной принимающей заявки на проблемы, а не письма о счастливом использовании, поэтому делюсь наболевшим.
Приобретая данный продукт, новый владелец должен быть готов к вынужденной покупке ежегодно:
1. ИТС Проф (Потому, что как написано Выше, разработка выполнена на основании 1С Бухгалтерии 2.0)
2. ИТС Отраслевой (Потому, что она отраслевая и будьте уверены, что не смотря на правила 1С при обращении в техническую поддержку ВДГБ, если договор ИТС у Вас заключен с другим Франчем, Вы будете возмущены тем, что за все что Вы заплатили, приходится упрашивать Вам что-нибудь ответить);
3. Обновление на БИТРИКС (Нужно потому, что есть 4 пункт);
4. Обновление на модуль ВДГБ для 1С: Сайт управляющей компании ЖКХ, ТСЖ и ЖСК (Вот тут забавно, но практически каждое обновление 1С приводит к изменениям в конфигурации, которые меняют формат обмена с сайтом, таким образом, что параллельно не обновив сайт, Вы рискуете остаться с совершенно неработоспособным обменом между 1С и сайтом).

Теперь заплатив Выше указанное, что мы получили как поддержку. (Один из примеров 19.06.2015 v.2.0.64.14)
Итак при очередном обновлении выявилось, что при выгрузке на сайт пользователей личных кабинетов, их логины не проверяются на уникальность со всеми вытекающими. Т.е. появились на сайте жильцы которые видят квитанции и могут ввести показания счетчика соседа, а соседи при этом теряют ссылку на личный кабинет.
Обратившись в тех.поддержку по адресу clients@vdgb-soft.ru и описав проблему, нам пришлось самим найти ошибку, ее исправить и теперь при обновлении, мы сначала обновляем конфигурацию, а потом обновленную конфигурацию обновляем своими заплатками. При этом настойчивые письма с требованием исправить этот недочет в следующих конфигурациях с картинками что конкретно и в каком модуле нужно исправить ушли в никуда Как Вы понимаете это не единичный пример.

Поэтому, как заметили коллеги Выше, готовьтесь к тому, что после обновлений Вам потребуются услуги программиста.
А техническая поддержка нужна будет только Вашим бухгалтерам как служба выставления галочек.
88. Maxsj_Payne 6 02.12.15 03:32 Сейчас в теме
(87) AlPi, Полностью поддерживаю, поэтому моим клиентам проще отказаться от всех платных ИТС и т.д. Т.к. все равно нужно вмешательство программиста. Разобраться почему после обновления не грузятся оплаты, или в квитанциях ошибки, или пароли пропали, или еще много всего. Да и местный программист может быстрее реализовать потребность клиента в дополнительной автоматизации расчетов, перерасчетов, проверок всевозможных, выгрузок/загрузок.
89. KingX 09.12.15 05:15 Сейчас в теме
Всем привет! Подскажите, ни у кого не было проблем с копированием документа начисление на лицевые счета. Что то перестало копировать с заполненными полями, постоянно пустое все.
90. AlPi 68 16.12.15 16:47 Сейчас в теме
Наша текущая версия 2.0.64.14, все вопросы бухгалтеров решены. Из решенных заданный Вами вопрос не поступал.
91. KingX 17.12.15 05:40 Сейчас в теме
92. PokerFace 20 29.12.15 16:12 Сейчас в теме
Я работаю с этой конфигурацией уже 4 года. Приятно удивляет доработка функционала в ред. 3.0, жалко только, что почти каждый релиз с каким-нибудь косяком - приходится исправлять. Потому большинство клиентов держу еще на ред. 2.0. Самым проблемным местом считаю расщепление услуг в регистрации оплаты и закрытие периода ЖКХ - пришлось там много допиливать, но это конечно сложный вопрос сам по себе.
93. SGordon1 10.02.16 10:34 Сейчас в теме
А 65.3 под 2.0 НОрмальный релиз, что то льготы совсем не считает по моему....
94. mindcannon 14.02.16 00:41 Сейчас в теме
Доброго времени суток! Используем конфигурацию 2,0 уже полтора года, автоматизируем расчет стоимости потребления воды в небольшом поселке. Со скрипом, конечно, но заменили ею учет в Экселе. Больше всего проблем при внедрении вызвал неудобный интерфейс, множество нажатий кнопок для получения нужной инфы (особенно по счетчикам), пользователям старшего возраста сложно выявить собственные ошибки "почему оно начисляется неправильно" без помощи консультанта. После освоения блока жкх решили связать его бухгалтерией и столкнулись вот с проблемой: если в документе открытия лицевого счета можно выбрать лишь один договор, что делать, если выставляются услуги по нескольким организациям? Как заставить правильно подбирать в начислении договор по нужной организации?
95. Maxsj_Payne 6 15.02.16 10:54 Сейчас в теме
(94) mindcannon, Добрый день! вы не тем путем пытаетесь решить проблему. У вас лицевой счет будет закреплен за одной организацией - Это ваша организация. А вот уже оказываемые услуги: ХВС, ГВС, Э/Э, содержание жилья - это разные договора. Тут используется заключение договора с поставщиком. В Функционале ЖКХ для этого есть целая закладка.
96. SGordon1 17.02.16 17:39 Сейчас в теме
А по льготам еще подскажите, как настроить чтобы делила услуги на общедомовые и индивидуальные и по своему настраивала расчет и лимиты по каждой услуге? В платежном документе делит ...
99. gabdullin555 28.07.17 16:44 Сейчас в теме
(96)
А по льготам еще подскажите, как настроить чтобы делила услуги на общедомовые и индивидуальные и по своему настраивала расчет и лимиты по каждой услуге? В платежном документе делит ...


добрый день.
можете привести более детальный пример для рассмотрения? Желательно на цифрах. Речь идет о том, чтобы льготный объем отдельно определялся по индивидуальным начислениям и отдельно по общедомовым? Если так, то подобный расчет в программе не предусмотрен.
Чем регламентирован описанный расчет?
97. vitonya 79 23.01.17 14:59 Сейчас в теме
Ужасная программа (ред. 3). Вся нелогичная, в багах. Орфографические ошибки. Ну ведь можно было используя опыт написания второй редакции, применить его в третьей. Тех программистов отправить в дворники. Нахрена ее было интегрировать с БП, когда можно было создать свою!?
98. gabdullin555 28.07.17 16:37 Сейчас в теме
(97)
Ужасная программа (ред. 3). Вся нелогичная, в багах. Орфографические ошибки. Ну ведь можно было используя опыт написания второй редакции, применить его в третьей. Тех программистов отправить в дворники. Нахрена ее было интегрировать с БП, когда можно было создать свою!?


Добрый день. Просим подробнее описать, о каких именно ошибках идет речь? Постараемся Вам помочь.
102. vitonya 79 23.10.17 14:29 Сейчас в теме
(98) [IS-QUOTE]ках и[/QUOTE

Программный код такой запутанный, что не обязательно было прятать некоторые общие модули.
Я не понимаю, как такие разработчики существуют!!!
Очень непрофессионально все сделано. Сопли - одним словом.
Оставьте свое сообщение
Вакансии
1С аналитик
Москва
зарплата от 210 000 руб.
Полный день

Руководитель направления 1С
Москва
зарплата от 350 000 руб.
Полный день

1С Программист
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)