Экономия своими руками

Когда проводят презентацию новой системы, связанной с IT областью, часто рассказывают о таком параметре как «стоимость владения», сопровождая обязательным словом «низкая». Обычно если об этом говорят, то это значит, что стоимость покупки сильно завышена, а производитель не сомневается в том, что его технология не потребует больших затрат на сопровождение. По большому счету это не самый плохой выбор.

Не знаю, как по этому параметру оценивают Navision. В этой статье я дам несколько советов, как снизить стоимость владения или просто сэкономить на покупке объектов в Navision применяя вполне легальные методы. Хочу обратить внимание на то, что речь идет о методах, которые позволяют решить проблему экономии средств на закупку дополнительных объектов Navision (таблицы, формы, отчеты) и не всегда эти методы будут самыми производительными по скорости выполнения или будут простыми по способу реализации.

Временные данные

Как правило, для хранения временных данных используются временные таблицы. Стандартное и вполне разумное решение, для любой СУБД. Но в Navision нет возможности создать временную таблицу произвольной структуры. Часто приходится сталкиваться с тем, что временная таблица не имеет всех необходимых полей для хранения данных. Кроме того вводит в заблуждение то, что в поле временной таблицы с именем, например «Код Товара», хранится значение не имеющее ни какого отношения к этому коду т.к. в исходной таблице нет поля с подходящим названием, типом и что самое плохое нужной длины. Так что, для хранения временных данных нужно покупать новую таблицу? Нет, не наш метод.

Попробуйте использовать XML. Причем советую использовать не стандартне для Navision XMLPort, а COM объект ‘Microsoft XML, vXXX’. У вас открывается возможность создать объект произвольной структуры, не привязанной к табличным ограничениям Navision. Если Вы планируете хранить несколько тысяч значений во временной таблице, то работает это также быстро, как и временная таблица. Ключевые значения советую хранить как узлы XML. Тогда можно быстро обращаться к нужной записи.

Заманчивыми является следующие возможности. В одном XML можно хранить несколько временных таблиц одновременно. Можно реализовать массив/список с произвольной глубиной, это то, что вообще нельзя сделать в Navision. Можно сохранять временные данные в файл, что в частности позволяет упростить отладку. Можно создать замену постоянно глючащему fin.zup и сохранять необходимые настройки в XML. В приложении к статье приведен пример как, используя XML создать интерфейс хранения в стиле ini файла.

Долгосрочное хранение

Как быть в случае, если нам нужно создать таблицу для длительного хранения информации? Давайте купим таблицу в Navision? Нет, не наш метод.

Попробуйте использовать ADO. Создайте таблицу в SQL сервере нужной структуры и заполняйте ее данными, используя стандартные команды INSERT, UPDATE и т.д. Советую так поступать для тех случаев, когда Вам необходимо хранить логи доступа или логи использования тех или иных объектов или их состояний. Как правило, в таких случаях Вам нужно только добавлять в таблицу логов данные, что очень просто сделать. Но ни в коем случае не думайте, что я Вас пытаюсь ограничить только этими задачами, дерзайте и ищите другие возможности по использованию ADO.

Пример:

Создаем таблицу в SQL

В Navision создаем функцию для хранения логов
AddSQLLog(MessageText : Text[1024])

Еще  ADO

Пример необычного использования ADO из реальной практики. Всем известно что, при учете документов в Navision возможен учет только одного документа в один и тот же момент времени. При большом количестве пользователей/документов учет превращается в кошмар белых экранов и длительных блокировок. Радикально решать задачу нужно на уровне учетных функции, но специалисты Navision/Micrososoft на протяжении всех версий даже не пытаются этого делать. Давайте хотя бы уберем белые экраны и покажем пользователю счетчик попыток учета. При этом в реальной очереди блокировки будет находиться один пользователь.

Проверьте наличие представления [Session] в Вашей БД. Если его нет, то создайте:

Предоставьте пользователю, через которого вы будете подключаться к SQL серверу право на просмотр этого представления.

Затем в Navision создайте функцию:

ПроверкаБлокировки(МаксПопыток : Integer) Result : Boolean

Данную функцию следует вызывать перед самой передачей документа в codeunit учета,  до того как возникнет  блокировка учета.  Как это работает:

Пользователь 1 запустил учет. Т.к. блокировки нет, он будет учитывать документ.

Пользователь 2 запустит учет. Т.к. блокировки нет, он запустит учет и будет ждать пользователя 1. Зависнет учет на первой строке документа. Количество блокировок 1.

Пользователь 3 видит окно с сообщением «Проверка возможности учета ХХХ» до тех пор, пока  пользователь 1 будет блокировать учет пользователя 2, либо не закончится счетчик попыток учета. Пауза между проверками случайным образом будет варьироваться в диапазоне от 0 до 1000 мсек. Когда пользователь 1  закончит учет пользователь 2 начнет учет, а пользователь 3 станет за ним в очередь учета. У меня количество попыток учета 500.

Замечу, что такой подход бережёт ресурсы сервера, т.к. сокращается количество блокировок, которые являются достаточно ресурсоемкими.

Универсальный справочник

У меня всегда вызывает раздражение тот факт, что в Navision считают, что для отображения бизнес информации достаточно тех справочников, которые изначально там присутствуют. Если Вам нужно классифицировать товар по способу хранения, то где хранить справочник способов хранения? Если клиенты делятся по каналу реализации, то где хранить справочник каналов реализации? Причем замечу, что  работа несложная, но нужно купить таблицу, форму для каждого справочника. Давайте Купим! Нет, не наш метод.

Как быть. Тут нам придется принять тот факт, что в справочники нужно вносить изменения, а значит, необходима форма. Когда будем разбираться с тем, как можно сэкономить на формах, то у Вас, возможно, она появиться без особых проблем. А вот таблицу нам придётся купить. Но не стоит покупать столько таблиц, сколько справочников нам нужно сейчас или возможно понадобиться в будущем. Давайте ограничимся одной таблицей и одной формой.

Начнем со структуры таблицы.

Универсальный справочник

Первичный ключ справочника «Тип строки», «Код». Это гарантирует нам уникальность введенных значений. Если значения справочника нужно сортировать каким-то уникальным способом, то в другие поля можно добавить поле «Сортировка» и создать еще один ключ «Тип строки», «Сортировка», «Код».

Теперь делаем форму.

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

Для передачи информации о том какой справочник нужно показать можно использовать фильтр который передаётся при вызове формы. Например, при вызове через lookup.

onLookup()

В форме на onOpenForm нужно добавить показ колонок:

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

Формы

Показ одной формой данных из разных таблиц

Этот метод хорошо подойдет для справочников. Если у вас есть много таблиц с разной справочной информацией, то не обязательно создавать разные формы для разных справочников.  Можно использовать одну форму и временную таблицу, куда можно загружать разные данные. Этот метод подходит и для показа информации из разных источников (ADO,XML и т.д.). Только вот проблема будет с выбором временной таблицы. Она должна иметь достаточно большое количество полей для показа разнообразной информации.

Тема использования временной таблицы в форме  хорошо освещена в данном источнике http://naviart.ru/temp-subform-source.

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

Разработка новых документов

Обязательно настанет день, когда у вас появиться задание на создание нового документа в Navision.  Давайте посчитаем, сколько таблиц и форм нужно использовать по стандарту:

• Четыре таблицы – заголовок неучтенных документов, строки неучтенных документов, заголовок учтенных документов, строки учтенных документов
• Шесть форм – список неучтенных документов, список учтенных документов, шапка неучтённого документа, шапка учтенного документа, субформа неучтенных строк , субформа учтенных строк.
• Таблица движений – нужна если документы должны изменять состояние учета.

Открываем прайс и считаем, сколько стоят все эти объекты. Давайте купим! Нет не наш метод.

Зачем нам отдельные таблицы для учтенных и неучтенных документов?  Есть мнение что хранение в разных таблицах улучшает производительность . Вполне корректное утверждение. Но ведь есть еще такая замечательная возможность SQL сервера как секционирование, т.е. разделение большой таблицы на несколько частей. Если количество Ваших документов станет очень большим, то Вы можете разделить таблицу на секции, не изменяя код Navision отвечающий за заполнение таблицы или извлечение из нее данных. Причем сделать это можно именно тогда, когда большая таблица будет существенно влиять на скорость работы. Кстати советую секционировать такие таблицы как неучтенные документы продажи.

Итак, вместо четырех таблиц можно использовать две.  Предположим, нам нужно создать несколько разных документов в рамках одного проекта. Например, учет тары. Нужно ли создавать новые таблицы для каждого вида документа. Скорее всего, нет.

Заголовок

Один совет, если в таблице будут храниться разные типы документов, то секционируйте таблицу по типам документов. Секционировать по учтенным/неученным  документам в таком случае нецелесообразно.  Соответственно поле «Учтен» не нужно включать в первичный ключ. Булевы поля в индексах не самое лучшее решение.

Строки

Т.к. у нас нет разных таблиц для учтенных и неучтенных документов, то мы сразу же можем сократить количество форм до трех: Список документов, Заголовок документа, Субформа строк документа. Это же позволяет нам сократить количество печатных форм документа.

Давайте сначала посмотрим на список документов.

Разделение по типам документа лучше всего реализовать через передачу параметра в форму. Создайте в форме глобальную переменную:

Создайте функцию

SetDocType(pDocType:integer);

Теперь нужно отфильтровать при открытии формы

onOpenForm()

Для корректного вызова формы с нужным типом документа нужно объявить переменные и вызов функции SetDocType()

onPush

Если пользователю нужно отдельно показывать учтенные и неучтенные документы, то можно добавить параметр «Учтен» в функцию SetDocType() и переделать OpenForm.

Теперь давайте посмотрим на карточку документа.

Нам необходимо запретить редактирование учтенных документов

OpenForm()

Как быть, если у разных типов документов должны быть показаны разные поля. Как правило, в рамках одной задачи поля одинаковые у разных типов документов. Но бывают поля, которые характерны только для одного типа документа. Например, в списании тары – тип списания.  Сначала в заголовок формы нужно добавить все поля и изменить OpenForm()

Не забудьте изменить свойство Name=”ТипСписания” у того объекта, который хотите скрыть/показать.

В строках документа Вам, возможно, нужно будет скрывать/показывать разные поля для разных типов документов. Делается это также как и в заголовке только для столбцов субформы.

Шапка документа и субформа. Две формы или одна?

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

Создайте форму для строк документа. Объявите глобальную переменную:

Установить все необходимые фильтры в OpenForm() для показа одного документа, например:

OpenForm()

Если планируется редактирование заголовка, то в событии onCloseForm добавьте

Добавьте в форму объект закладки и прижмите его к верхнему краю. Табличную часть разместите ниже. Добавьте в закладки поле для редактирования. В свойстве SourceExpr укажите ЗаголовокДокумента.ПолеДляРедактирования.  Откомпилируйте форму.

Теперь откройте форму. Успех? Вроде да. Однако при изменении в заголовке документа Вы увидите, что после повторного открытия формы содержимое заголовка и строк не изменилось.

Нужно вызвать Validate() поля. В событии onValidate() поля редактирования нужно написать

onValidate()

Компилируем. Редактирование приводит к желаемому результату. Теперь изменения вносятся в заголовок, и отрабатывает последующий код.

Но как же без ложки дегтя. Проблема в том, что у заголовка нет объекта xRec, т. к. транзакция не начата. Это означает что если в Validate поля, которое Вы редактируете, есть конструкция вида:

То система ничего не сделает т.к. Rec  и xRec одинаковы.

Что можно сделать? Есть два варианта:

• Исключить сравнение Rec  и xRec в коде Validate  как таковое
• Если, все таки, этого не избежать, то
  • Выделить сравнение в отдельную функцию
  • В заголовке формы создать временную таблицу «xЗаголовокДокумента:Record “Заголовок”;» в которую записывать копию заголовка при открытии формы
  • Передавать в функцию сравнения ЗаголовокДокумента и старую копию заголовка для корректного сравнения данных.

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

Самый простой способ экономить в печати — использовать Excel. Я думаю каждый способен выбрать для себя как лучше всего его использовать . Кто-то будет писать прямой код, кто-то использует Query объект, кто-то шаблоны.  Я использую все три метода в зависимости от типа задачи.

С точки зрения экономии объектов Report  наиболее перспективной является печать документов. У меня в Navision для печати накладной документов продаж используется три отчета: Печать неучтенных продаж/кредит-нот,  Печать учтенных продаж, Печать учтенных кредит нот. Если бы в Navision не было деления на учтенные и неучтенные таблицы, то и проблем бы не было. А так с точки зрения администрирования это полный кошмар. Нужно добавить новую колонку, изменить текст, подвинуть поле — нужно вносить изменения в три отчета, в которых еще и некоторые переменные и поля названы по разному.

Зачем нам три отчета для печати одного документа, даже если источники данных разные? Нужно сразу делать один отчет. Отчет должен базироваться на временных таблицах.  Я использую временные таблицы на основе неучтенных документов и копирую в них печатаемые документы как учтенные, так и неучтенные. Таким образом, вместо трех отчетов я получаю один.

Однако все равно остается проблема  добавления/удаления колонки в секциях Navision.  В том же документе продажи у меня 21 секция для печати разных вариантов строк.  Поэтому следующим этапом становиться печать документа в Excel с использованием шаблона.Это уже не предмет изучения данной статьи.

В качестве примера как во временную таблицу скопировать разные типы документов приведу пример функции:

Приложение

XML

Идея в том, чтобы имитировать работу в стиле ini файла как в Delphi используя  XML в качестве хранилища данных. В тему этой статьи: достаточно быстро данный код можно переделать для временной таблицы.

В любом доступном объекте создайте глобальную переменную

Это объект для хранения XML файла. Его нужно правильно инициализировать и удалить с помощью следующих функций:

tXML_Init()

tXML_Free()

Добавляем функции для работы с ключами:

tXML_KeyCount() result : Integer

tXML_KeyExists(Key : Code[30]) result : Boolean

tXML_AddKey(Key : Code[30])

tXML_DelKey(Key : Code[30])

tXML_GetKeyByIndex(Index : Integer) Key : Code[30]

tXML_FieldCount(Key : Code[30]) result : Integer

И еще функции для работы со значениями:

tXML_FieldExists(Key : Code[30];Field : Code[30]) result : Boolean

tXML_SetField(Key : Code[30];Field : Code[30];Value : Text[1024])

tXML_GetField(Key : Code[30];Field : Code[30]) result : Text[1024]

tXML_DelField(Key : Code[30];Field : Code[30])

tXML_GetlFieldByIndex(Key : Code[30];Index : Integer) Field : Code[30]

И функции для сохранения и чтения файлов:

tXML_SaveToFile(FileName : Text[512])

tXML_LoadFromFile(FileName : Text[512])

Функцианальность можно наращивать в зависимости от необходимости.
Пример использования: