evngas.gif (2282 bytes)

Задаваемые вопросы, переписка

Рассчеты с населением за газ

evngas.vallmind.ru

www.vallmind.ru

Применяйте контекстный поиск CTRL+F интересующего вас материала !

Фрагменты переписки по сопровождению c СРГ (1):

1


Всё это делаешь только для DATABASE . Потом нужно будет:
1. В карте данных и приложений найти текущее приложение и изменить у него источник с данными на новый
2. В системном меню выбрать \Система\Доступ к данным и структуры\Выбрать источник с глобальными установками... это - перенос SHARSET
3. В системном меню выбрать \Система\Доступ к данным и структуры\Свойства источника с картой данных - это - перенос DATAMAP

Вообще - лучше создать три базы в SQL: GAS_MAPS, GAS_SETS_GAS_DATA соответственно трём источникам в свойствах приложения.

Попробуй это всё сначало на тестовой базе! Сам понимаешь - процедура очень редкая и давно не делелась.

Проблемы с владельцами попозже начну смотреть.

И не затягивайте там с анализом главного отчёта, а то опять 20-го аврал бухи устроят!


Friday, April 14, 2006, 8:52:16 AM, you wrote:

КМЮ> И еще вопрос.

КМЮ> Пожалуйста поясните на счет перехода на SQL версию.

КМЮ> Ставим SQL серверделаем две базы одну под данные, одну под настройки.Создаем новый источник данных, например DATABASESQLи прописываем для него настройки подключения к SQL серверу.Так же для SHARSET. Открываем структуру данных и для каждой группы таблиц меняем источник данных. Говорим перенести на новый источник и после того как все таблицы будут перенесены, рабочие таблицы будут готовы к работе на SQL.

КМЮ> Поправьте если где не прав.

КМЮ> И вопросы по переходу

КМЮ> 1 Как перенести таблицы настроек. Наверно в пункте Выбратьисточник с глобальными установками

КМЮ> 2 Что надо менять в свойствах источника с картой данных ну и где и что я еще пропустил и на что необходимо обратитьвнимание.


Хранение тарифов в позициях (поле QUANTITY) является единственным путём получения такого отчёта.

О написании VFP функций и создании свободных отчётов читайте в разделе "Средства и методики для сторонних разработчиков, сопровождающих приложения на платформе EvnFox". Разделы есть только в EvnFox.chm, пришедшем с последними билдами. (и на сайте)


Билды на vallmind.ru Кроме того я на сервере установил EvnGas.
Полные дистривы пока не делал.

1. Изменяю начисления:
- на заявленные нулевые показания не должно начисляться по норме;
- на каждый тариф (в случае изменения в месяце) в итоговом уровне расчёта посторится соответствующая позиция суммы, где в выражении будут переменные [ГАЗ_ТАРИФ_N_1_...], [ГАЗ_ТАРИФ_N_2_...] . Это вместо использования среднего значения тарифа. Каждая позиция объёма теперь хранит норму из её выражения, а позиции сумм - тарифы, по которым они посчитаны. _N_1_ , _N_2_ - порядковые номера тарифов в месяце. По сему нужно проверить правильное начисление тарифов и в месяцах с изменением тарифов и без - нужно проверить максимум контрольных примеров как при первом начислении

2. Все изменения отчётных форм (квитанций и других) проводить только на этих билдах, а не на старых !!! !!! !!!

3. Не компенсировалось начисление по норме при подаче показания - только при начислении отдельного счёта. Исправил, нужно проверить. И в пакете тоже.

4. Ярлыки на столе на DBF-ах должны теперь сохраняться

5. Доначисления за предыдущие месяцы. Если в предыдущих месяцах не было вообще начислений и клиенту нужно начислить задним числом, то теперь не в пакете, а в отдельном документе коррекции при перерасчёте предложит начислить по типовым операциям. Согласиться - это и есть доначислить

6. Включена дополнительная проверка наличия документов при попытке удалить лицевой счёт.

7. Добавляю в свойства участка газификации поле "Юр.лицо" со ссылкой на справочник владельцев. В списке типов объектов газификации добавляю: "Управляющая компания", "Агент", "Собственник жилья", "Управляющие компании", "Агенты", "Собственники жилья". Первые три типа - для юрлиц, по которым будет вестись учёт по абонентам. Для каждого такого юрлица нужно завести участок с названием как у юрлица, создать владельца с полным названием и всеми нужными реквизитами и сделать ссылку на этого владельца из свойств участка. Для трёх вторых типов нужно создать участки эквивалентные группе юрлиц по территориальному признаку, например: "Югорск - агенты", "Югорск - собственники жилья", ... Далее для каждой такой группы создаются перечни владельцев - управляющих компаний, входящих в неё, и для каждого владельца заводится перечень лицевых счетов согласно направлений потребления и наличия приборов учёта, как указано в комментариях к ТЗ.

8. Отчёт по банку - итоги можно по агентам суммировать. Бухгалтерии это должно понравиться


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


Monday, March 27, 2006, 4:44:17 PM, you wrote:

РСАХМ> Здравствуйте!

РСАХМ> Это Миша.

РСАХМ> Возник вопрос.

РСАХМ> Установили терминал контролера. После того как заводишь права доступа, поле наименование во владельце становится не доступным.


По нулевым показаниям понял.
По показаниям - файл положи на ftp. Когда я их импортирую в центральную базу - нужно для каждого из участков с этими показаниями создать и отправить
пакет. Пункт меню \Данные\Прочий обмен\Передать показания счётчиков на участок. На участке сделать как и при синхронизации - Пункт меню \Система\Средства разработчика\Выполнить команду FoxPro набрать Do Gas_terminal_Crucial, кнопка "Выполнить" и вабрать "Принять показания.
Миша знает эту процедуру

САО> Здравствуйте, Андрей Васильевич!

САО> Вопрос по отчету пока остается открытым. У наших разные мнения. Думаю, с этим можно пока еще повременить (хотя бы до понедельника). Вопрос действительно важный.

САО> У нас еще есть пара моментов. 1) Миша уже писал в заявке про начисление по норме при нулевой разнице показаний счетчиков за период. На самом деле такого не должно быть. Абонент может и уехать, т.е. газом не пользоваться, а мы ему по норме. Не правильно.

САО> Поэтому, мы посовещались (Абон. Служба), и сошлись на том, что в данном случае алгоритм должен анализировать однозначно наличие показаний приборов учета (не смотря на то, что они нулевые). Начисления по норме в таком случае не должно быть. Только по показаниям счетчиков, будь то положительные, нулевые или отрицательные.

САО> Надеюсь, мы друг друга поняли.

САО> 2) Возникла небольшая проблема. Думаю, решить ее можете только вы.

САО> Миша в Югорске установил АРМ контролера. Теперь информацию по абонентам можно вводить только там (при обмене данными ей отдается приоритет).

САО> НО: Наши работники уже заколотили показания счетчиков более, чем по 3 тыс. абонентам в файл с лицевыми счетами. Если их сейчас заново вносить в базу, то уйдет очень много времени (они просто могут не успеть до конца месяца). ВОЗМОЖНО ЛИ каким-либо образом залить файл с показаниями по лицевым счетам, чтобы приоритет стоял как у участка (т.е. АРМ контролера)?

САО> Файлы эти уже готовы, и если вы скажите, что можно, то мы готовы их выложить на ftp на заливку.


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

Кроме округлений в БРГ возник вопрос почему перемножение человек на нормы не дают объём. Мы объяснили, что и не могут дать, так как количество человек (а также и оборудование и площади) могут поменяться посреди месяца. Я готовил им отчёты путём суммирования позиций объёмов из документов и выборки количества человек на конец месяца (а также площадей, оборудования). Естественно - никакого баланса в строках не получалось. Чем это кончилось - не знаю. Завтра так же поинтересуюсь. Два варианта: или они сами поменяли отчёты (маловероятно) или смогли убедить аудиторов (вероятно), что умножением человеков, площадей и оборудование на нормы - объёмы нельзя получить. Так же обстояло дело и с умножением объёмов на тарифы. Третий путь - среднее дробное количество человек в месяце (площадей, оборудования). Но от этого отказались сразу

Так что есть над чем подумать


Thursday, March 23, 2006, 3:15:28 PM, you wrote:

САО> Здравствуйте, Андрей Васильевич!

САО> Предлагаю поговорить по поводу формирования отчетов. С комментариями:

САО> Ну главный - точность привязки к тарифам. Последний отчёт настроен такимобразом:

САО> - берём суммы по начислениям;

САО> - для текущего месяца вытаскиваем из справочников тарифы и нормы;

САО> - получаем объёмы , площади, человеки путём деления сумм на тарифы инормы

САО> Данный подход является единственным исключающим погрешности в строках.

САО>  

САО> Но! Как минимум это не правильно для коррекций, так как коррекции пересчитываются то тарифам прошлых месяцев.

САО> Я пока дорабатываю расчёт, чтобы с каждой суммой в документе хранился тариф. Но абсолютно жёсткой привязки суммы к тарифу добиться может и неудастся. Я сейчас трачу на это много сил.

САО> До начала создания отчёта из ТЗ нужно решить - делать ли его подействующей технологии усреднения показателей и исключения погрешностей, илидожимать до строгой привязки к тарифу каждой суммы?

САО> Отчет из ТЗ будет требовать строгой привязки суммы к каждому тарифу иобъему. Иначе нас тут всех абонентщиков поубивают.

САО> У меня есть некоторые домыслы по сложившимся проблемам.

САО> Во-первых, я посмотрел, в чем может быть проблема с округлениям.

САО> Дробные нормативы, такие как 7,3; 6,04; 24,67; 32,5.Дробные тарифы (все), такие как 1,46; 0,99657; 1,05946 и т.д.Дробные площади (при расчете на отопление).

САО> Перемножение этих дробных чисел для расчета стоимости дает длинные хвосты. Но мы их округляем при начислении (на стадии формирования счета абоненту). Хвосты, соответственно съедаем.

САО> При формировании отчета складываем суммы счетов по абонентам поучасткам (и даже при делении на тариф у нас объем уже не пойдет, т.к. округлениебыло уже на стадии расчета по абоненту).

САО> Проблема. Сумма поучастку должна соответствовать сумме счетов абонентов на участке.

САО> Аудиторы же будут смотреть (кол-во абонентов на участке х норма хтариф), а не то, что у нас в счетах по абонентам.

САО> В результате окажется, что мы выставили больше, либо меньше, чемполучится на основании объема расчетным методом (кол-во человек х норма хтариф).

САО> Как Брянск сводит?

САО> Я обсужу с финнами и бухгалтерами.


1. Сортировка по квартирам в адресе (если не проверяли)
2. Формирование книг и печать квитанций (если не проверяли)
3. С датаграммами не передавалась дата ограничения на изменение документов - проверитью
4. При отсутствии предыдущих показаний и вводе платёжных документов заносились нулевые показания.
5. При вводе показаний в любом месте проверка на наличие начальных показаний. При отсутствии начальных показаний в платёжных документах не даст вводить текущее, а в остальных местах - предложит ввести начальное. Фактически проверяется ситуация наличия вообще каких-либо показаний перед вводом текущего и если их нет - требует ввести показание на дату "с" счётчика. Всё нужно проверить.
6. При формировании адресов по умолчанию (для нового пользователя) должно быть "Объекта"
7. При экспорте в Excel должна открываться книга
8. Формирование счёта за газ из данных о расчётах
9. Формирование справки в суд
10. Редактирование показаний счётчиков (меню Документы) не работало. Можно было только добавлять.
11. Редактирование отключений (меню Документы) не работало. Можно было только добавлять.
12. Оплата в центре из списка не сохранялись пачка и агент


- выход при отказе от пароля должен быть быстрый;
- проверить инициализацию EGasTerm. Запрос ключей - приём справочников;
- пакет для синхронизации нужно создавать на последнем EvnGas и принимать на последнем EGasTerm. Проверить инициализацию и синхронизацию EGasTerm для участков снуля;
- квартиры в адресе в квитанциях - выравнивание для сортировки - проверить;
- "оплата в центре" теперь есть в EGasTerm;
- "оплата в центре" и "коррекция в центре" - запрет на сохранение и удаление в EGasTerm;
- экспорт из таблиц на экране. Добавлены кнопки "отметить все поля" и "убрать отметку со всех". Для полей дат можно указывать МИН или МАКС. Пример выборки последних показаний: Выбрать из базы "Показания счётчиков", и из таблицы "Показания счётчиков"; добавить таблицу "объекты газификации"; создать условие для "объекты газификации" и включить флажёк "Показать"; выбрать данные; мышку на заголовок столбца и кнопка "экспорт"; убрать отметку со всех столбцов; отметить дату показания, показание, номер лицевого счёта; текущий владелец, улица, ...; переместить лицевой счёт и владельца вверх; поставить функцию МАКС для даты показания; включить флажки "группировать" и "сотрировать" для номера лицевого; экспортировать в excel - получаем отчёт о последних показаниях счётчиков.
- при заполнении полей КЛАДР в лицевом счёте фильтры на город и населённый пункт теперь устанавливаются и на поиск соответствий при наборе наименования улицы. Проверить !


В меню Данные появился пункт "Пересчитать старые месяца в центре". Нужно бы исследовать на тестовой базе. Потом - пересчитать весь Горноправдинск. Должны сохраниться только документы у которых есть различия в позициях со старым документом. Считается медленно, но всё-же быстрее чем вручную


6. Теперь не должны начисляться счета на объекты, которые полностью отключены за целый месяц начислений. Нужно проверить! Для мёртвых душ обязательно укажите отключение по 2999

7. Есть некоторые изменения в диалоге пакетного начисления. Не включайте флажёк "Сохранить для абонентов без изменений в лицевых счетах ..." если не уверены, что начисленное за текущий месяц в результате предыдущих попыток - все правильное. Обычно в БРГ до конца месяца начисляют льготникам, а потом переначисляют всем. Для ускорения процесса сделана возможность не переначислять тем, у кого эти начисления не изменятся, то есть со времени предыдущего начисления за данный месяц не было изменений в ЛС, показаниях, отключениях, тарифах, нормах, коэффициентах.

8. Документ коррекции и коррекции в центре теперь содержат пункт меню "Документ\Пересчитать прошлый месяц". Суть в следующем: Выбираем месяц, начисления которого нужно пересчитать, лицевой счёт. Если в данных лицевого счёта просто поменяли значения и не трогали даты "с", то оставить "Использовать данные прошлого месяца", а если добавляли изменения новыми записями с датой "С" февраля - переключиться на "Использование данных текущего месяца". Имеются ввиду данные из лицевого счёта!!! Программа начислит по новым данным и добавит все позиции из документа прошлого месяца с cуммами, умноженными на -1. Эти суммы добавятся как последние уровни расчёта. Таким образом пробуйте корректировать и счета с изменениями и мёртвые души.

9. Все корректировки делайте документами коррекции в центре. Если делали просто коррекцией - поменяйте в doc_head DC_CODE с 404 на 406


Да в том-то и дело, что в расчёте мне легче поделить всё на два периода чем вычислять средний тариф. Как в квитанциях и отчётах это показывать без среднего тарифа? В этом основная проблема!

Monday, March 6, 2006, 2:32:38 PM, you wrote:

ЗИЮ> Андрей Васильевич. Ну, в квитанциях вроде у физиков можно оставить расчет по тарифу среднему. Я их убедила. Юр лица очевидно в этом месяце в программе не появятся, и соответственно и вручную будут формироваться СФ.

    ЗИЮ> То, что смена тарифа в середине месяца - это мы выяснили в пятницу.
    ЗИЮ> Нужно решить как будем считать? Вводим понятие среднего тарифа за
    ЗИЮ> месяц? В расчёт я добавляю синтаксис. В квитанциях придётся его
    ЗИЮ> печатать и в отчётах. Думаю нет смысла городить более сложный учёт с
    ЗИЮ> учётом за какой месяц показания давались.


Friday, March 3, 2006, 3:26:22 PM, you wrote:

КМЮ> Каким образом лучше производить корректировки, с помощью документа корректировки или с помощью документа счет за газ (если с помощьюсчета за газ это вообще возможно)?

Корректировки - только с помощью документа коррекций!

КМЮ> Как пользоваться документом корректировка? Как я понял вручную вбивать в позиции документа суммы и объем. Можно ли заносить отрицательныезначения?

Я удалил добавление в документ коррекций промежуточных уровней расчёта. Фактически нужно вручную заносить значения в позиции итогового уровня. Значения - абсолютно любые. Есть нюанс. Схема итогового уровня наследуется из счёта за газ. Вероятно мы ещё что-то там будем менять в связи с переходом на новые тарифы в середине месяца. Потому автоматически может поменяться и схема итогового уровня в доументе коррекции. Если просто изменятся выражения ГАЗ_ТАРИФ на ГАЗ_СРЕДН_ТАРИВ (в очередном билде синтаксис будет) - то не страшно. А если добавятся новые позиции - в ситуациях итоговоро расчёта документа коррекции нужно будет для них очистить выражения. Как это всё выглядит можете смотреть в НСИ\Ситуации создания документов , но править пока
сам буду


КМЮ> Сейчас мы исправим данные по абонентам и в этом месяце они посчитаются правильно, а предыдущий надо пересчитать. В каком порядке выполнять действия,сначала сформировать счета за газ, потом вводить корректировки или наоборот илине имеет значения?

Если не хотите, чтобы поплыли отчёты - старый месяц нужно закрыть для редактирования, а не то что-пересчитать. Все корректировки документом коррекции в текущем(незакрытом) месяце

КМЮ> Наиболее остро стоит вопрос в абонентами, которых надо удалить. На лицевой счет произвели начисление в январе, а в феврале оказалось,что по этому адресу вообще, например, дом сгорел. Как скорректировать сумму иобъем, и сделать так что бы он в дальнейшем не считался?

Нужно всем поставить отключение по 2999 с причиной типа "ликвидация объекта" и типом "обрезка". В новом билде на объекты полностью отключённые в месяце расчёта счета не будут генериться


Если хочешь попробовать сам:

Посмотри на http://evngas.vallmind.ru ссылку "Работа с приложением как с COM объектом" Таблица gas_meters_indications - проста (показания). Нужно найти по лицевому счёту (поле CODE в gas_objects с выравниванием по правому краю) абонента. В gas_obj_meters по IDENT найти счётчик. В OBJECT показаний занести его IDENT, в METER - ITEM_IDENT из gas_obj_meters, INDICATION - показание, DATE - дата, ITEM_IDENT - E_IndexKey10(), SQL_RECORD - E_IndexKey20()
Заноси в MODIFIED какую-либо одну редкую дату, чтобы по ней можно было легко удалить неудачный эксперимент. Остальные поля не нужно заполнять. Ну в USER укажи свой логин

gas_meters_indications:
OBJECT
aevsikow (16:20) :
gas_meters_indications:
OBJECT - gas_objects.IDENT
METER - gas_obj_meters.ITEM_IDENT where gas_objects.IDENT=gas_obj_meters.IDENT
INDICATION - показания
DATE - дата
ITEM_IDENT - E_IndexKey10()
SQL_RECORD - E_IndexKey20()
MODIFIED - дата-ключ для удаления
USER - свой логин

aevsikow (16:23) :
Если счётчиков несколько - первый обычно - общий, второё - пром(отдельный для бань, теплиц, ... наверное и нет такого
практически), или отдельный на ППГВ. Нужно анализировать gas_obj_meters.METER = gas_meters_types.IDENT
aevsikow (16:24) :
Короче - пробуй. Не получится или не успевать будешь первый раз - я сделаю
 


6. Квитанции настроил только цифры. Нужно поформировать и посмотреть правильность цифр во всех вариантах на всех участках.

7. Для настройки надписей взависимости от участка нужно создать в отчётной форме все их варианты как отдельные поля. Пусть они налагаются друг на друга. В свойстве Print when каждой такой надписи нужно указать условие типа Val(_site.CODE)=1 , где 1 - код участка (для Югорска) и т.д. или если для нескольких участков - один вариант надписи, то: Val(_site.CODE)=1 or Val(_site.CODE)=2 or ...

8. Если не совладаете с предыдущим пунктом - составьте мне перечень надписей и соответствия их участкам. Или уже присылали?

9. Можно ссылаться на адрес и телефон абонентской службы участка как это делалось в исходной форме (_site.NAME, _site.ADDRESS, _site.PHONES,
...). Для просмотра исходной формы создайте ещё одну копию, посмотрите и удалите (кнобки в окне "Формы отчётов"). Впринципе можно в адрес запихать и реквизиты. Короче составьте мне варианты надписей для разных участков и я посмотрю как оптимальнее их сделать.

10. БИК там не добавлен был - добавьте в таблицу своих РС в \НСИ\Свои реквизиты


Tuesday, February 21, 2006, 12:24:45 PM, you wrote:

КМЮ> 1. Зачем в документе оплаты стоятпоказания счетчиков? Нужно ли их заполнять, и вообще на что они влияют?

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

КМЮ> 2. Внесение платежей списком делается только по одному лицевому счету?

Нет, сразу пачка квитанций. Но не желательно долее 50 в пачке делать
 

КМЮ> 3. Зачем нужен документ «Оплата за газ в центре» и почему нет разделения на наличную, безналичную оплату?

Для разных ситуаций, когда данные по оплате поступили не в абонслужбу района, а в центр. Конкретно уже не помню. Нужно у БРГ спросить. Это - чтобы не перемешались и не потерялись документы при двустороннем обмене. Так как оплата в одном месте, то нет необходимости раэделять на разные типы документов. Вид оплаты просто указывается разный
 

КМЮ> Сейчас наш бухгалтер хочет заносить оплату, пришедшую сразных участков. Ему следует воспользоваться именно этим документом?

Если ваш бухгалтер, то да. Но настроить могу - завтра только.
 

КМЮ> 4. Про дату операции. В инструкции что то написано про ограничение на редактирование. Как я понял в глобальных установках -> прочее устанавливаем дату, и если документ введен с датой операциименьше чем указанная в настройках, то на участках его редактировать не смогут. Я правильно понял? И если да, то распространяется ли это надругие документы?

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

КМЮ> 5. Какой лучше указывать номер документа. Написано, что лучше как номер квитанции, но если за несколько месяцев разом, то так не получится. Какое-нибудь принципиальное значение онимеет?

Нет - кто как. Как кому удобнее. Это только для удобства поиска и сверки
 

КМЮ> И по печати квитанции. Когда распечатываем сформированнуюкнигу, в каком порядке сортируются квитанции? Понятно, что улицы идут по порядку, а вот дома 1, 11, 12, 13 …. 2, 21,22,23… 3, 31 и т.д. мне кажется это не очень удобно или это можно настроить?

Сортировка по индексу и адресу. Потом всё бьётся по сотням с чередованием для резки пополам. Есть средства для учёта доставочных участков. Если почта даст информацию по отнечению домов и улиц к их доставочным участкам, то мы можем это учесть.

В настоящее время есть много вариантов сортировки квитанций


Необходимо выполнить следующие мероприятия:

1. Не знаю почему, но не работает шрифт BarCode на сервере. Может переустановить? Шрифт - в IN . Надеюсь на других компьютерах он
работает.

2. Источник REPORTS должен быть типа DBF_TABLES. Я перенёс его из источников типа MS_SQL в DBF_TABLES. Но. Пока там указана директория
'C:\REPORTS' , т.е. локальный для сервера путь. Необходимо директорию REPORTS на сервере сделать разделяемым ресурсом с полным доступом всем
и в свойствах транспорта источника REPORTS указать глобальное имя директории типа \\h086-srv-04\C\REPORTS Карта данных и приложений вызывается \Система\Доступ к данным и структуры\Карта данных и приложений . Описание в EvnFox.chm или http://evnfox.vallmind.ru/Data_Map.htm

3. Работа с квитанциями только на последнем билде ( http://vallmind.ru  скачать )

4. Рекомендаций по информации на квитанциях недостаточно. С другой стороны я не могу просто адаптировать БРГ-шные квитанции к СРГ-шным.
Слишком разные алгоритмы начислений. Необходимо разработать внешний вид квитанций для четырёх вариантов:

- только по норме;
- только по счётчикам;
- со счётчиком и без показаний (нулевая)
- комбинированная: и нормы и показания

За основу можно взять внешний вид БРГ-шных. Самые первые образцы они присылали в виде как я прикрепил к этому письму


Вижу следующие варианты:

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

2. Оформляем управляющие компании как отдельные участки. Это позволит все расчёты вести на индивидуальном субсчёте для каждой компании. К
оплате управляющей компании представляется оплата (за вычетом их доли) вцелом по субсчёту, а для их работы с абонентами можно им по запросу выдавать сальдово-оборотку в разрезе клиентов. Вся остальная работа с абонентами ведётся как со всеми остальными включая средства для работы с должниками.
Квитанции печатаете и разсылаете вы. Только реквизиты платежа - их. За чей счёт - решаете

3. Берём за основу второй вариант. Но! Если управляющая компания приобретает терминал "АРМ контролёра участка", то можно легко функции начисления, коррекции, сбора оплаты, работы с лицевыми счетами ... передать им. Из центра к ним (от вас) будут поступать только главные справочники (алгоритмы расчёта, схема проводок, ...) Всю работу с клиентом включая судебные разбирательства, начислнение, оборотки, ... - их дело. Периодически абсолютно всё состояние дел они сливают в центральную базу как и другие участки, которым вы в центре начисляете и печатаете. Сумма к оплате им (компаниям) представляется как во втором варианте. Мы управляющим компаниям только свои реквизиты (банковские и др) позволяем сменить, а алгоритмы все - под вашим контролем. Квитанции печатают и разсылают они.

В любом случае для 2 и 3 вариантов нужно оформить управляющую компанию как отдельный участок (абонентскую службу), хотя физически они могут быть в ведении другого участка. С этим не будет возражений?


Это как настроим. Нужны подробнее данные. С какого срока задолженность? Или с момента образования? Ставка - в день? Дни только рабочие или все?
Всё можно сделать.

Thursday, December 29, 2005, 4:04:54 PM, you wrote:

ЗИЮ> Начисляется ли пеня за просроченную задолженность в ЗИЮ> размере1/300 ставки рефинансирования и включается ли эта пеня в ЗИЮ> квитанцию?


Необходимо выполнить следующие пункты:

1. Скачать обновление билда 417. Ссылки на странице http://www.vallmind.ru/Download.htm . Все файлы из архива обновления нужно поместить в исполняемую директорию C:\EvnGas (заменить существующие).
2. Инструкция по адресу http://evngas.vallmind.ru/Gas_Start.htm имеет продолжение. Все новые пункты нужно постараться выполнить. Если льготы для вас не нужны, то пропускаете всё, что с ними связано.

Я пишу импорт лицевых счетов и нужны составленные справочники, перечисленные в инструкции, для указания ссылок на идентификаторы реальных строк в них.


Брянскрегионгаз взял на себя долги межрайгаза. При приёме оплаты сумма шла одной цифрой и абоненту голову не морочили. А при разнесении
оплаты на долги (делается динамически при печати квитанций или отчётов) ставили приоритет - закрывать сначала свои начисления, а что останется - на погашение долгов. Правда была большая путаница с приоритетами на коррекции. Что чем нельзя закрывать, а что с приоритетом - сложную схему с Панфиловым настраивали (есть средства в програме). Это был переходный период, и самые большие проблемы - общение с межрайгазом. Они ещё год после начала работы слали сотнями свои корректировки сальдо. Короче, когда этот договор с межрайгазом кончился - все вздохнули с большим облегчением. Но начальство было
довольно, что им удалось избежать конфликтов с населением, кто переплатил МРГ, как было в См...
Monday, December 26, 2005, 11:34:55 AM, you wrote:

ЗИЮ> Ну, типа, так хочет сделать руководство. А как это будет в реальности.


В любом случае мы должны стараться работать как можно с опережением графика. Но, блин, я вижу - будет как с Брянскрегионгазом. Там тянули
с договорами с января по июнь, а потом сказали, что в июле уже нужно напечатать квитанции. Два различия - тогда ещё и программы не было и здесь более 400 000 абонентов. Но в июле мы квитанции напечатали.

Что могу сказать? Будем стараться. Буду просить Панфилова заняться заранее стыковкой адресной информации с КЛАДР. Но даже если не успеем - первые квитанции можно печатать с адресной информацией в текущем виде, а преобразование в КЛАДР нужно для связи с ГРС, ГРО и группировки отчётов.


Friday, December 23, 2005, 1:48:06 PM, you wrote:

ЗИЮ> Андрей, здравствуйте. Нужно перепланировать таким
ЗИЮ> образомплан работ, чтобы первое начисление и печать по Хантам,
ЗИЮ> Югорску , Советсвому иБелоярскому АУ љљможно было провести до 28
ЗИЮ> февраля. Иначе мы теряем деньги. Чтоможете сказать по э тому
ЗИЮ> поводу?


В договорах не увидел ничего противного вроде. Единственное, что не так - я должен представдять счета-фактуры. Я их могу представить, но
НДС-то у меня нет. И в стоимостях нужно указать "НДС не облагается"


Мы используем клавиатурные. С портовыми дело иметь не приходилось, но, думаю, не должно быть принципиальных проблем. На сколько я понимаю -
они также считывают код в клавиатурный буфер

Tuesday, December 20, 2005, 10:18:57 AM, you wrote:

ЗИЮ> Скажите, сканер может быть любой, как должен быть подключен к
ЗИЮ> компьютеру, принципиален ли порт?


Начало инструкции по вводу в эксплуатацию я поместил на http://evngas.vallmind.ru/Gas_Start.htm  . Пока там только пункты где взять дистрибутивы и как их установить. Настройку предметной области буду описывать по ходу дела. Пока можете пробовать устанавливать и настраивать программу


"Терминал" - это только урезанный вариант програмы центрального офиса. Убраны администраторские функции, а на оставшиеся разданы полномочия. Ничего
общего с терминалом NT. Любая из программ может работать как с данными в DBF, так и в SQL. Если есть канал в 1 мб/с с участком или локальная сеть, то однозначно программа абонентской службы (терминал контролёра) работает непосредственно с центральной базой в SQL. Если нет - то работает с DBF в своей локальной сети, в которых имеется информация только по абонентам своего участка. Обмен с центральной базой организационно происходит раз в месяц, а практически может быть хоть пять раз в день.

Сегодня-завтра напишу инструкции по установке и положу дистрибутивы на сервер.

Thursday, December 15, 2005, 12:56:34 PM, you wrote:

ЗИЮ> Скажите љпожалуйста, Андрей , понятие љ«терминалконтролера
ЗИЮ> участка» - это может быть и вправду терминальное соединение и
ЗИЮ> «кусок»базы, обмениваемый там раз в месяц – что-то вроде
ЗИЮ> распреде6ленки ?


См. в интернет:    Долина разума    Система учета "Events"     Рассчеты с населением за газ    Предприниматель     Инструментальные средства "EvnFox"    www.vallmind.ru    EasySQL4Fox    ECalcPad    VMZipper    Святая трезвость    Трезвая Россия