gifts2017

Конфигурация для абонентского отдела водоканала (7.70.606)

Опубликовал ООО "Информ Центр" (Информ Центр) в раздел Отраслевые решения - Услуги и сервис

Конфигурация предназначена для автоматизации работы абонентского отдела водоканала ведущего расчеты с физическими лицами по оказываемым услугам водоснабжения (водоотведения). Данная конфигурация построена на компоненте 1С:Расчет 7.7. Компонента в поставку не входит.

При разработке конфигурации преследовалась цель: вести обработку больших объемов информации при минимальных требованиях к ПК и максимальном быстродействии.

В конфигурации учтены особенности расчетов описанные в Постановлении от 23 мая 2006 г. N 307 в редакции Постановления Правительства РФ от 21.07.2008 N 549.

Функциональные возможности конфигурации

  • Ведение начислений по нормам и по счетчикам по 5 методикам ("водоснабжение", "водоотведение", "на скот", "на полив" и "прочие начисления");
  • Ведение разовых начислений (очистка стоков, прокладка водопровода и т.д.);
  • Учет по нескольким счетчикам установленным у одного абонента с возможностью распределения объема оказанных услуг по периодам;
  • Учет по домовым счетчикам с распределением объема оказанных услуг по абонентам;
  • Учет изменений в течение месяца: количества проживающих, норм, тарифов, предоставляемых льгот, методик расчета ("по нормам" и / или "по счетчику"), сроков действия договоров и видов оказываемых услуг;
  • Возможность автоматической смены методики расчета "по счетчику" на методику "по норме" при отсутствии показаний счетчика;
  • Возможность автоматической смены методики расчета "по счетчику" на методику "по норме" при просроченной поверке индивидуального счетчика;
  • Учет оплаты и субсидий в разрезе видов и источников поступления денежных средств;
  • Перерасчет начислений при изменении информации по лицевым счетам, льготам или оказываемым услугам за прошлые периоды расчетов;
  • Формирование различных отчетов с фильтром по абоненту, группе абонентов, контролеру, населенному пункту, улице;
  • Формирование отчета с предварительным расчетом сумм начислений до конца года при расчете по методике "по нормам";
  • Работа с торговым оборудованием: сканером штрих-кода, фискальным регистратором;
  • Работа в режиме распределенной информационной базы данных.

Дополнительные возможности конфигурации

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

 

В конфигурации использованы различные методики оптимизации выполнения. Подробнее о некоторых из них можно посмотреть здесь http://www.infostart.ru/public/18924/

 

Во вложении версия 7.70.519 (текстов нет, обработана КЗК2) - полнофункциональная версия без ограничений.

Скачать файлы

Наименование Файл Версия Размер
7.70.519 (текстов нет, обработана КЗК2) 198
.zip 3,80Mb
02.11.12
198
.zip 3,80Mb Бесплатно
7.70.012 (тексты есть, сокращенная версия) 122
.1230120524 531,76Kb
02.11.12
122
.1230120524 531,76Kb Бесплатно
Документация в формате pdf 96
.1230120812 1,93Mb
02.11.12
96
.1230120812 1,93Mb Бесплатно
Дополнения к документации 13
.1250835028 31,68Kb
02.11.12
13
.1250835028 31,68Kb Бесплатно

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Алексей Константинов (alexk-is) 24.12.08 15:19
В формате этого портала данный материал я бы рассматривал как демонстрацию некоторых возможностей 1С:Предприятия 7.7.
2. LenaTorpeda 24.12.08 16:01
Не поняла шутки.Что смотреть? закачка 7.70.507 закончилась ошибкой,а в 7.70.012
одни шапки. Такое мы богато бачили. Лучше бы сало показали...:)
3. LenaTorpeda 24.12.08 16:03
Не понятно за что плюсы ставят DSshark и support если даже не смотрели.
4. Алексей Константинов (alexk-is) 24.12.08 16:20
(2) (3) По поводу 7.70.012. Документы Перерасчет, Исправление, ОказаниеУслуг и ПоступлениеДенежныхСредствПКО появились только в версии 7.70.201. В демонстрационную сборку на базе версии 7.70.012 они добавлены опционально. Т.е. без модулей проведения. Это же и в отношении других добавленных в эту версию объектов из старших версий.

В версии 7.70.507 все есть и все работает. Нет только некоторых текстов модулей.
5. Алексей Константинов (alexk-is) 24.12.08 16:23
(2) По поводу закачки. Проверил. Все качается. Дистрибутивы устанавливаются. Библиотеки регистрируются.
6. LenaTorpeda 24.12.08 17:14
И вообще вы с работниками водоканалов общались? У нас они работают на старой
досовской версии.И им "ничего не надо,нас и так всё устраивает".Сколько интересно стоит Ваша программа?
8. LenaTorpeda 24.12.08 17:20
Посмотрела - 9500 рублей.Довольно не плохо. И вопрос : Коммерческая версия открыта
или там ничего не изменить?
9. Алексей Константинов (alexk-is) 24.12.08 17:32
(8)
Полностью открыта.
http://www.1c.ru/rus/partners/solutions/solution.jsp?SolutionID=11639

Внедрение Респ Удмуртская, г Глазов, Январь 2004
МУП “Водопроводно-канализационное хозяйство города Глазова” МО “Город Глазов”

АВТОР: 1С:Франчайзи Дельта Ай-Ти, Ижевск
Расчеты с частным сектором
Конфигурация построена на основе оригинальной конфигурации ООО "Информ Сервис" (г.Лысьва), использующей компоненту 1С:Зарплата и Кадры 7.7, и предназначена для ведения расчетов с частным сектором по услугам водоснабжения.
10. LenaTorpeda 24.12.08 18:09
Прежде чем предлагать кому-то ,нужно знать с чем имеешь дело.
Один предприниматель купил конфигурацию за 21 000 рублей.В итоге - это был мыльный пузырь. Было жалко на него смотреть.Эта конфа у меня есть и скажу я вам она вообще ничего не стоит. Можете зайти посмотреть к деятелям ,которые ее двигают.(дурят - другого слова не подобрать).
http://estetik-consulting.ru/openbiz/openbiz6/
11. Алексей Константинов (alexk-is) 24.12.08 19:53
(10) "География пользователей" это холодные продажи. Т.е. пользователи сами на нас выходят. Узнают друг у друга или еще как-то...

Чтобы это был не "мыльный пузырь" - смотри материал. Именно поэтому документация и две конфигурации:
7.70.012 - с текстами чтобы понять общие принципы.
7.70.507 - полнофункциональная версия. Сомневаешься - проверяй. Не понятно - спроси...

Хотя здесь материал был опубликован с несколько иной целью... (см. пост 1)
12. LenaTorpeda 24.12.08 20:44
13. f13 f13 (f13) 25.12.08 09:56
каковы размеры клиентских баз? есть ли проблемы с производительностью?

Именно из-за производительности делал подобные вещи на MySQL и PostgreSQL.
14. Алексей Константинов (alexk-is) 25.12.08 12:02
(13) Встречный вопрос. А какие показатели вы считаете приемлимыми, ну, например, для базы данных на 10000 абонентов?
15. f13 f13 (f13) 25.12.08 14:53
(14) ну .. для 1с это уже немалый размер. У меня например базы 25 000 - 30000 полностью пересчитываются за 1-1.5 мин, в базе всегда актуальные данные (как правило включен авторасчет). Базы никогда не резались - т.е. в системе данные за весь период эксплуатации системы.
По моим скромным ощущениям :) при увеличении числа пользователей в десятки раз база на Postgres покажет почти линейное увеличение времени расчета.

Действительно интересно - есть ли проблемы с производительностью, что пришлось сделать для решения проблемы.
16. Алексей Константинов (alexk-is) 25.12.08 17:35
(15) К сожалению у меня нет таких больших баз. Поэтому тренируюсь на базе в которой 11600 активных абонентов. Размер базы за 4 года ~ 350 Mb.

На моем компьютере в монопольном режиме полный расчет по 11600 абонентам за 1 месяц занимает 28 секунд (10 секунд отмена проведения, 18 секунд проведение). При этом удаляется, а потом формируется 25000 записей в журнал расчетов. Программа использует около 30 Mb оперативной памяти.
17. Алексей Константинов (alexk-is) 25.12.08 17:48
+16 "всегда актуальные данные" - не совсем понятен тезис.

Разумеется при работе по сети и в многопользовательском режиме показатели производительности будут хуже.
18. Алексей Константинов (alexk-is) 25.12.08 18:38
+16 Немного покривил душой. 28 секунд это лучший показатель. т.е. по свежим индексам. Стабильный показатель - 32 секунды.

Со сменой всех тарифов в середине месяца при 60000 записей полный расчет - 51 секунда (21 секунда отмена проведения, 30 секунд проведение).
19. f13 f13 (f13) 02.02.09 11:52
Структура базы / состав данных - продиктованы жизнью.
В своих проектах дела все очень похоже. На 1с скорее всего конфигурация так и выглядела.

Молодцы :)

Еще один вопрос - льготники.
Откуда берется/как вводится в систему информация о льготниках?
Сталкивался с тем, что файлы, формируемые собесом, не всегда актуальны и могут содержать ошибки в ФИО и адресах. Пришлось сделать инструмент для сравнения и сопоставления тек. состояния базы и файла собеса.
20. Алексей Константинов (alexk-is) 02.02.09 12:22
(19) Льготники - ручками. собес ничего не дает - только требует отчетности в "своем" формате. Сделана выгрузка в 2х "своих" форматах...

Есть обработка для загрузки справочников с диска ИТС. Можно воспользоваться ей. После загрузки есть обработка в конфигурации, которая проверяет справочники и дозаполняет, исправляет или выводит предупреждения...
21. f13 f13 (f13) 02.02.09 13:12
Я обратил внимание на обработки.

Мне удалось "автоматизировать" :). Благодаря моим пользователям, в собесе поддерживается относительный порядок - обратная связь работает: нашли ошибку - звонок в собес.

У меня базы города и районов вытягивают на 8 и более тысяч льготников. Раньше "расчет льгот" + "отчет для собеса" требовал: "программиста" + неделю работы.

После внедрения время обработки сократилось до нескольких часов.

Могу поделиться "концептуальными" наработками.


22. Алексей Константинов (alexk-is) 02.02.09 13:34
(21) Всегда за. А какой у вас регион?
23. f13 f13 (f13) 02.02.09 15:03
(22) Программы используются в Ростовской области, но я думаю сути это не меняет. Набор данных собеса (Уник. номер, ФИО, Адрес, количество человек, количество льготников, проценты начислений) - одни и те же.
24. Сергей (seermak) 02.02.09 16:11
(23) не надо! Я работаю плотно с собесами, сибсидиями,монитизациями - данных они требуют гораздо больше и разноообразнее. :)
25. Алексей Константинов (alexk-is) 16.02.09 21:06
В продолжение http://www.infostart.ru/blogs/939/ пост (64, 66, 67)
Мне не хотелось бы сравнивать эти две конфигурации. Мне кажется, что они имеют разную направленность. Но раз Арчибальд привел этот пример http://www.kamin.kaluga.ru/products/rent/, то замечу, что приведенная в качестве примера эталонная конфигурация предусматривает создание регламентных документов по расчету домов. 1 дом - 1 документ. 10000 домов - 10000 документов в месяц. Средний «вес» 1 начисления в эталонной конфигурации около 3500 байт. Средний вес 1 начисления в конфигурации Абонентский отдел водоканала около 350 байт.
Я не могу сказать, что приведенная в качестве примера эталонная конфигурация плохая. Просто она рассчитана на другой сектор рынка, другие бизнес процессы, другие объемы обрабатываемых данных. В данном случае, мне кажется, что это не очень удачный вариант для сравнения.
Что будет, если база 100000 абонентов и у каждого в среднем 3 начисления + оплата. База данных за месяц будет увеличиваться на 1,3 Гб (за год на 15,6 Гб).
…или не так?
26. Александр Рытов (Арчибальд) 18.02.09 12:26
(25)
Задержался с ответом – связь вырубилась.
Итак: я привел пример решения похожей задачи на движке Бухучет. Для водоканала архитектура решения (структура данных, порядок ввода) не очень подходящая, конечно, ибо не учтена многочисленность объектов (аб. точек) и единственность начисления. О трех в среднем начислениях я речь не веду, поскольку расчеты ведутся не по людям, а по точкам отбора. Люди и поменяться могут, а кран остается.
Касательно объема базы. В самом деле, в бухучете объем данных по одному движению больше, чем в журнале расчетов. Но примерно вдвое, а отнюдь не в 10 раз. Зато данные и более информативны (движение + итоги, а не только движение), и извлекаться могут независимо, поскольку не лежат в одной куче (журнале расчетов), а распределены по их природе (по «счетам»).
Что осталось? Оптимизировать обработку справочника аб. точек и заставить начисление за месяц формировать не один документ-монстр, а дюжину операций.
На 10000 аб. точек в месяц будет порядка 30000 проводок (вместе с платежами, льготами и субсидиями). Это порядка 100 Мб в год прибавления к объему БД. И никаких проблем со сверткой базы.
27. Алексей Константинов (alexk-is) 18.02.09 15:28
(26) В 10 раз получилось случайно. Я скачал демку и тупо померил результат до и после проведения документов начисления, и поделил на количество строк начислений. Конечно все зависит от структуры данных абонентской базы. Если льготников много (а на каждого делается по 3 дополнительных проводки по каждому начислению), то размер базы значительно увеличится. Если говорить об "информативности данных", то учет раздельно ведут по водоснабжению, водоотведению, поливу, на скот в разрезе размера скота (крупный, средний, птица) и еще автомобиль (на помыв) и разовые работы. Раздельно по счетчикам и по норме. Раздельно горячую и холодную. Раздельно льготируемые начисления и без льгот. Раздельно по тарифным ставкам. Так что формула 1 абонент - 1 начисление не соответствует реальности. 3 начисления я взял из демонстрационного примера чтобы быстрее клонировать документы и набрать объем эталонной базы. В реальных базах может быть в среднем и более 10 начислений. Я видел базу где только по скоту было 26 начислений у одного абонента и тарифы разные.

А дюжину операций будет формировать обработка? Чем такое решение лучше регламентного документа? Несколько тысяч проводок в одной операции. Насколько удобно будет искать в таком объеме проводки по конкретному абоненту. И что будет с ручными изменениями при повторном регламентном расчете?
28. Александр Рытов (Арчибальд) 19.02.09 07:48
(27)Т.о. мы имеем разные типы абонентскик точек = различные счета начисления (Дебет). Различные варианты льгот, субсидий и платежей = различные счета кредита проводок. Плательщик (абонент) - это атрибут справочника абонентских точек. Возможно, второе субконто в проводках по абонентским точкам.
Начисление (регламентный расчет) проводится однократно. Все изменения - документом "Корректировка", формирующим проводки по требуемым отклонениям.
Вся информация в перечисленных разрезах получается стандартными бух. отчетами типа "анализ субконто" или "ОСВ", поскольку данные автоматически хорошо структурированы.
29. Алексей Константинов (alexk-is) 19.02.09 14:17
(28) "Начисление (регламентный расчет)" - это обработка?

Что делать в случае, если через неделю работы обнаружили, что новые тарифы установили не по всем начислениям?

Как получить отчет в разрезе тарифных ставок?
3.15, 3.62, ...
30. Александр Рытов (Арчибальд) 20.02.09 08:48
(29) Нормативное требование в сфере коммунальных услуг - периодическое (ежемесячное) выставление счетов потребителям. А когда через неделю выяснится, что выставлены неправильные счета - это не повод для повторного выставления оных. Делается коррекция начислений.
Ну, а "отчет в разрезе" как то за пределами нашего обсуждения - мелкая техническая задачка. Тариф, например, может быть атрибутом справочника абонентских точек с возможностью сортировки/отбора.
31. Алексей Константинов (alexk-is) 20.02.09 09:47
(30) Счета выставляются за прошлый месяц, а платежи собираются за прошлые месяца и за текущий. Т.е. расчет выполняется в начале месяца - предварительный и в конце месяца - окончательный. Окончательный это после поступления от почты и банков данных по показаниям счетчиков.

По периодическим реквизитам справочника нельзя сделать отбор или сортировку. Если реквизит будет не периодический, то отчет за прошлый период будет неверный. Нужно добавить субконто?
32. Алексей Константинов (alexk-is) 02.03.09 10:50
(30) Теперь у меня есть версия под компоненту "бухгалтерский учет". Над ней набо еще поработать, но регламентные начисления уже работают. Однако сомневаюсь что найдутся энтузиасты купить данный продукт, но попорядку...

- проводил только регламентные документы по начислениям, т.к. остальные документы еще неготовы, то их не сравнивал
- потерял немного аналитики в проводках и типовыми бухгалтерскими отчетами этого не вернуть - придется разрабатывать что-то специально
- 4 файла для работы с журналом расчетов (ЖР) заменили 20 файлов для работы с бухгаллтерскими итогами (БИ) + 6 справочников для восстановления аналитики
- объем 4 файлов ЖР - 300 Мб, объем 20 файлов БИ - 2 Гб (основной объем 2 файла - проводки и итоги)

Все отборы отключены, содержание проводок и разделение по журналам удалены. Можно поработать над оптимизацией внутренней структуры итогов, а также поработать над быстродействием, но я не уверен, что получится выйти хотябы на паритет с журналом расчетов по объему и по скорости.
33. Александр Рытов (Арчибальд) 03.03.09 02:19
(32)Могу посмотреть и чего-нить посоветовать. Один ум хорошо, а два сапога - пара.
34. Алексей Константинов (alexk-is) 03.03.09 21:02
(33) Однажды я уже пытался это побороть, но в то время техника была слабая, а на большое количество экспериментов небыло времени.

Я использовал план счетов из приведенной в качестве примера конфигурации. Добавил аналитику по тарифам и нормам. Получилось 5 субконто.

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

В данном случае должен быть другой план счетов и соответственно другие коррепонденции. Также необходимо продумать проводки всего документооборота чтобы не накапливались лишние итоги.
35. Александр Рытов (Арчибальд) 04.03.09 23:37
(34)Сваял иллюстрацию к некоторым идеям по минимизации итогов и количества субконто. Куда послать?
36. Алексей Константинов (alexk-is) 21.05.10 08:21
Версия 7.70.521.
Обнаружена ошибка при использовании фильтров в отчете "Справка по источникам поступления денежных средств" в случаях, когда условие накладывается по реквизиту не выбранному в группировке.
Исправлена в 7.70.522
37. Игорь Исхаков (Ish_2) 07.06.10 09:49
Даже смотреть не стал . На 8 - ке когда будет ?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа