evngas.gif (2282 bytes)

Регламент выполнения мероприятий

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

evngas.vallmind.ru

www.vallmind.ru

    Существуют требования к регламенту ежемесячных мероприятий, обусловленные:

    Очень важно понимать, что работа участка не является замкнутым процессом с обособленными данными, а ведётся в постоянном взаимодействии с ЦО с двусторонним обменом данными. Игнорирование данного факта неминуемо приводит к ряду существенных проблем, резко усложняющим жизнь персоналу и населению. Так, например, если не обеспечить передачу с участка сделанных изменений расчётных данных в лицевых счетах или принятых показаний в ЦО до начисления всему региону, то, как минимум, населению будут отправлены квитанции с неправильным расчётом, а максимум - данные в ЦБ не будут внесены до сдачи отчётности за текущий месяц (закрытие месяца) и их исправление потребует много усилий. Хотя в последних версиях программы развиваются средства для контроля и выявления фактов нарушения регламента, но предусмотреть абсолютно все ситуации заранее и заложить их в программу невозможно. Потому ответственность за соблюдение регламента будет оставаться на персонале и дальше.

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

    Регламент может быть различен для разных регионов и даже для отдельных участков, но при традиционном начислении всему региону в ЦО базовый регламент подразумевает:

I. Текущая работа в отчётном месяце и даты в датаграммах.

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

    В любом случае делать дату "по" датаграммы отличной от текущей есть смысл только в ситуациях, когда датаграмма была сформирована ранее, но где-то потерялась и не принята в центре, или обнаружились системные ошибки в архиве датаграммы.

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

    Для печати отдельной квитанции отдельному абоненту из оперативных данных если контролёр не желает или не имеет возможности вникать в детали состояния счёта, то в любом случае рекомендуется выполнить пункт "Пересчитать три последних месяца" меню, вызываемого кнопкой с подсказкой "Выполнить пересчёты/корректировки" в окне оперативных данных. Если же контролёр хочет выполнить конкретное отдельное действие, например, только начислить текущий месяц, то на этой кнопке нужно щёлкнуть правой кнопкой и далее выбрать вариант. При работе в режиме "АРМ кассира" программа сама будет только начислять текущий месяц, а уже дополнительные перерасчёты нужно абоненту делать принудительно.

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

    Отправка данных из ЦО на участки рекомендуется делать:

II. Этап начисления.

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

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

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

  4. Отправка документов с начислениями и прочих документов, введённых в ЦО на участки.

III. Этап печати квитанций.

  1. Определение конечной даты приёма платежей и корректировок с участков, импорта и приёма платежей в ЦО.

  2. Приём платежей и корректировок с участков.

  3. Проведение повторного начисления абонентам с фактами изменения расчётных данных для расчётного месяца после выполнения начислений.

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

  5. Проведение тестов незакрытых месяцев на предмет нарушения регламента.

  6. Печать квитанций.

  7. Отправка документов на участки.

  8. Проведение теста незакрытых периодов нв участках.

! Изменения расчётных данных и приём показаний в период между начислениями и печатью квитанций

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

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

  2. Провести повторное сторнирование. Ранее просто пересторнировалось всем.

    В последних версиях для этого  нужно запустить процедуру "Проверить незакрытые месяцы" в ЦО и вновь передать данные на участки.

Проверка нарушения регламента

Запускается перед формированием книг квитанций и перед отправкой данных после начислений на участки. Во время теста осуществляются:

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

  2. Определяется наличие по одному абоненту и одному месяцу(дата документа) нескольких корректировок и сторнирований с датами операций, попадающими в незакрытые месяцы.

  3. Ищутся факты изменения расчётных данных лицевых счетов, ввода показаний и отключений после проведения начислений за расчётный месяц.

  4. Ищутся факты наличия сторнирований прошлых, выполненных в незакрытом месяце (дата операции) при отсутствии показаний в этом месяце (были удалены показания после пакетного сторнирования).

  5. Ищутся факты отсутствия нужного сторнирования прошлых месяцев при наличии показаний, заявленных в текущем месяце (показания были введены или приняты с участков после выполнения пакетного сторнирования)

Все найденные факты показываются в диалоге в виде списков для запуска этапа исправления. В процессе исправления:

  1. Из множественных начислений оставляются начисления с последней датой.

  2. Осуществляется повторное начисление (с удалением имеющихся) абонентам, у которых обнаружено изменение данных задним числом.

  3. Удаляются сторнирования для абонентов, у которых показания были удалены после пакетного сторнирования.

  4. Выполняется сторнирование для абонентов, которым были введены или приняты показания после пакетного сторнирования.

  5. Удаляются все найденные множественные перерасчёты и сторнирования и делается единый перерасчёт месяца по абоненту.

Факты удаления любых документов будут переданы на участки с очередными датаграммами за соответствующий интервал дат.

Изменения "задним числом"

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

Во время перерасчёта указывается интервал месяцев, по каждому из которых;

Факты удаления любых документов будут переданы на участки с очередными датаграммами за соответствующий интервал дат.

Глобальные установки

    Возможность создания процедуры логической проверки документов на предмет соблюдения регламента появилась после создания в глобальных установках ряда важных настроек, состояние которых нужно проверить перед выполнением процедуры:


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