Комбинация search ta .. и [jf..] как эквивалент форм-историй



Posted by Анатолий Анимица on November 17, 1999 at 12:21:44:

In Reply to: Eсть такая функция - [JF ...]. posted by Аpкадий Водяник on November 15, 1999 at 22:20:38:

Информирую всех коллег и посетителей wwwboard, что я еще неделю буду на a@secom.lg.ua, куда можно направлять свои вопросы.
Этот - об аналогах форм-историй - очень интересен. Здесь на wwwboard неоднократно дискутировался отказ от ta-фактов в пользу собственных механизмов. "Проприетарных", как по-научному выражаются некоторые наши уважаемые гости и посетители. В моей практике реализации практических систем было все, в том числе и полная замена ta-фактов как описателей проводки собственными описателями - в частности, именно из-за отстуствия компонент текста операции, например, комментария, в факте ta. Но после реализации функции [jf..] все встало на свои места. Теперь нет нужды изобретать собственные факты (типа entry - очень удачно предложенные Сергеем Васеленко) и тщательно следить за корректностью их генерации в собственных моделях операций - ветвях дерва и т.п.. Все берет на себя сервер при описании проводок. Простая проводка порождает факт ta dt,sd,sk,kt,ea,m3, где dt - счет или субсчет дебета, sd sk - соответственно сумма дебета и кредита, kt - субсчет кредита, ea - результат проводки в дебетуемомом счете, m3 - штамп операции.
Если теперь в любой отчетной форме выполнить rewind facts range t1,t2 (t1,t2 - интервал дат), затем search ta x1,x2,x3,x4,x5,x6 (где x1..x6 могут приобретать разные уазанные или ?уn или даже ?? значения) и по [success] отыскивать компоненты операции, используя [jf 'o key='+m3], можно построить полный аналог формы-истории с незначительными ограничениями. Every operation не реализуется для тех операций, которые не содержат ни одной ненулевой проводки - зато и не нужно фильтровать null и скобки {} . Далее. Нужно понимать, что в extrd.dat по индксам [ged jf..] хранятся компоненты операции примерно так, как их режет на строки UltraH в представлении журнала - кусками байт по 80 или около того - и нужна конкатенация этих кусков для создания полного текста операции. Кроме того, длина текста операции может превысить 256 байт, т.е. одной строковой переменной мало, нужен или массив или резерв трех-четырех, с запасом, переменных. После этого создание любых форм немыслимой красоты не составляет труда. Возможны различные фильтры - текстовые и логические, в фильтрах можно применять И, ИЛИ, Запрет (И - И НЕ ), Стрелку Пирса (НЕ-ИЛИ) и более сложные логические выражения, причем в ряде случаев их программирование можно делегировать диалогу пользователя и самой отчетной формы, т.е без операторного или процедурного программирования формы пользователем. Помещение штампа операции в первые восемь байт строки формы (или девять байт - с учетом вериткальной черты таблицы) - дадут возможность выхода в журнал операций просто по Enter в клиенте - с последующим редактированием, просмотром проводок или выводом первичного документа - и все это без торможения сервера запуском второй машины проводок, т. е. очень быстро.
С уважением
Ваш ААА



Пpишедшие ответы: