Модель Теплосети и начислений в 1С для ТеплоКоммунЭнерго

 “Фишка” в том, что обычная для западных фирм идеология параметрически настраиваемых “пользовательских стандартов” (скрываемых в сейфах их руководств) , исторически НЕ вошедшая в сознание отечественных разработчиков электронных систем здесь демонстрируется в среде 1С v7, не имеющей средств генерации собственных видов объектов пользователя из встроенных в 1С. Более того, вводимые здесь пользовательские стандарты для куда более широкого класса задач реализуются исключительно средствами самой 1С v7 без каких-либо внешних надстроек (“наворотов”) типа 1C++ и других с добавкой всевозможных *.dll. Не ограничивая использование встроенных стандартов 1С и расширяя их возможности, пользовательские стандарты делают лаконичными и сходными даже внешне формы и модули объектов – справочников и документов, журналов и отчетов, заметно упрощая управление ими (диалог). Эти стандарты позволяют обойти ограничения и недоработки среды, включая приводящие к сбоям откровенные ляпы, которых даже в такой распространенной и относительно простой 1С v7 только мне удалось зарегистрировать более 700. Наконец, это - демонстрация пути, без которого широкое распространение инноваций в любой области деятельности рискует оказаться только (!) благим пожеланием и тем более на периферии
 

P.S. Без особых хлопот с еще большим эффектом эти стандарты можно перенести в 1C v8. При желании увидеть в действии такое Приложение 1С v7 (конфигурацию с текстами модулей и Теплосетью с начислениями для клиентов пары домов), обращайтесь по E-mail patrickeev@mail.ru
 

Немного поучительной Истории ТеплоКоммунЭнерго

В 2001-2004 годах мне была поручена информационно-вычислительная служба Луганского (Украина) ТеплоКоммунЭнерго, программисты которой самостоятельно поддерживали систему взаиморасчетов с физическими лицами порядка 60 тысяч клиентов на базе Delphi+SQL2000 в локальной сети с центральным сервером и тремя операторами абонентского отдела – терминальными станциями.
 

 1) Визуально операторы использовали набор простых (не связанных между собой) линейных форм – каждая с двумерной таблицей (главная – список клиентов), связанная непосредственно с удаленной (remote) Базой Данных (БД) SQL-сервера и потому работающая с видимыми (1-4 сек) задержками даже в простейшей операции перелистывания (PgUp, PgDn)
Рынок ИТ-услуг в России: оценки, тренды, крупнейшие участники. Обзор и рейтинг TAdviser 298.3 т  
 2) Как и добрых 50 лет тому назад весь диалог - множество также с линейной структурой (НЕ иерархических) меню, клавиш и кнопок с многочисленными подсказками, придуманными многочисленными кодами команд каждая с собственной последовательностью параметров - зачастую также надуманных и отсутствующих в инструкциях служб многочисленных кодов, например, типа 3001 – клиенты, обслуживаемые домовыми счетчиками
 
 3) Начисления выполнялись так же старинным обычным для наших программистов способом – скрытыми от абонентского отдела алгоритмами в текстах хранимых процедур на языке T-транзакт с примитивным последовательным долгим перебором строк (кортежей) таблиц (файлов)
 
 4) Собственно структурно база данных НЕ был реляционной – предметным образом отображающей объекты теплосети и начислений со связями между ними. Потому в начислениях НЕ использовался основной скоростной механизм – запросы SQL, при которых СУБД эффективно применяет буферный пул для сокращения числа обращений к винчестеру
 
 5) И самое тревожное: Архив взаиморасчетов с клиентами тормозил начисления и особенно перерасчеты за прошлые периоды (месяцы), причем с каждым очередным периодом все заметнее. Информационно Архив представлял собой множество машинных Лицевых карточек клиентов в одной таблице SQL: единство Базы Данных (БД) разработчики понимали буквально! Вместе с тем это позволяло с некоторыми задержками по требованиям служб предприятия и города получать любые сведения в 2-3 не регламентированных запроса на языке SQL
 
 6) Угроза жизни Архиву вынудила меня трансформировать его в структуру из нескольких логически связных (индексы) таблиц с минимальными затратами памяти SQL-сервера (коды таблиц и индексов), позволяющую эффективно его наращивать и обрабатывать исключительно запросами SQL в перспективе хотя бы еще лет 20. Одновременно он был перенесен в среду в то время более скоростной версии freeware MySQL, к тому же ориентированной на использование в технологиях программирования Internet и потому дистанционно легкодоступную другим службам ТеплоКоммунЭнерго
 
 7) Диалоги операторов абонентского отдела, начисления за текущий и ряд предыдущих периодов (перерасчеты) были перенесены в среду 1С v7 электронной документации (справочники, документы, журналы) и оперативного учета (календари, оборотные регистры) с мощными средствами экранных форм 1С, в т.ч. связных (подчиненные справочники и документы) и еще более гибких генерируемых (автоматизация) форм Отчетов
 
 8) БД 1С и SQL-БД (архив) стали предметными и реляционными: в них четко были определены объекты, включая два вида услуг – Отопление (Тепло) и Горячее ВодоСнабжение (ГВС), Счетчики с их Установками (состояние после снятия на поверку в лаборатории), их размещение на Теплосети, с любой точностью также предметным образом отображаемой, включая вводы (Входы) Теплосети в дома и даже в квартиры (стояки)
 
 9) Обработка SQL-архива (6) управлялась также из Приложения 1С, генерирующего для этой цели (например, при формировании лицевой карточки) запросы SQL и направлявшего их для исполнения SQL-серверу. Скорость начислений возросла и за счет параллельной работы SQL-сервера и Приложений 1С (физически разные серверы)
 
 10) Абонентский отдел ТеплорКоммунЭнерго получил возможность видеть в формах и без приостановки системы визуально корректировать НЕ только структуру Теплосети от Котельных до их входов в дома и далее вплоть до стояков внутридомной сети трубопроводов с произвольным размещением Счетчиков, но и произвольно логически и визуально (структура БД, формы, отчеты) связывать льготы клиентов с любыми частями их отапливаемых площадей (Тепло) и обслуживаемыми клиентами (ГВС), причем все это унифицированным по Виду обслуживания образом
 
 11) Перерасчеты за прошлые периоды фактически сводились к повторению начислений – перепроведению (терминология 1С) документов этих периодов. Изменения теперь легко выяснялись сравнением результатов перерасчетов с Архивом (6) за те же периоды и помещались в тот же Архив, но уже на текущий период (месяц)
 
 12) Обработка различных реестров от почты, банков и местных отделов субсидий была унифицирована и настраивалась в принципе на любую структуру реестра
 
 13) В 2002 году буквально в течение 2 месяцев новая система была запущена в эксплуатацию вместо прежней
 
 14) Позднее функции выборки из Архива запрашиваемых службами предприятия НЕ регламентированной структуры данных также были автоматизированы с передачей их непосредственно начальнику абонентского отдела. Для него был разработан простейший удобный язык таблиц с условиями выборки, чем то напоминавший QBE и позволявший запрашивать любые сведения, в том числе и для предварительно отобранного в 1С списка клиентов. Неявно для него генерировался поток запросов к SQL-серверу и формировался MXL-отчет (электронная таблица) с нужными данными. – В итоге программисты избавились от ручных операций по выполнению нестандартных запросов к БД, чуть не каждый день поступающих от руководителей служб ТеплоКоммунЭнерго и отделов горисполкома
 
 15) В 2005 году ТеплоКоммунЭнерго (уже без меня) вместе с названием влили в другую аналогичную организацию и новый хозяин вместе со своими программистами и программами, выбросив все Приложения не знакомого им 1С, перенес данные (с потерей части из них) в собственные “самопальные” Приложения давно устаревшей среды типа FoxPro 2. Не удивительно, что уже к 2008 году база данных с этой системой рухнула и ТеплоКоммунЭнерго вынуждено было привлечь коммерческую организацию, внедрявшую сходные и куда более простые системы в снабжении населения водой и электроэнергией
 
 16) И все вернулось на своя круги (1)-(5) и даже проблематичнее: теперь закрытая для своих программистов и абонентского отдела система начислений с данными, недоступными для других служб ТеплоКоммунЭнерго со своими системами, сопровождаемыми уже другими коммерческими подрядчиками столь же скрытым образом и все вместе за существенные деньги без сколь-нибудь заметных усилий со своей стороны. Теперь к проблемам (1)-(5) добавились новые:

 17) В итоге в конце 2010 года руководство ТеплоКоммунЭнерго вспомнило об утерянных решениях (6)-(14) по интеграции различных своих служб в рамках 1С и обратилось ко мне с просьбой помочь восстановить утерянное в 1С, но уже с учетом вдвое возросшего числа клиентов, изменившейся организации взаиморасчетов с ними и накопившегося огромного опыта стран СНГ в части 1С
 
 18) На основе накопленных мною собственных пользовательских стандартов в 1С в течение буквально двух месяцев аналогичная (6)-(14) , но многократно более эффективная в диалоге, эксплуатации и быстродействии система была собрана, протестирована и затем опытным порядком проверена на объекте заказчика. Более того, в среду 1С (что не обязательно!) удалось встроить и архив взаиморасчетов, вынуждено сохранив часть НЕ унифицированных решений и данных истории действующей системы (16) и, соответственно, ряд тех же проблем.
 
Ввиду новых ограничений госпредприятия ЖКХ на использование финансовых средств для развития (по договорам с подрядчиками) ТеплоКоммунЭнерго взяло на себя теперь куда более сложные функции внедрения системы (18) с заменой закрытой действующей (16), а также разработку уже в среде 1С многочисленных действующих отчетов с сокращением их числа соответствующей унификацией.
 
Мне же представилась возможность, уйдя от ограничений вызванных во многом надуманными проблемами действующей системы (16), привести решение (18) к типовому, предлагаемому ниже на уровне концепций
 

Концепции системы взаиморасчетов с физическими лицами

Решения инфологической структуры

   1) Структурно (конфигурация) и визуально (экранные формы) База Данных (БД) отображает реальную теплосеть с любой точностью от котельных и их подключений к домам ("Входы") вплоть до системы трубопроводов внутри каждого дома (стояков) и далее до каждой квартиры (подключения или входы клиента в Теплосеть), позволяет вносить в нее уточнения и изменения буквально "на ходу" - без остановки автоматизированной системы (Приложения 1С). При этом для перерасчетов в прошлом сохраняются все характеристики такой теплосети на моменты изменений включая любые ее элементы, наличие, установку и снятие счетчиков, их характеристики
 
 2) На основе модели (1) теплосети вводятся режимы работы котельных, учета их простоев, сбоев в обслуживании домов и ниже по иерархии элементов внутридомной системы трубопроводов вплоть до отдельных стояков и подключений к ним площадей и жильцов одного клиента с произвольно определяемой пользователем классификацией причин простоев - отказов в обслуживании. Из этих данных автоматически генерируются удобные для начислений в компактном виде графики обслуживания домов, их входов в теплосеть (вплоть до стояков). Попутно такое решение снимает с пользователя затраты на составление обычно принятых многочисленных актов по отказам в обслуживании клиентов.
 
 3) При общих для всех клиентов тарифах для каждого Подключения (1) клиента к теплосети (Входа Клиента) явно в Базе Данных (БД) с отображением в экранных формах вводится Схема (модель, рис.1 и 2 Приложения к статье) начислений отдельно по каждой из Услуг (Тепло, ГВС). Эта схема состоит из любого количества элементов начислений, идентифицируемых каждый (элемент) набором исходных данных клиента:
   
 - основной параметр (площадь – для ‘Тепло’, количество жильцов – для ГВС)
 - основная Льгота, действующая для основного параметра по Виду услуги (Тепло, ГВС)
 - Коэффициент льгот (процент), возможно при одновременном действии нескольких льгот (госбюджет, местный бюджет) отличающийся от установленного основной льготой,
 
причем последние два значения могут отсутствовать (нет Льгот). Эта модель через подключения – входы клиента в теплосеть связывается (ссылки ID) с моделью (1) Теплосети – со Входами Домов в теплосеть и, следовательно, с графиками (2) обслуживания Котельной. Модель легко корректируется "на ходу" и все ее изменения во времени также сохраняются для перерасчетов в прошлом. Модель начислений унифицирована по видам обслуживания (Тепло, ГВС), включая структуру исходных данных, алгоритмы начислений, экранные формы, результаты начислений и формы отчетности. Без проблем можно ввести новые пока отсутствующие виды услуг. Автоматизирован процесс первоначальной генерации модели начислений по данным квартиры клиента, его льготам и подключениям к Теплосети его квартиры и дома
 
 4) С точностью до часа Начисления по Тарифу производятся отдельно по каждому Виду обслуживания и каждого элемента (3) исходных данных для начислений клиента, причем вне зависимости от использования этим элементом домовых или индивидуальных (клиентских) счетчиков, включая результаты начислений. Инструкциями и соответствующим справочником Тариф по каждому виду услуги указывается на месяц и является периодическим – меняющимся во времени. В начислениях же используется Тариф в расчете на 1 час, пересчитываемый из месячного. Этот почасовый, возможно, скорректированный Тариф сохраняется в документе ‘НачислениеПоТарифу’, формируемом отдельно по Котельной и Виду услуги (реквизиты Шапки документа). Начисления по тарифу производятся для всех обслуживаемых котельной клиентов проведением этого документа. При изменениях исходных данных по котельной (режим), дому или его клиентам достаточно перепровести (терминология 1С) этот документ, генерируемый вместе с графиками обслуживания автоматически при установке режима котельной на Период (месяц) и регистрации ее простоев в обслуживании Входов домов и клиентов в теплосеть. Затем можно группой (одна операция) провести все документы по всем таким Котельным за период стандартными средствами 1С
 
 5) Результаты начислений (4) формируются также отдельно для каждого элемента (2) исходных данных и НЕ в регистрах учета, но в справочниках, подчиненных корневому справочнику ‘Периоды’ (начислений) связываемых в древовидную структуру (иерархически подчиненные справочники) вместе с исходными данными, включая графики (2) обслуживания котельной оптимальным по затратам памяти (коды БД) и быстродействию образом. При этом НЕТ необходимости каждый раз при смене периода взаиморасчетов запускать стандартную (1С) процедуру пересчета регистров (Оперативный Учет)
 
 6) Акты счетчиков (документ) унифицированы по виду счетчика (домовой, клиентский - индивидуальный), Виду услуги (Тепло, ГВС) и операциям с ними: установка, поверка (снятие показаний), снятие счетчика на тестирование с последующей сменой исходных показаний очередной установки Счетчика. Акты генерируются по каждому дому автоматически (список счетчиков и их установок) и тогда же по каждому счетчику (Акт) предлагается лишь уточнить показание, вычисленное из предыдущих показания и расхода теплоносителя по Счетчику. Акты поверки могут быть генерированы из предоставляемых (магнитные носители) реестров банков и почты по оплатам клиента за один или более прошлых периодов. Пользователь может отдельными Актами определить отложенные Счетчики - без полученных показаний за период. По таким счетчикам (актам) показания вычисляются по расходу за предыдущий период или среднему расходу за предыдущие периоды. Без проблем можно вести в таких случаях методы экстраполяции
 
 7) Счетчики и их установки произвольным образом распределяются по Входам домов, клиентов и даже элементам (3) модели начислений клиентов. При проведении Актов (6) расходы теплоносителя по показаниям Счетчика автоматически распределяются по этим элементам пропорционально значениям их основных параметров (3) - обслуживаемые Площадь (Тепло) или число жильцов (ГВС). Погрешность распределения относится (корректируется) на элемент с максимальным значение параметра. Тем самым сокращаются затраты времени и упрощается алгоритм начислений (8) по Счетчикам
 
 8) Начисления по Счетчикам (и Виду обслуживания) Клиентов одного Дома, Улицы, Участка Эксплуатационного района (или всех клиентов одновременно) могут производиться (не обязательно) отдельно своим документом (a) 'НачисленияПоТарифуИСчетчикам', если для них (использующих Счетчики) уже имеются результаты (5) начислений по тарифу и проведенные акты (6) счетчиков. Результаты начислений по Счетчикам автоматически привязываются (подчиненные справочники и ссылки) к результатам (5) начислений по Тарифу с их исходными данными для каждого элемента (3) модели начислений клиента, включая графики обслуживания. Тем самым резко сокращаются затраты времени и памяти (коды справочников с результатами) на вычисления и максимально - буквально до нескольких операторов языка программирования 1С упрощаются алгоритмы начислений в случаях, когда домовой и/или клиентский счетчики устанавливаются или снимаются в середине отчетного периода (месяц) и приходится сводить начисления по тарифу и счетчикам
 
 9) По всем клиентам с поверенными (Акты) или не поверенными счетчиками сохраняются все их элементы начисления по Тарифу (результаты). Проведение новых (дополнительно) Актов счетчиков и затем еще одного документа (8a) по таким клиентам в том же или следующем Периоде автоматически внесет изменения в начисления (8) по ним, подвязываемые к элементам начислений по тарифу. При этом НЕТ нужды повторять начисления (5) по тарифу. Понятно, что теперь абонентский Отдел может видеть в экранных формах для каждого элемента (3) исходных данных клиента как Начисления (5) по Тарифу, так и (8) по Счетчикам, т.е. содержание начислений, которые теперь легко сообщить и клиенту
 
 10) Периодические реквизиты 1С обеспечивают сведение перерасчетов в прошлом к простому повторению начислений (проведение документов) в предыдущие периоды. Однако большое количество таких исходных во времени меняющихся данных клиентов (площади, количество жильцов, их льготы) порождает угрозу снижения быстродействия в начислениях, которую удается предотвратить локализацией таких данных в отдельном невидимом (экран, формы) служебном справочнике, причем без потерь для восприятия абонентским отделом
 
 11) Суммирование результатов начислений по всем Входам (1) клиента в теплосеть и их исходным основным параметрам (3) - обслуживаемая площадь (Тепло) или число жильцов (ГВС) происходит только при помещении результатов начислений в Архив взаиморасчетов (в самом Архиве)
 
 12) Унифицированный по видам обслуживания Архив взаиморасчетов с клиентами можно вести непосредственно в среде (конфигурация) 1С в упакованном виде: используется 36-ичная система счисления (знаки 0-9,A,B,…Z) прежде всего для параметров (реквизитов), включаемых в индексы таблиц (Dbase или SQL-таблицы - модель данных 1С), например, скрытый от абонентского отдела уникальный 4-х-значный код LS клиента, однозначные данные (коды) периода - Год, Месяц (справочник ‘Периоды’) и др. В случае модели Dbase данных вводятся учитывающие специфику взаиморасчетов с клиентами специальные решения, резко сокращающие затраты памяти и время доступа к данным Архива. В целях надежности сохранения Архива при любой модели данных (Dbase или SQL) в его структуре исключены явные связи (внутрисистемные ссылки ID) с оперативно используемыми разделами (1) и (2) БД. Тем самым упрощается и перенос Архива из конфигурации 1С в удаленную (remote) БД выделенного SQL-сервера при росте требований к числу клиентов и сроку службы Архива
 

Решения на Операционном уровне - Пользовательские Стандарты

 
 Исторически эти понятия отсутствуют в отечественных технологиях программирования Информационно-Вычислительных Центров (ИВЦ) и отделов предприятий (развитие оффисов, вычислительной техники и ИВЦ), как и соответствующие руководства в них, сохраняемые от конкурентов в сейфах западных фирм. Потому здесь в 1С, лишенной средств генерации собственных видов пользовательских объектов, демонстрируется построение эффективных пользовательских стандартов использованием прежде всего следующих встроенных возможностей среды 1С:
 
 - Программный доступ модулей к Метаданным – практически к описанию любого объекта в конфигурации
 
 - включение ссылок ID на объекты типа "Метаданные" в динамические структуры - списки из списков и таблиц значений (глобальные переменные - export). Эти структуры создаются для описания свойств открываемых (вводимыми стандартами) форм объектов (справочников, документов, отчетов) и даже содержат данные по подчиненности и порядку открытия форм объектов
 
 - программный доступ процедур глобального модуля к элементам формы объекта, их значениям и свойствам и даже переменным ее модуля через ‘Контекст’ (терминология 1С) формы
 
 - значения параметров настройки и частично операции (действия) пользовательских стандартов можно задавать выражениями и шаблонами в MXL-таблицах форм и общих таблицах глобального модуля
 
 - символ '_' (подчеркивание) в идентификаторах процедур, объектов и реквизитов позволяет определения стандартов в конфигурации и модулях заведомо отделить от общепринятых аналогичных определений даже в стандартных конфигурациях 1С
 

 
Предельная компактность, читабельность модулей форм справочников, документов и отчетов, радикальное снижение затрат пользователя на манипулирование ими (интерактивный диалог), повышение качества форм и диалога достигается введением пользовательских стандартов - элементов управления (формы, общие таблицы) и операций с ними - здесь до 90% “стандартных” функций и процедур глобального модуля, легко переносимых простым копированием из формы в форму того же или других Приложений (конфигураций) 1С. В глобальном модуле эти стандарты разделены (разделы) комментариями по видам объектов (справочники, документы, отчеты и др.), что позволяет переносить лишь завершенную часть – раздел необходимых стандартов.
 
  Для подключения формы справочника или документа к этим стандартам достаточно ввести в нее объект типа 'Текст' с идентификатором '_F' и заголовком - уникальным именем формы среди прочих форм – здесь Ф1, Ф2,… . В предопределенных процедурах 'ПриОткрытии' и 'ПриЗакрытии' нужно обратиться, соответственно, к процедурам 'гл_ОткрытиеСправочника' и 'гл_ЗакрытиеСправочника' (Документа). Вводимые здесь пользовательские стандарты являются настраиваемыми: их параметры в виде текстов, выражений или шаблонов языка программирования 1С помещаются и корректируются самим пользователем в глобальных (общих) MXL-таблицах с фиксированными именами:
 
общ_Реквизиты
- Описание синтаксиса (лексической структуры) и логического контроля реквизитов форм справочников и документов. Горизонтальные секции таблицы - суть имена реквизитов согласно конфигурации Приложения 1С, вертикальные – пользовательские имена форм справочников и документов, определяемые идентификатором _F в формах (см.выше). В ячейках пересечения горизонтальной (реквизит) и вертикальной секций (форма объекта-справочника или документа) содержится описание синтаксиса и логического контроля реквизита в соответствующем объекте. Такое решение, упрощая поиск этих описаний, стимулирует разработчика Приложения единым образом определять одноименные реквизиты в различных объектах и их формах, заметно упрощая описания параметров настройки этих стандартов
 
общ_Соответствия

• Тесты логического контроля элементов справочников при (до) записи элемента, задаваемые в любом количестве разрабочиком Приложения и корректируемые пользователем. Вертикальные секции определяются аналогично предыдущей общей таблице, а горизонтальные - выполняемый следующим очередной i-й тест - секцию с именем 'Тест[i]' (i=1,2,3,...)
  

 
общ_ДокКонтроль

• аналогичные тесты для документов, задаваемые также в любом количестве, но отдельно для Шапки документа, поочередно проверяемых его строк и Итогов.
  

 
 Каждая из этих таблицы начинаются одноименной горизонтальной секцией 'Реквизиты<i>', в которой "1" означает включение контроля синтаксиса и логики (реквизитов, тестов) для соответствующего (вертикальная секция) объекта. 0 или отсутствие (пусто) значения в этой секции отключает контроль. Это значение может задаваться явно или выражением (шаблоном), динамически (в ходе обработки) вычисляющим включение или отключение контроля. Горизонтальные и вертикальные секции в этих таблицах могут следовать в любом порядке, НЕ влияющем на результаты контроля. Специальной константой может быть введен режим тестирования перечисленных функций логического контроля, при котором формируются более подробные сообщения о его ходе.
 
 Все перечисленные таблицы в закладках ‘<i>Расшифровка’ ячеек также выражениями и шаблонами могут задавать действия при обнаружении ошибок логического контроля: как минимум, генерировать текст сообщения, изменять значения реквизитов с обнаруженными ошибками, делая их текущими в формах и, наконец, запускать в принципе любые процедуры глобального модуля, а также открывать формы любых объектов конфигурации.
 
  Незначительная часть с фиксированными именами параметров настройки стандартов помещается непосредственно в формах объектов и комментариях к их реквизитами в конфигурации Приложения. Параметры настройки Генератора Отчетов размещаются пользователем в одинаковом для любых Отчетов легко читаемом виде непосредственно в MXL-таблице - шаблоне Отчета. Такое решение делает формы справочников и документов, их модули, шаблоны отчетов почти идентичными при их просмотре в конфигурации (конфигуратор 1С), сводя к минимуму затраты на их создание и модификацию (редактирование). При этом нет необходимости осваивать новые объекты за рамками уже известных из 1С, например, из 1С++, Yoksel, FormEx и др.
 
 Далее краткий обзор вводимых в среде самой 1С (исключительно ее средствами) пользовательских стандартов и предоставляемых ими новых возможностей пользователю:
 

Манипулирование формами справочников

 
 1) При закрытии формы списка справочника (как и документа) автоматически сохраняются текущие (на момент закрытия) определения строки и колонки списка (строк документа), значения указанных при обращениях к стандартам полей формы, параметры отбора элементов справочника, причем сохраняются НЕ порознь, а экономнее (быстродействие и память) в виде единой динамической структуры со скрытым от пользователя идентификатором. При повторном открытии формы все эти параметры автоматически восстанавливаются и также быстрее, чем обычно
 
2) При закрытии формы списка справочника автоматическое удаление с экрана всех форм подчиненных ему справочников и т.д. всех вниз по их иерархии подчинения
 
3) Выпадающий список стандартным образом для формы списка сообщает заголовок реквизита в форме (а не его идентификатор или синоним!), включая заголовок колонки с Кодом или Наименованием элемента справочника, по которому список элементов упорядочен. Для смены этой упорядоченности достаточно установить текущим другой реквизит из этого списка
 
4) При открытии формы списка справочника-владельца ранее (уже) открытых форм подчиненных ему справочников последние незамедлительно сворачивают списки своих элементов до подчиненных текущему элементу формы вызванного справочника-владельца. Таким образом, снимается требование общепринятых руководств 1С вызывать всегда первой форму списка справочника - владельца
 
5) При наличии подчиненных справочников и прав доступа пользователя хотя бы к одному из них в форме справочника - владельца стандартным образом проявляется (делается доступной) кнопка вызова списка доступных (!) пользователю подчиненных справочников. В случае списка из одного такого справочника форма последнего вызывается на экран незамедлительно без выбора этого элемента списка. Заголовок этой стандартной кнопки и ее положение в форме уточняет пользователь посредством генератора форм 1С. Обычно вначале эту кнопку копируют из другого справочника
 
6) Отображение в заголовке формы списка справочника ключевых (по смыслу) реквизитов текущей строки справочника - его владельца (отца), но и выше по иерархии деда - владельца владельца, а также текущих параметров отбора. При этом аналогично (3) используются НЕ синонимы реквизитов из конфигурации, а по возможности текущие их заголовки в форме, включая Код и Наименование элемента справочника. Лишь в отсутствие отображения этих реквизитов в форме используются их синонимы из конфигурации- Такое же решение применяется и в следующих стандартах, включая отображение реквизитов итогов (7) и Отбора, включая (8)
 
7) Отображение (не обязательно!) количества и итогов (сумм выбранных реквизитов) элементов формы списка справочника, подчиненных текущей строке (элементу) формы списка справочника - владельца первого. Список включаемых в Итоги реквизитов через ‘запятую’ перечисляется непосредственно в невидимом пользователю поле “_сп_Итогов” той же формы, как и формат этих итогов в поле “_ИнфоСпр” типа ‘Текст’
 
8) Отбор элементов справочника по набору (кортежу) из нескольких реквизитов, включая часть из них одновременно по интервалам числовых значений и дат. Частично эти возможности встроенными средствами реализованы в версии 1Cv8. Сортировки (3) распространены на кортежи реквизитов (скрытые визуально в форме списка реквизиты с идентификаторами 'Отбор_...'), как и отображение текущего Отбора по кортежу в заголовке формы списка справочника. Стандартным образом в форме производится установка значений реквизитов - элементов кортежа в соответствующие значения, включая выбор интервала значений - чисел или дат (скрытые в форме реквизиты 'ОтДо_...). Элементы управления этим отбором, включаемые в форму, обслуживают и отбор по встроенным средствам 1С (одному реквизиту). Напомним, что 1С не позволяет выполнять отбор по значению Кода или Наименования элемента и это ограничение также снимается вводимыми здесь стандартами. Отбор по значению Перечисления, как и других объектов (справочник, документ, дата и др.) вводимые стандарты выполняют заметно быстрее (чем встроенные в 1С средства) и экономнее в расходах памяти на индексирование
 
9) Контекстный отбор элементов справочника по указываемой пользователем произвольной комбинации обрывков значений (подстрок) его реквизитов. Тезаурус для поиска и отбора ведется в служебном справочнике и корректируется автоматически при редакции элементов справочника, в котором осуществляется отбор. Здесь (Приложение 1С) эти средства применены в справочнике 'Дома' (неявно в спр.Клиенты) для отбора домов по подстрокам Адреса (Улица, Пункт и др.). Здесь заимствовано простое решение, предложенное одним из москвичей и ограничивающее размер справочника несколькими тысячами элементов. Впрочем существует испытанное мною в фирме оптовой торговли эффективное решение, более чем на порядок ослабляющее это ограничение при исходных указываемых пользователем дополнительных вариантах поиска
 
 

Манипулирование формами документов и журналов

 
 Эти стандарты реализованы сходным для справочников (см. выше) образом, включая отбор документов в журнале типа 'Общий' по кортежу реквизитов шапок документов и/или интервалов их значений (чисел, дат). Дополнительно могут быть определены интервалы Количеств строк и Дат документов, по которым (интервалы) отбираются документы в журнале. Как и в случае справочников рассматриваемые операции Отбора документов могут инициироваться вручную пользователем и программно в различных модулях. В данном Приложении эти стандарты НЕ используются не взирая на поддержку их глобальным модулем и утилитами (Обработки) конфигурации.
 

Лексический анализ объектов типа 'Текст'

 
1) Синтаксис (лексическая структура) реквизитов справочников и документов определяется в глобальной (общей) таблице 'Общ_Реквизиты' (рис 3. Приложение к статье) на языке подобном языку регулярных выражений (RegExp) в языках Perl, Jscript и JavaScript. Анализ соответствия значения реквизита определению его синтаксиса выполняется стандартным лексическим анализатором (комплекс реентерабельных процедур), включенном в глобальный модуль Приложения
 
2) Для освоения языка (1) описания лексем и проверки корректности этих описаний в конфигурацию введена обработка 'Лексический Анализатор'. Там же описание этого языка с примерами
 
3) Лексический анализатор с успехом использовался для обработки текстов, извлеченных из PDF-файлов французских фирм с нормами технологии швейных изделий на давальческом сырье. Из этих текстов на основе описания их лексической конструкции извлекались данные и помещались в БД соответствующего Приложения 1С
 

Инициализация реквизитов справочников и документов

 
 При создании новой строки справочника или документа (объект) стандарт организует загрузку исходных значений ее реквизитов - результатов вычисления формулы (выражения или шаблоны) в ‘расшифровках’ соответствующих ячеек общей (глобальный модуль) MXL-таблицы 'Общ_Реквизиты' (рис.3). В этих формулах допускается использование глобальных переменных, атрибутов и методов объекта, реквизитов ранее (предыдущих в конфигурации) инициализированных реквизитов текущей строки, значения инициализируемого реквизита из предыдущей текущей строки, исходные (до редакции) значения реквизитов редактируемой строки и дополнительно любые параметры (ссылки на объекты), передаваемых при запуске процедуры - стандарта. В случае документа в формуле инициализации могут быть использованы реквизиты шапки. Допускается для каждого реквизита строки задать последовательность формул инициализации (расшифровок) и каждое с условием запуска инициализации - закладка 'Текст' окна свойств ячейки MXL-таблицы 'Общ_Реквизиты' (рис.3). Эти условия проверяются в том же порядке последовательности и лишь при выполнении условия (значение 1 выражения) очередной формулы производится инициализация – установка значения реквизита в результат вычисления формулы ("Расшифровка"). - В этом случае следующие формулы последовательности не используются
 

Логический контроль реквизитов справочников и документов

 
 Соответствующий стандарт запускается либо после ввода или редакции реквизита из формулы свойства его поля в форме объекта (документ, справочник) либо при записи строки поочередно для каждого реквизита в порядке их следования в конфигурации объекта. - В любом случае предварительно автоматически производится контроль синтаксиса согласно п.1.2.2.3 и лишь в отсутствие нарушений синтаксиса выполняется логический контроль, задаваемый идентично инициализации (п.1.2.2.4) и там же (MXL-таблица 'Общ_Реквизиты', рис.3 Приложения к статье). Отличие состоит лишь в том что:
 
a) условие формулы (расшифровки) - суть выражение, определяющее (выход '1') корректность анализируемого введенного или редактированного значением реквизита. Значение 0 условия означает наличие ошибки
 
b) формула (шаблон) в закладках ‘Расшифровка’ или ‘Текст’ обычно задают текст сообщения, выдаваемый пользователю при обнаружении ошибки - значение 0 условия (а). Однако вместо такого сообщения можно задать формулой (результат ее вычисления) значение, которое заменит (скорректирует) введенное пользователем значение, и здесь же сопровождающее эту операцию сообщение об ошибке, возможно, предваряемое (префиксом) кодом ':' (двоеточие)
 
c) при успехе 1 логического контроля (а) запускается следующая формула контроля в их последовательности
 
d) вместо исходного значения редактируемого реквизита предыдущей текущей строки в условии и формуле контроля используется исходное (до редакции пользователем) значение реквизита, которое можно использовать здесь же для автоматического (формула) его восстановления в случае обнаружения ошибки
 
Здесь и выше (инициализация) безусловно в качестве условий можно использовать выражения языка 1С типа  

 
Однако для удобства записи этих условий в глобальном модуле введены логические (вычисляющие "0" или "1:") функции _И(...) , _ИЛИ(...) и другие с большим количеством входных параметров и возможностей при предельных мнемонике и лаконичности. Понятно, что эти функции могут быть использованы в любых модулях форм объектов
 

Логический контроль элемента справочника

 
  Общая MXL-таблица 'Общ_Соответствия' (рис.4 Приложения) может задать для любых справочников:

1) Список реквизитов (явно или вычисляемый выражением, шаблоном) строки, безусловно присутствующих (c НЕ пустыми значениями) при записи строки. При наличии пустых реквизитов из этого списка пользователю автоматически сообщается перечень пустых и запись элемента (строки) блокируется с установкой курсора на первый из пустых реквизитов
 

Внимание! Вводимый описываемый Синтаксический и Логический контроль реквизитов и/или строки любого справочника и документа можно динамически (выражением) отключить, заменив 1 на 0 - "Условие обработки" в секции 'Реквизиты' рассмотренных общих Таблиц с параметрами настройки стандартов
 

Логический контроль документа

Тесты (а) и (б) могут выполняться отдельно, соответственно, для Шапки при попытке ввода 1-ой строки и при попытке завершения редакции текущей строки.
 При обнаружении ошибки в одном из тестов последующие НЕ выполняются. Особенностью этих тестов является унифицированный доступ выражений общей таблицы к табличной части документа как к таблице значений. В случае (б) в выражениях ячеек таблицы 'Общ_ДокКонтроль' доступны реквизиты обрабатываемой очередной строки. В любом случае (а)-(в) доступны реквизиты шапки документа и итоги реквизитов со свойством 'Итог'. В тестах (в) допускается использование стандартной глобальной процедуры контроля дублей - кортежей значений из любых реквизитов строк. В этом случае автоматически сообщается список строк с дублями
 

Управление последовательностью ввода реквизитов строки

 
 Ввод реквизитов шапки документа рассматривается как ввод отдельной (0-й) строки. В строке (шапка или строка документа, элемент справочника) можно определить практическое любое количество не пересекающихся подмножеств реквизитов, каждое из которых определяется (инициируется) ПЕРВЫМ (начальным) произвольным символом комментария реквизита в конфигурации. В порядке следования таких реквизитов в конфигурации (необязательно подряд) это подмножество определяет цепочку реквизитов строки (элемента), ввод которых стандарты организуют строго в том же порядке: после корректного (синтаксис, логика) ввода значения очередного реквизита цепочки автоматически допускается ввод следующего по цепочке и блокируется доступ к следующим еще далее по цепочке. Более того, по завершении ввода или редакции реквизита (без нарушения синтаксиса или логики) цепочки автоматически осуществляется перевод курсора (форма справочника или документа) на следующий реквизит (колонка в форме объекта) цепочки: он делается текущим автоматически. - Иначе (нарушение синтаксиса или логики) этот переход блокируется. Допускается возможность автоматического сброса части цепочки следующей за верно редактированным (введенным) реквизитом цепочки
 

Генератор Отчетов

 
 При всей мощи средств 1С для формирования Отчета - MXL-таблиц на основе его шаблона (ИсходнаяТаблица) из таблицы значений (данные Отчета) большой проблемой является нумерация страниц, их выравнивание по длине (высоте), формирование иерархически определяемых групп строк в Отчете с их заголовками и итогами (подвалами), нумерация элементов (строк, подгрупп) в группе, оформление шапки следующей страницы при переполнении текущей, размещение заголовков определенных групп с начала страницы и др. Все это приходится каждый раз (Отчет) программировать вручную с достаточной трудоемкостью, включая оформление шапок и итогов групп. Попросту говоря, полномасштабный Генератор Отчетов отсутствует в 1С. Однако не теряя встроенных возможностей 1С в программировании Отчетов его удается ввести (глобальный модуль) достаточно простыми средствами самой 1С (Отчеты 'Лицевая Карточка' клиента, 'Отчет Периода' и др.). Как обычно, Отчет формируется генератором за один просмотр предварительно отсортированной по иерархии групп (ссылки на объекты - группы или их значения, коды) таблицы значений с данными Отчета.
 Отличающие от прочих особенности введенного здесь Генератора Отчетов:
 
 1) В нем для автономного применения пользователем (вне Генератора) выделен нижний его уровень - вертикальные и горизонтальные секции, нумерация страниц с их выравниванием по длине (высоте) и переносом отдельных горизонтальных секций шаблона в начало следующей страницы безусловно или/и при переполнении страницы Отчета.
 
 2) В шаблоне отчета в виде горизонтальных секций с фиксированными именами (идентификаторами) описывается структура страницы : Нумерация страниц, размер страницы в пунктах, определение групп в их иерархии и итогов в исходной таблице значений, требования переноса группы в начало следующей страницы и др. Понятно, что эти описания (параметры) могут быть заданы явно (текст), статически вычисляемыми выражениями или шаблонами при настройке генератора Отчета (процедура гл_НастройкаГруппОтчета) или только его нижнего уровня (1)
 
 3) Генератор Отчетов позволяет явно или выражением (шаблоном) в специальной горизонтальной секции шаблона Отчета задать вычисляемый (выражение, шаблон) список вертикальных секций в порядке их вывода в Отчет по каждой его строке, включая определяемые секциями Заголовки и Итоги групп
 

И точно также в этой секции выражения пользователя могут содержать переменные Отчета и обращения к функциям его модуля
 
 5) Выполняемые пользователем описания Заголовков и Итогов Групп отчета (горизонтальные секции шаблона Отчета) идентичны, оставляя возможность пользователю вносить нюансы в заголовки и подвалы (итоги) отдельных групп (в их описания в шаблоне), используя для этой цели как глобальные переменные Отчета с данными текущей секции группы, включая автоматически вычисляемые итоги, так переменные и функции модуля Отчета
 
 6) Локальная нумерация каждой группы (1,2,...) внутри содержащей ее группы - вышестоящей по уровню иерархии. Аналогично нумеруются строки в группе нижнего уровня. Доступ пользователя в описываемых им секциях текущей группы и строки к ее локальному номеру. Этот же Номер в секции итогов группы автоматически указывает количество составляющих ее элементов (подгрупп, строк). Ушлый пользователь без проблем может здесь же получить доступ к данным всех вышестоящих по уровню иерархии групп, включающих текущую группу (строку)
 
 7) Итоги Группы с из единственного элемента (подгруппа, строка) опускаются (не формируются) в целях сокращения затрат на носитель Отчета
 
 8) Отсутствуют какие-либо ограничения на количество групп (уровней их иерархии)
 
 9) Весь Отчет определяется как Группа наивысшего уровня - вся исходная таблица значений с данными Отчета. Такое решение позволяет заголовок и итоги отчета определять идентично (5) для групп (подгрупп) Отчета
 
 10) Через переменные Отчета (объект) в шаблон отчета и, соответственно, в секции заголовков, итогов групп и строк Отчета можно включать данные из любых других объектов (ссылки на них в переменных или выходах функций модуля Отчета) . -Типичный пример - достаточно сложный отчет "Лицевая Карточка" клиента, включающая много дополнительных исходных таблиц значений формы Отчета. Эти же данные можно применять здесь же для корректировки выражения секций) итогов групп
 

Другие пользовательские стандарты

 
  Среди прочих НЕ используемых в данном Приложении 1С, но поддерживаемых его глобальным модулем пользовательских стандартов следует обратить внимание на трактующий обычные числа как отсутствующий в 1С v7 тип "Время" (ЧЧ.ММ), а в паре с типом Date как "ДатаВремя" (DateTime). Здесь используются процедуры и функции глобального модуля (его раздел согласно комментариям), вычисляющие в различных единицах времени интервалы времени - их длительность и окончание с учетом часовых поясов и по желанию смены зимнего и летнего периодов. Эти стандарты успешно были опробованы при разработке в среде 1С модели маршрутной сети и расписаний движения городских, пригородных и междугородних автобусов
 

Приложение. Фото экрана 1C-Приложения (рисунки)

 
Рис 1. Входы Клиента в Теплосеть. Элементы начислений за Тепло

 
Рис 2. Входы Клиента в Теплосеть. Элементы начислений за ГВС

 
Рис 3. Синтаксический и логический контроль реквизитов. Параметры настройки

 
Рис 4. Логический контроль элементов справочников. Параметры настройки