Пользовательские стандарты – путь продвижения новаций не только в программировании

На TV-шоу г-ну Путину был задан уместный вопрос: `А каким образом из инновационных Центров новации будут поступать на периферию…?`. - И был ответ в духе до перестроечных времен: `Введем новые законы, льготы, специальные организации и…`. – УЖЕ Слышал это, когда мощное движение `НОТ` (Научная Организация Труда) ограничилось созданием на предприятиях кабинетов НОТ с плакатами и призывами. И тогда же в кулуарах жалобы руководителей предприятий:

• `На каждый станок у нас – один технолог!` - директор Калининградского завода ЭВМ;
  
• `В любом проекте машины каждый болт проектируем заново` -директор Луганского СТО Сорока (электронное машиностроение)

Внимание! - Уже в те времена на многих предприятиях `за бугром` отсутствовал Отдел Главного Технолога: технологами были лишь руководители предприятия, цехов и их участков. В перестройку передавал новации программистам ЦКБМ Брянского МашЗавода (БМЗ) в виде пользовательских стандартов технологии использования СУБД Paradox в управлении производством. `Мы надеемся, это позволит значительно сократить число сотрудников отделов программирования ЦКБМ` – главный инженер БМЗ. Я лишь с грустью заметил: `Не в них проблема! – Куда острее отсутствие пользовательских стандартов в ваших технологических, конструкторских и производственных отделах!!`. Конечно, проблема НЕ в г-не Путине и прочих во власти! – Проблема в нас самих – в нашей истории и даже сознании. Попробую изложить это в общедоступной мере со ссылками на личный опыт и все же в контексте программирования
 

Кто и как занимался новациями. История

Инновационные Центры

На Западе и США уже в до перестроечные времена такими центрами являлись технологические институты и университеты . Неудивительно, что во главе кафедр зачастую были ведущие специалисты крупных предприятий, не имеющие ученой степени и профессорских званий: реноме их практики было достаточным. Якобы так было и у нас: кафедрой кибернетики МИЭМ (Москва) руководил некий член-корр. АН СССР, одновременно - руководитель Союзного КБ, которого мне – ответственному исполнителю договора по теме `Лотос РВО` с этой кафедрой ни в одном из многочисленных приездов НЕ удалось лицезреть. Ак. Глушков В.М. числился руководителем кафедр во многих ВУЗ’ах СССР… Такими центрами должны были бы стать отраслевые институты, если бы НЕ оторванность отраслевой науки от академической (АН СССР) и ВУЗ’овской: в каждой из них были свои ученые, журналы, научные советы и прочее. В ВУЗ’ах существовал Научно-Исследовательский Сектор (НИС) на договорах с предприятиями - 2-й, 3-й и прочие заработки преподавателей, собственно связь с предприятиями и практика студентов на их оборудовании. В перестройку все это исчезло вместе с финансируемыми государством отраслевыми программами развития.
 

Кто и как распространяет новации

  Распространение новации в современной технологии физически воплощается разработкой соответствующих специфике предприятия пользовательских стандартов – легко настраиваемых на меняющуюся структуру производства унифицированных электронных модулей (систем) проектирования технологии, управления предприятием или производством, будь-то АСУ, САПР, программы ЧПУ для изготовления деталей на станках или системы медицинской диагностики. Эти стандарты разрабатываются, совершенствуются и систематизируются в соответствующем руководстве (документ) предприятия информационным отделом под грифом ‘Секретно’ в сейфе для защиты от конкурентов. В отсутствие приемлимого `руководства` такой отдел ликвидируется и предприятие ищет нового его руководителя. Эти руководства, как и понятие ‘пользовательские стандарты’ у нас традиционно отсутствуют и сейчас во многом исторически от пропущенного нами этапа механизированных архивов, конторских машин и еще многого до появления ЭВМ.   Многие предприятия США обходятся и без таких отделов, используя услуги небольших информационных и консультационных фирм, высокий доход которых оправдывается и гарантируемой ими конфиденциальностью - обеспечению секретности при доступе к базам данных клиентов. У нас НЕТ и НЕ было таких фирм, не считая ‘франчайзи’, перепродающих и слегка корректирующих стандартные конфигурации 1С, обучающих пользованию ими клиентов - бухгалтеров, системных администраторов и других. До сих пор нет и системных программистов, обладающих навыками разработки пользовательских стандартов для определенных классов задач в рамках различных инструментариев, например, в среде Delphi или все той же 1С: это нетрудно обнаружить даже при беглом просмотре стандартных конфигураций 1С.
 Рынок ИТ-услуг в России: оценки, тренды, крупнейшие участники. Обзор и рейтинг TAdviser 299.3 т Для прояснения проблемы несколько примеров из собственной практики:
 
  1) Наши пользователи не воспринимали линейчатые меню Paradox 3.5 в верхней строке экрана: русский не так лаконичен как английский! Но в течение 2 минут замешательства обратил внимание на: (a) любое меню – типичная древовидная структура, поддерживаемая связными экранными формами (linked forms) Paradox и (b) эти формы , как и часто используемые данные, размещаются в буферном пуле – фактически оперативной памяти. Ограничение же Paradox двухуровневой связью одной таблицы Master с прочими Slave можно обойти, отобразив на нее многоуровневую структуру Меню: разместив все связи (ссылки) многоуровневого меню в колонках однострочной Master-таблицы. - Через два часа получил первый пользовательский стандарт в Paradox – модуль, с любыми красками формы отображавший любое меню из таблицы со всеми опциями, позволяющий, выбрав любую опцию, запустить определенный в ней (ссылкой) модуль, экранную форму, форму отчета, или запрос к Базе Данных (БД).
 
 2) В отсутствие решения (1) прочим нашим пользователям Paradox 3.5 пришлось врукопашную посимвольно расписывать опции каждого меню на экране и для каждой опции программировать запуск соответствующего ей объекта. - Они так и не поняли механизма linked forms, позволившего мне в 15 минут рисованием форм на экране создать модель структуры БМЗ c цехами, участками, их руководителями и рабочими, и здесь же продемонстрировать работу с этой структурой. На ту же работу в ЦКБМ БМЗ тратили до двух месяцев с сомнительным результатом. По той же причине Paradox - программы известнейшего Днепропетровского отраслевого института машиностроения были практически необозримыми (сотни тысяч операторов языка PAL) с огромными задержками при их эксплуатации и слабой графикой
 
 3) По приходе Л. Кучмы во власть его предприятие и КБ `Южный` проводило семинар с руководителями предприятий машиностроения Украины и их ИВЦ, где обсуждалась и проблема поддержки баз данных Paradox и FoxPro. - Все высказались в пользу FoxPro, как более быстрого. Я же пытался обратить внимание на то, что нельзя сравнивать мощь истребителя FoxPro и бомбардировщика Paradox по скорострельности пулеметов – обработке таблиц поочередно просмотром каждой их строки, где FoxPro был в 7 раз быстрее. - Современный уровень `ракет` – использование параллельной (групповой) обработки строк таблиц запросами к СУБД (Local SQL для FoxPro и QBE – для Paradox). Здесь, как мне удалось доказать (ж-л `К+П` № 5, 1995 год, Киев, 1-я статья), картина с точностью до наоборот. Впрочем этими `ракетами` ,по большому счету, НЕ пользовался никто даже из наших любителей FoxPro, как не пользуются и сегодня в Приложениях Delphi, SQL-серверов и 1C v8. Одна из причин – отсутствие в СССР, как и сейчас (СНГ), преподавания теории и практики конструирования Баз Данных.
 
 4) В среде Paradox подготовил генератор многопользовательских (многотерминальных) его же Приложений, каждое из которых теперь собирал за одну-две недели. - Программистам ИВЦ ‘ЛуганскТепловоз’а на тот же результат требовалось до полугода. - Представил руководителю ИВЦ список стандартов генератора с краткими пояснениями. - Через три дня получил шокировавшую меня реакцию: `Это что же! – Программист должен стать дураком?`. Это и есть суть нашего понимания, точнее всеобщего не понимания важности и назначения пользовательских стандартов. На симпозиуме СНГ по программированию (Алушта) один из бизнесменов в области ПК высказался более определенно: `Какие еще там стандарты! – Да машине (в программе) что не дай – все схавает!` . - А это уже мы и причина наших бед…
 
 

Пользовательские стандарты

 

Раздел "Информатика" российской wikipedia.org в соответствии с требованиями IEEE ограничивается определением внутренних стандартов как средства эффективного унифицированного взаимодействия членов группы проектировщиков при разработке Приложений ПК. Здесь же вводится понятие пользовательских стандартов как внутренних, ориентируемых (и это главное!) на класс задач, решаемых Приложениями ПК.
 

В прошлом видел сообщения представителей западных фирм, осваивавших некоторый инструментарий, например, Delрhi или Programmer-2000 (Oracle) для разработки собственных Приложений ПК: `Первое и необязательно второе Приложение (комплекс программ) мы еще программировали, а уже 3-е и последующие попросту собирали (как в детском конструкторе, прим. автора)` – понимай из подготовленных в процессе разработки первых одного-двух Приложений пользовательских стандартов для решаемого фирмой класса задач. Даже встроенные в существующие Генераторы Приложений (1С, FinExpert , Мегаполис и др.) стандарты электронной документации, оперативного и бухгалтерского учета нельзя считать достаточными, ибо они как правило ориентированы на задачи куда более широкого класса, чем решаемые в конкретном предприятии. В их среде можно и нужно разрабатывать пользовательские стандарты, ориентированные на конкретный класс решаемых Вами задач. См. пример таких пользовательских стандартов в среде 1С v7 для взаиморасчетов пользователей Теплосети с коммунальным предприятием
 

Пользовательские Стандарты. Что это

 Как и в детском конструкторе Пользовательские Стандарты – суть законченный набор агрегатных информационных и программных модулей – блоков с унифицированными интерфейсами, позволяющих собирать Приложения ПК определенного класса с минимумом затрат (вплоть до 0-я) на программирование. В процессе сборки производится статическая (до запуска Приложения) настройка агрегатных модулей – их параметров единым (для всех модулей) образом в самом модуле , либо, что еще лучше, в некоторой одной четко определенной области Приложения. Еще важнее возможность динамической настройки (перенастройки) параметров агрегатных модулей - в процессе функционирования Приложения, часто достигаемая записью их значений виде выражения на языке самого инструментария, например, Paradox или 1С.
  Пользовательским стандартом может быть и инфологическая структура Приложения (конфигурация), например, принятая как некоторая классическая конструкция из различных разделов системотехники: таблица решений, абстрактный автомат, потоковая функциональная машина и мн. др. В отличие от этого Генераторы Приложений позволяют пользователю собирать собственную конфигурацию Приложения на соответствующем языке (1С), доступную (Метаданные 1С) пользовательским стандартам (их модулям). Основной путь получения пользовательских стандартов – унификация как основных технологических функций Приложения, в т.ч. вычислительного и информационного характера (включая операции с БД), так и средств диалога пользователей с автоматизированной системой. Унификация технологических функций, упрощая деятельность подразделений и сотрудников предприятия при росте их эффективности чаще всего приводит и к необходимости соответствующей реорганизации их деятельности.
  В современных объектно-ориентированных системах (например, Delphi или Мегаполис) для этой цели предусмотрены механизмы построения пользователем собственных видов и классов объектов из набора встроенных объектов среды. Но даже с их отсутствием в средах 1С (v7 и v8), Paradox и даже броузера Internet (IE, Opera и др.) без каких-либо дополнительных надстроек и систем можно создавать эффективные пользовательские стандарты технологии сборки Приложений введением настраиваемых образцов экранных форм, событий с их элементами и процедур обработки событий; образцов QBE-и SQL-запросов, форм отчетов и модулей. Все эти среды вычисляют значения параметров настройки, задаваемые выражениями, например, eval(выражение) Javascript броузеров Интернет, шаблон(выражение) в 1С. Все они могут размещать эти параметры в динамических массивах, БД, XML-файлах (броузеры) или MXL-таблицах (1С). Все обладают средствами генерации запросов на поиск, выборку и изменения как собственных данных (Local SQL, XML для броузера), так и удаленных (remote) обращениями к SQL-серверу
 

 

Пользовательские Стандарты. Собственный опыт

    

Эпоха Paradox 3.5-4.5

 

Этот опыт более 80% фирм США мы пропустили, не считая сомнительного опыта части предприятий машиностроения. Изначально ориентированный на обычного экономиста и инженера Paradox 4.5 (3.5) вызвал у меня восторг наличием потрясающих свойств:

• Высочайший уровень унификации с программированием на всех уровнях, включая генерацию экранных форм, форм отчетов и даже QBE-запросов
• Механизм связных экранных форм с событиями и методами их обработки – средство эффективного интерактивного управления многоуровневой БД
• Разнообразные события, включая нажатие клавиш и таймер, программирование имитации событий, методы – процедуры обработки событий и потоки событий
• Встроенный язык QBE – запрос от данных (таблиц) к связям и формулам, а не наоборот, как в SQL и потому куда более эффективный в обработке даже сегодня при минимуме использования ресурсов ПК с Windows
   
  

и еще мн.др.
 
  Все это делало среду Paradox идеальной для размещения в ней не только пользовательских стандартов, но и на их основе Генераторов Приложений ПК для различных классов задач.
 

Генератор многопользовательских Приложений ПК

При проектирования уже первых Приложений в среде Paradox был получен Генератор его же Приложений задолго до появления версии v7 1C и во многом сходный c ней, Конечно, это был далеко не аналог 1С (нет объектов `периодический`, `календарь`, `Счет`, такого мощного сервиса) и вместе с тем были решения, превосходящие возможности 1С, например:
 

• Вводились этапы Приложения и для каждого из них собственные объекты электронной документации, меню, панель управления с кнопками, инструкции (аналог `Помощи` 1С) и даже столешница (фон или заставка экрана) с оперативными инструкциями на ней
   
• Справочники, документы и журналы НЕ нужно было вызывать посредством меню или панели управления: для каждого этапа: они размещались стопкой (как в жизни) на столешнице – один над другим в виде всплывающих окон (аналогично Windows) с заголовками в рамках окон. Их исходные размеры, положение на столешнице и порядок в стопке – параметры описания конфигурации этапа
   
• Этап Приложения мог вызвать другой этап и документация столешницы первого сохранялась автоматически, так и их текущие положение и размеры на столешнице, порядок в стопке, текущие строки и колонки. При возврате управления вызвавшему этапу эти документы (справочники и журналы), их положение, размеры и текущие на столешнице восстанавливались
   
• Одновременная редакция документа (журнала, справочника) несколькими пользователями. Попытка редакции одной и той же записи (строки) вторым пользователем блокировалась с сообщением второму имени первого захватившим запись. Редакция документа (справочника) допускала вставку записей (строк). Допускалась (параметр документа) и авторизация каждой записи ее создавшим и блокирование редакции такой записи другим пользователем
   
• Документы (таблицы и экранные формы) фактически находились в буферном пуле (оперативная память) и потому быстродействие в их обработке и доступе было максимальным. Вместе с тем в конфигурации для каждого документа можно было указать параметры (тайм-аут, частота обращения по записи), вызывающие автоматически сброс данных документа (его DB-таблиц) на винчестер
  
   

Не простой для программирования своевременный сброс изменений таблиц буферного пула на винчестер выполнял автоматически пользовательский стандарт, в отсутствие которого и (тогда еще!) средств защиты ПК от сбоев по электропитанию ЦКБМ БМЗ вынуждено был отказаться от Paradox в ряде задач.

 

Многопроходный бухгалтерский калькулятор обработки формы 20 опытного производства

В каждом из цехов Николаевского ЮжМаш’а (Украина) бухгалтер заполнял строки формы 20 по каждому этапу выполнения заказа опытным производством, исходя из затрат на изготовление и материалы. Форма состояла из массы колонок – граф, заполняемых поочередно каждая построчно очередным проходом из данных норм и значений предыдущих колонок в той же строке и/или их итогов (Сумм) . Научно-исследовательское отделение предприятия в течение 3-х лет безуспешно пыталось автоматизировать решение этой задачи на ЕС ЭВМ, затем СМ-1640 (малая ЭВМ) и, наконец, ПК. Анализ выявил следующие причины провала этих решений:

• Разработчики НЕ заметили, что операции бухгалтера с формой 20 фактически повторяются при каждом очередном ее проходе – поочередном просмотре строк формы с заполнением очередной графы (колонки) формы. - Отличия только в формулах, используемых для вычисления значения, заполняющего графу. Наиболее трудоемкой для бухгалтера операцией являлось вычисление значений распределением суммы (итога) по строкам одной из предыдущих граф (предыдущих проходов) пропорционально значениям одной из уже заполненных. Операция завершалась коррекцией погрешности распределения, вызванной округлениями значений, заполняющих графу (колонку)
   
• В перестройку чуть не ежемесячно менялись не только нормы, включая общегосударственные, но и их структура, как и использование в вычислениях затрат по форме 20
   
• Форма 20 уже не отвечала новым требованиям перестройки и ее приходилась разрезать, вклеивая дополнительные строки, дополняя на обороте и т.д.
  
   

Потому объем автоматизирующих заполнение формы 20 программ был велик и их попросту НЕ успевали корректировать при постоянных изменениях в организации норм. Эту проблему и задачу удалось решить в 3 недели, разработав в среде Paradox классический многопроходный бухгалтерский калькулятор со следующими возможностями:

• Форма 20 приняла на экране и в БД (таблицы) тот же вид, что и бумажный аналог, но куда более унифицированный и легко раздвигаемый (разрезаемый) – вставка строки между двумя и с возможностью изменять состав, свойства и имена граф (колонок) самим пользователем. – `Практически на все случаи жизни!` – реакция главбуха предприятия
   
• Для каждого прохода в сходной с формой 20 таблице Paradox (классическая таблица решений) бухгалтер получил возможность для каждой графы записывать выражениями (формулы) любое количество операций по ее заполнению вместе условием выполнения операции (классическая таблица решений). В формулах в качестве аргументов использовались (исходные) имена граф – их значений в той же строке или их итоговые (по всем строкам) суммы, вычисляемые автоматически в предыдущих проходах. Помимо мощного набора элементарных функций и функций статистики языка PAL (Paradox) вводилась единственно указанная выше операция распределения. (пользовательский стандарт) итоговой суммы любой предшествующей колонки (графе) пропорционально текущим значениям другой колонки
   
• В реализуемый Paradox калькулятор встроил (пользовательский стандарт) произвольно вводимую и корректируемую самим пользователем систему норм иерархической структуры: от государства (верхний уровень) до участка цеха (нижний уровень). Бухгалтер в формуле таблицы решений указывал только имя нормы и ее значение выбиралось автоматически как имеющееся (не пустое) на самом нижнем уровне иерархии норм
   
• Количество проходов (просмотров) формы 20, как и операций в них определяла сама бухгалтерия
  
   

`Теперь обойдемся без бухгалтеров в цехах и даже без программистов` – реакция главбуха. - Мне пришлось заполнить лишь часть начислений при опытной проверке, а дополнили их сами бухгалтера. Запуск калькулятора в эксплуатацию был произведен без каких-либо помех и обращений ко мне. Время всех проходов формы 20 для любого заказа не превышало 1-2 минут на ПК Intel/386

Решение задач АСУ на ПК реляционными методами

Это едва ли НЕ единственный метод переноса сложных задач АСУ с мэйнфреймов (больших ЭВМ) на ПК с ограниченной архитектурой Intel: он позволяет в десятки раз увеличить быстродействие Приложений ПК переносом нагрузки с винчестеров на оперативную память и процессоры эффективной организацией буферного пула СУБД при обработке БД потоком запросов (SQL, QBE). Наконец, СУБД может для выполнения запросов использовать параллельно несколько процессоров (ядер процессора) современного ПК.
  Практически все используемые сегодня Базы Данных (БД) на ПК являются реляционными. Проблемой для наших программистов является проектирование БД, предметным образом отображающих не только развивающую структуру реального объекта (например, производства), но и логические отношения – сути (содержания) автоматизируемых функций. Эту проблему можно ослабить пользовательскими стандартами, эффективно по быстродействию – запросами в языке SQL (или QBE) выполняющих:

• Разузлование узлов и деталей
  
• Распределение значения по строкам таблицы (или подмножества ее строк) пропорционально значениям некоторой ее колонки с исправлением погрешности распределения из-за округлений вычисляемых значений распределения
  
• Поиск дублей наборов значений в строках таблицы
  
• Интерполяция, экстраполяция и мн.др.
  
  

Опыт такого решения потрясающими и поныне средствами Paradox для MS DOS (поток генерируемых QBE-запросов) в классической задаче комплектации изделий поступающими на сборку деталями и узлами смотрите в Интернет и печати – журнал `Компьютер+Программы`, Киев, 1995, №5 (1-я обширная статья с примерами QBE-запросов из задачи).
  Применение методов реляционной алгебры (поток QBE-запросов) потребовало пересмотра не только алгоритмов решения задачи, но и классических математических методов, применяемых при оптимизации планов сборки. После уничтожения отраслевых институтов Горбачевской перестройкой, возможно, я остался последним держателем (архив на CD) этой классической задачи для любого производства дискретного типа изделий (машиностроение, авиастроение, легкая промышленность и др.)

 

Генератор многопользовательских Приложений в Delphi

 

В 2000 году, занимаясь поиском подходящей готовой системы электронной документации (стандарты) на сети ПК ТеплоКоммунЭнерго, разработал простейший генератор многопользовательских Приложений в Delphi + SQL-2000 и даже опробовал его в ряде задач. В отсутствие навыков создания в Delphi собственных видов и классов объектов поступил аналогично разработчикам 1С: построил пользовательские стандарты справочников, документов и их указателей (журналы) – структуры SQL-таблиц, их экранных форм и в них стандарты предопределенных – с фиксированными именами процедур (методы) обработки событий, включая поиск значения в колонке, ввод и редакцию строк, права доступа пользователей. В отсутствие объектов оперативного и бухгалтерского учета, сервиса 1С здесь были и определенные преимущества:

 

• Справочник, документ и журнал могли быть не только SQL-таблицей, но и результатом многотабличного SQL-запроса, завершающегося (выход) операцией SELECT
  
   
• Документ для редактирования автоматически копировался в локальную БД – таблицу Dbase или Paradox, редактировался там в соответствующей экранной форме (конфигурация) с подчиненными ей формами справочников из локальной или SQL-БД. По окончании редакции документ копировался (возвращался) обратно в SQL (remote) БД
  
   
• При обработке и редакции документа в локальной БД использовался Local SQL
  
   
• Событий с соответствующими стандартными методами (предопределенными процедурами) их обработки было значительно больше, в т.ч. таймер, включение и выключение режима редакции, нажатие клавиш, в отличие от 1С безусловная отработка методами начала и окончания каждого события
  
   
• При запуске печати описание (шаблон) экранной формы автоматически трансформировалось в описание формы отчета для той же таблицы (табличная часть документа, справочника, журнала) с учетом выполненных до печати изменений `Мышкой` ширины колонок документов на экране вплоть до 0 (пропуск колонки при печати) или их перестановки
  
   

Пользовательские стандарты в 1С

 

Необходимость интеграции имеющихся стандартных Приложений 1С (после привязки) бухгалтерии и отдела кадров с основной службой – абонентским отделом ТеплоКоммунЭнерго (взаиморасчеты с клиентами) вынудили уже в среде 1С v7 разработать собственные пользовательские стандарты, обеспечивающие требуемые производительность (в 2-3 минуты начисления сотне тысяч клиентов), надежность и эффективность диалога - производительность операторов абонентского отдела.
Вместе с тем приведенные там концепции БД 1С v7 и Архива взаиморасчетов с клиентами ориентированы на использование реляционных методов с еще более эффективной обработкой групповыми операциями 1C v8 – запросами к БД, сходными по структуре с SQL

 

Пользовательские стандарты для КПК

 

Такие стандарты опробовались на КПК с Windows Mobile 5 и 6 для торгового агента фирмы оптовой торговли: выбор товаров с ведением остатков и картинок (проспект), выписка счетов (накладных) на объектах клиентов с корректировкой остатков товаров. Первый вариант системы использовал броузер IE5 с freeware персональным WEB-сервером и БД типа MDB (CDB для КПК). Затем аналогичное решение только средствами броузера Opera 9.5.1 для КПК (9.2 для ПК) или IE без каких-либо дополнительных программ. В Opera локальные хранилища данных отсутствуют и в качестве БД (Остатки товаров, Счета) используются eболее 50 тысяч cookiе для указанных версий Opera. В случае IE БД на cookie Opera моделируется локальным хранилищем IE5 и выше. Для хранения справочников (клиенты, товары), описаний Счетов и их указателей, параметров пользовательских стандартов (включая Меню) используются файлы XML с древовидной структурой. Приложение отрабатывается на ПК и затем в том же виде без каких-либо изменений переносится в КПК. Предусматриваются утилиты для переноса данных остатков товаров из 1С в КПК и выписанных Счетов обратно. В процессе выборки товаров в Счет визуально индицируется итоговая Сумма по Счету. В формах диалога учитываются даже такие явления как `дребезг` стилуса на экране КПК. План (по дням недели) обхода клиентов сокращает затраты на формирование Счетов и выборку клиентов. Подробнее см. темы от patrick (login) в форуме `Ладошки`

 

Пользовательские Стандарты. Зачем

 

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

 

• Разработчики Приложений ПК сосредотачивают внимание на автоматизации технологических функций, отвлекаясь от деталей программирования и тонкостей инструментальных систем – повышение качества автоматизации технологических функций
  
   
• Совершенствование пользовательских стандартов – основной путь повышения качества использующих их Приложений ПК и квалификации программистов
  
   
• Эффективное разделение труда между теми, кто создает и развивает пользовательские стандарты, и теми, кто их применяет для сборки Приложений ПК
  
   
• Использующие одни и те же пользовательские стандарты Приложения ПК обеспечивают минимум затрат на их эксплуатацию, интеграцию и развитие
  
   
• Возможность обойти ограничения и ошибки сложных инструментальных систем, в том числе приводящие к сбоям в работе Приложений
  
  

P.S. Для получения более подробных сведений, включая готовые конфигурации Приложений ПК и КПК, обращайтесь по E-mail patrickeev@mail.ru