Журнал LinuxFormat - перейти на главную

LXF100-101:Ананас

Материал из Linuxformat
Перейти к: навигация, поиск
Ананас

Документы и печатные формы

ЧАСТЬ 4 Завершая цикл статей, посвященных платформе Ананас, Андрей Паскаль покажет, как создавать учетные документы и выводить их на печать при содействии OpenOffice.org.

Как известно, в автоматизации учетной деятельности и бизнес-процессов принято выделять два методических подхода: «от первичных документов к операциям» и «управление процессами». Программная система, реализующая первый подход, обслуживает потребности пользователя, главным образом, по формированию и учету необходимой документации, как правило, регламентированной. Программные системы, реализующие второй подход, выстраиваются под потребности системы управления организацией, помогая управляющему персоналу держать под контролем качество выполнения бизнес-процессов сотрудниками организации в соответствии с принятым нормами и стандартами. По данной классификации, Ананас относится к системам первого типа, в которых учет строится на регистрации учетных событий в документах. Поэтому разработчику бизнес-схемы необходимо уметь определять документы, их экранные и печатные формы. Учетные документы — это отправная точка, источник данных, на котором строятся все прочие операции, осуществляемые Ананасом.

(thumbnail)
Рис. 1. Вызов диалога создания нового документа.
(thumbnail)
Рис. 2. Диалог создания нового документа.
(thumbnail)
Рис. 3. Создание нового реквизита шапки документа.
(thumbnail)
Рис. 4. Задание свойств реквизита Номер документа.
(thumbnail)
Рис. 5. Реквизит Продавец имеет сложный тип данных.

Как всем известно с детства, «чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное», поэтому мы рассмотрим проектирование бизнес-объекта Документ на примере документа Приходная накладная, который используется при постановке на учет приобретенных товаров.

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

Первым шагом создадим новый документ, вызвав для этого соответствующий диалог, как показано на Рис. 1, и зададим название «Приходная накладная», как показывает Рис. 2. Описание вводить не обязательно, однако, это удобное место, чтобы оставить послание тому, кто решит когда-нибудь исправить созданный вами документ. И даже если это будете вы сами, через, скажем, года два, это все равно будет другой человек, так как через такое время вы уже с трудом вспомните суть деталей проекта двухгодичной давности. Если вы сможете сжато и доходчиво объяснить назначение и контекст жизни документа, обязательно сделайте это. Сегодня ничто так не дорожает, как время. Хорошие комментарии экономят его.

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

Определим атрибут Номер, указав тип данных Символ(100), как показывает Рис. 4. Закроем диалог и аналогично определим атрибуты Дата, Продавец, Основание, задав типы данных Дата, Справочник контрагентов, Символ соответственно. Получилось? Разумеется, невозможно задать тип данных Справочник контрагентов, пока его еще нет. Это я говорю для тех, кто пропустил предыдущие уроки, где мы как раз и занимались его созданием. Им следует сделать паузу в работе над Приходной накладной и заняться Справочником контрагентов, как объясняется во второй статье цикла (LXF98). Однако, сейчас не обязательно полностью переключаться на Справочник контрагентов, достаточно создать его, указав название. Определение реквизитов контрагентов можно оставить и на потом. После создания Справочника контрагентов полю Продавец можно будет, наконец, задать тип Справочник контрагентов, что демонстрирует Рис.5.

Дела табличные

(thumbnail)
Рис. 6. Реквизиты шапки и табличной части документа определены.

Задав реквизиты шапки документа, определим состав столбцов таблицы, в которую будет заноситься информация по товарам.

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

/**
* Вызывается при изменении значения в ячейке таблицы с именем tname
*/
function on_tabupdate(row,col,tname)
{
// только для таблицы wDBTable1. wDBTable1 - имя таблицы,
// задаваемое в дизайнере, а не имя в метаданных
if(tname!="wDBTable1") return;
// подсчет суммы и запись ее в поле «Сумма» таблицы
var newValue = parseFloat(TabValue(tname,row,1))*parseFloat(TabValue(tname,row,2));
SetTabValue(tname,"Сумма", row, newValue);
}

Функция on_tabupdate(row, col, tname), является зарезервированной служебной функцией Ананаса. Если разработчик бизнес-схемы определит в модуле экранной формы документа или другого бизнес-объекта функцию с таким именем и с таким количеством параметров (имена параметров могут быть любыми), то она будет вызываться всякий раз, как только пользователь изменит значение любой ячейки таблицы экранной формы. Такие функции принято называть обработчиками событий. Самым очевидным применением обработчика on_tabupdate является расчет вычисляемых значений типа поля Сумма или Сумма по документу.

Важный момент, связанный с табличным представлением данных в документе, который следует осознать до начала использования таблиц — это возможность определения в документе более одной таблицы. Ананас не ограничивает количество табличных частей у документа, проектируемого разработчиком бизнес-схемы. Документ может не содержать ни одной табличной части, как например, платежное поручение, или содержать одну, две и более табличных частей. Честно говоря, мой скромный объем знаний состава первичных документов различных участков учета не помогает мне вспомнить хотя бы один вид, где бы потребовалось больше двух табличных частей. Но видимо, разработчики Ананаса решили не ограничивать запас страховки и в этом случае.

Таким образом, перед определением первого реквизита табличной части документа необходимо создать эту табличную часть.

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

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

Твердая копия

(thumbnail)
Рис. 7. Вид шаблона печатной формы Приходной накладной.

Подсистема подготовки печатных форм (отчетов) Ананаса использует хорошо известную методику с использованием шаблонов. Суть ее заключается в создании готового документа при помощи соединения шаблона документа, задающего форматирование и оформление, и данных, обработанных и подготовленных специальным образом для вписывания в шаблон. Такой подход хорошо себя зарекомендовал тем, что обеспечивает поддержку большого количества различных форматов. Например, Ананас с одинаковой легкостью может формировать отчеты в форматах TeX, HTML, XML. Какой формат выбрать, решает разработчик бизнес-схемы. В бизнес-схеме, поставляемой в дистрибутиве Ананаса, используется формат документов OpenOffice.org, как наиболее дружественный и удобный для пользователя, привыкшего к работе с OOo.

Рассмотрим возможности Ананаса по работе с отчетами с точки зрения разработчика бизнес-схемы. С точки зрения пользователя, отчет или печатная форма документа — это просто документ, открытый Ананасом либо в редакторе Writer, либо в электронной таблице Calc пакета OpenOffice.org.

Для разработчика бизнес-схемы подготовка к формированию отчета складывается из двух составляющих: подготовки шаблона отчета и написания кода, команды которого формируют отчет из шаблона и данных.

Формирование печатной формы осуществляет Ананас-Скрипт на основании имеющихся в его распоряжении данных и шаблона отчета. Шаблон отчета представляет собой документ OpenOffice Writer, с занесенными в него тегами специального формата. Процедура на Ананас-Скрипте подменяет теги значениями, оставляя неизменным стилевое оформление, заданное для тега. Рис. 7 показывает шаблон приходной накладной. Каждый тег в документе начинается с пары символов <: и заканчивается парой символов :>, между которыми указывается имя тега. Его-то и использует Ананас-Скрипт при формировании отчета.

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

/**
* обработчик нажатия кнопки
*/
function on_button(button_name)
{
if(button_name!="print_button") return; // обрабатываем только нажатие кнопки Печать
var p = new Report("Report1","1"); // создаем экземпляр отчета
p.setTable("templ_prihod.odt"); // связываем его с шаблоном
// шаблоны ищутся в каталоге 'Рабочий каталог'
p.setValue("param",Value("Номер") ); // устанавливает значение для простого тега
p.exec("Документ.Номер"); // применяет установленное значение для тега с именем <:Документ.Номер:>
p.setValue("param",Value("Основание") );
p.exec("Документ.Основание");
p.setValue("param",Value("Продавец"));
p.exec("Документ.Продавец");
p.setValue("param",Value("Дата") );
p.exec("Документ.Дата");
var sum=0;
var countRow = TabCount("wDBTable1"); // количество строк таблицы
var i;
for ( i =countRow-1; i>=0; i--)
{
p.setValue("npp", String(i+1)); // устанавливаем значение табличного тега с именем 'npp'
for ( j=1; j<=5; j++)
{
p.setValue("f"+String(j), TabValue("wDBTable1",i,j-1));
}
p.exec("table_section"); // применяем установленные значения для строки
//содержащей табличный тег [:table_section:]
}
sum = Value("lineEdit1");
p.setValue("param",sum);
p.exec("Итого");
p.setValue("param", Propis(sum)); // записываем сумму прописью
p.exec("Итого_прописью");
p.setValue("param","Сидоров С.С");
p.exec("Сдал");
p.setValue("param","Петров П.П");
p.exec("Принял");
p.setValue("param",getConstant("Константы","Главный бухгалтер")); // получаем имя главного бухгалтера из справочника констант
p.exec("Организация.Главбух");
p.show(); // запускаем OpenOffice
p.close(); // удаляем все временные файлы
}

Этот код следует поместить в модуль экранной формы Приходной накладной. Он сработает только если:

  • Была нажата кнопка, для которой в дизайнере экранных форм было задано имя print_button.
  • Шаблон Приходной накладной, показанный на Рис. 7 хранится в файле templ_prihod.odt, расположенном в рабочем каталоге. Рабочий каталог задается в параметрах настройки бизнес-схемы.
  • Названия справочников и полей совпадают с указанными в коде.

Внимательный читатель уже самостоятельно заметил наличие в шаблоне странного тега с прямоугольными скобками [:table_section:]. Такой тег нужен для таблицы. Так как в шаблоне определяется только одна строка таблицы, а в сформированном документе их может быть произвольное количество, необходим тег, который позволил бы программе понять, что эту часть шаблона следует рассматривать как размножаемую строку. Имя тега можно выбирать произвольно — важно лишь то, чтобы и в шаблоне, и в коде оно было одинаковым.

Более детальное описание возможностей и способов работы подсистемы формирования отчетов Ананаса следует искать в фирменном руководстве. Самый быстрый и качественный ответ на практически любой технический вопрос по этой теме всегда можно получить на форуме проекта Ананас. Дерзайте!

В чем сила, брат?

«Вот в чем сила!» – просто не может не воскликнуть любой программист, впервые увидев, какой мощный арсенал готовых, качественных и, что самое главное, хорошо знакомых пользователю инструментов ему предоставляет мир свободного ПО для реализации его идей в форме потребительских программных продуктов. Ярчайшим примером подобного случая является пакет офисных приложений OpenOffice.org, точнее сказать, его доступность. Ни один проприетарный продукт не может рассчитывать в отношениях пользователей к себе на такой уровень лояльности, который имеет OpenOffice.org среди пользователей и разработчиков. Создатели Ананаса, входя в их число, смогли максимально воспользоваться всеми преимуществами этого пакета программ, интегрировав Ананас с OpenOffice.org в настолько удобной для пользователя форме, что порой он даже не замечает и не задумывается над тем, что подготовленный в Ананасе счет или накладная открываются для печати в редакторе Writer или в электронных таблицах Calc из пакета OpenOffice.org. Такая интеграция стала возможной благодаря открытости форматов файлов этого офисного пакета. Формат ODF, используемый программами пакета OpenOffice.org является сегодня стандартом, утвержденным ISO, международной организацией по стандартизации.

Персональные инструменты
купить
подписаться
Яндекс.Метрика