Конфигурация для абонентского отдела водоканала (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)
.zip 3,80Mb
02.11.12
206
.zip 3,80Mb 206 Скачать бесплатно
7.70.012 (тексты есть, сокращенная версия)
.1230120524 531,76Kb
02.11.12
128
.1230120524 531,76Kb 128 Скачать бесплатно
Документация в формате pdf
.1230120812 1,93Mb
02.11.12
98
.1230120812 1,93Mb 98 Скачать бесплатно
Дополнения к документации
.1250835028 31,68Kb
02.11.12
14
.1250835028 31,68Kb 14 Скачать бесплатно

См. также

Комментарии
1. Алексей Константинов (alexk-is) 6096 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) 6096 24.12.08 16:20 Сейчас в теме
(2) (3) По поводу 7.70.012. Документы Перерасчет, Исправление, ОказаниеУслуг и ПоступлениеДенежныхСредствПКО появились только в версии 7.70.201. В демонстрационную сборку на базе версии 7.70.012 они добавлены опционально. Т.е. без модулей проведения. Это же и в отношении других добавленных в эту версию объектов из старших версий.

В версии 7.70.507 все есть и все работает. Нет только некоторых текстов модулей.
5. Алексей Константинов (alexk-is) 6096 24.12.08 16:23 Сейчас в теме
(2) По поводу закачки. Проверил. Все качается. Дистрибутивы устанавливаются. Библиотеки регистрируются.
6. LenaTorpeda 24.12.08 17:14 Сейчас в теме
И вообще вы с работниками водоканалов общались? У нас они работают на старой
досовской версии.И им "ничего не надо,нас и так всё устраивает".Сколько интересно стоит Ваша программа?
8. LenaTorpeda 24.12.08 17:20 Сейчас в теме
Посмотрела - 9500 рублей.Довольно не плохо. И вопрос : Коммерческая версия открыта
или там ничего не изменить?
9. Алексей Константинов (alexk-is) 6096 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) 6096 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) 6096 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) 6096 25.12.08 17:35 Сейчас в теме
(15) К сожалению у меня нет таких больших баз. Поэтому тренируюсь на базе в которой 11600 активных абонентов. Размер базы за 4 года ~ 350 Mb.

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

Разумеется при работе по сети и в многопользовательском режиме показатели производительности будут хуже.
18. Алексей Константинов (alexk-is) 6096 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) 6096 02.02.09 12:22 Сейчас в теме
(19) Льготники - ручками. собес ничего не дает - только требует отчетности в "своем" формате. Сделана выгрузка в 2х "своих" форматах...

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

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

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

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

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


22. Алексей Константинов (alexk-is) 6096 02.02.09 13:34 Сейчас в теме
(21) Всегда за. А какой у вас регион?
23. f13 f13 (f13) 02.02.09 15:03 Сейчас в теме
(22) Программы используются в Ростовской области, но я думаю сути это не меняет. Набор данных собеса (Уник. номер, ФИО, Адрес, количество человек, количество льготников, проценты начислений) - одни и те же.
24. Сергей (seermak) 656 02.02.09 16:11 Сейчас в теме
(23) не надо! Я работаю плотно с собесами, сибсидиями,монитизациями - данных они требуют гораздо больше и разноообразнее. :)
25. Алексей Константинов (alexk-is) 6096 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. Александр Рытов (Арчибальд) 2652 18.02.09 12:26 Сейчас в теме
(25)
Задержался с ответом – связь вырубилась.
Итак: я привел пример решения похожей задачи на движке Бухучет. Для водоканала архитектура решения (структура данных, порядок ввода) не очень подходящая, конечно, ибо не учтена многочисленность объектов (аб. точек) и единственность начисления. О трех в среднем начислениях я речь не веду, поскольку расчеты ведутся не по людям, а по точкам отбора. Люди и поменяться могут, а кран остается.
Касательно объема базы. В самом деле, в бухучете объем данных по одному движению больше, чем в журнале расчетов. Но примерно вдвое, а отнюдь не в 10 раз. Зато данные и более информативны (движение + итоги, а не только движение), и извлекаться могут независимо, поскольку не лежат в одной куче (журнале расчетов), а распределены по их природе (по «счетам»).
Что осталось? Оптимизировать обработку справочника аб. точек и заставить начисление за месяц формировать не один документ-монстр, а дюжину операций.
На 10000 аб. точек в месяц будет порядка 30000 проводок (вместе с платежами, льготами и субсидиями). Это порядка 100 Мб в год прибавления к объему БД. И никаких проблем со сверткой базы.
27. Алексей Константинов (alexk-is) 6096 18.02.09 15:28 Сейчас в теме
(26) В 10 раз получилось случайно. Я скачал демку и тупо померил результат до и после проведения документов начисления, и поделил на количество строк начислений. Конечно все зависит от структуры данных абонентской базы. Если льготников много (а на каждого делается по 3 дополнительных проводки по каждому начислению), то размер базы значительно увеличится. Если говорить об "информативности данных", то учет раздельно ведут по водоснабжению, водоотведению, поливу, на скот в разрезе размера скота (крупный, средний, птица) и еще автомобиль (на помыв) и разовые работы. Раздельно по счетчикам и по норме. Раздельно горячую и холодную. Раздельно льготируемые начисления и без льгот. Раздельно по тарифным ставкам. Так что формула 1 абонент - 1 начисление не соответствует реальности. 3 начисления я взял из демонстрационного примера чтобы быстрее клонировать документы и набрать объем эталонной базы. В реальных базах может быть в среднем и более 10 начислений. Я видел базу где только по скоту было 26 начислений у одного абонента и тарифы разные.

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

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

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

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

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

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

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

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

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