Автоматизация учета

Описание учетных задач

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

Титульное название данного документа может быть любое из следующего ряда: ТЗ, предложение, описание, методика. Лично мне больше нравится последнее, как наиболее точно отражающее суть такого документа и его значимость, как продукта интеллектуального труда в этой области. Сама разработка правильной методики - это обычно довольно трудоемкий процесс со множеством итераций и мозговых штурмов (вместе с заказчиком и без него), являющийся первым этапом в любом договоре автоматизации учета. Стоимость этого этапа обычно составляет 20-40% от суммы договора. Этой цифрой я хотел подчеркунуть исключительную важность этого документа для конечного успеха проекта в целом.

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

Ниже рассмотрим аспекты, правила формирования и состав такого документа (далее МЕТОДИКА). Данные соглашения будут использоваться в следующих статьях учетной тематики.

Таблицы и атрибуты

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

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

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

Правила обработки информации

После описания состава и структуры таблиц, а иногда и параллельно, производится разработка правил и методов их обработки на различных этапах ввода информации. К таким этапам, как минимум относятся следующие: 1) ввод информации в интерфейсе пользователя; 2) ввод информации через импорт данных; 3) создание новой информации обработкой уже имеюшейся; 4) выполнение проводок учетных операций ручных или автоматических; 5) подготовка (сборка и хранение) информации для отчетов; 6) подготовка (сборка и хранение) информации для экспорта.

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

Таким образом, при описании правил обработки информации необходимо однозначно и четко формулировать их, как для режима ВВОДА, так и для режима КОРРЕКТИРОВКИ. Последний термин может быть заменен термином-синонимом ОБНОВЛЕНИЕ, что более понятно для молодого поколения программистов.

При описании правил обработки информации важно также указать момент и условия старта этой обработки. Например: 1) для интерфейса пользователя это вход или выход из поля ввода (формы) 2) для массовых обработок/операций - событие, список, меню, процесс закрытия отчетного периода; 3) для отчетов - старт или финиш сборки, действия пользователя внутри отчета.

Системная информация

В ряде случаев методика и правила обработки информации опираются на заранее определенный набор ЗНАЧЕНИЙ атрибутов, который должен быть всегда в некоторых таблицах и не может удаляться. Это можно назвать постоянным набором (перечислением) неких констант, которые хранятся в строках таблицы под определеным кодом. Другие правила могут требовать использование фиксированных диапазонов значений атрибутов, что тоже имеет право на жизнь. Все это должно быть описано, как начальное заполнение таблиц системной информацией.

В общем случае системная информация в таблицах используется для управления процессами обработки и поэтому должна помечаться определенным знаком или статусом в соответствующей строке, исключающим её случайное удаление или некомпетентное изменение. Например, можно использовать последовательность знаков (*) в конце символьного значения. Если вся таблица содержит системную информацию, её необходимо также пометить знаком (*) и поместить в отдельную группу системных таблиц (справочников) с ограниченным доступом пользователей.

Структура таблиц и виды атрибутов

При описании структуры таблицы перечисляются все необходимые для хранения информации атрибуты и их реквизиты (тип и длина). Указывается связь (если есть) с вышестоящим аналитическим справочником. И, наконец, очень важно отметить ВИД атрибута с точки зрения учетного контекста. Например, для описания структуры оборотов и остатков счета.

Для условного обозначения учетного ВИДА атрибута будем использовать следующие знаки в описании структур таблиц перед именем атрибута:

ПРИМЕР ОПИСАНИЯ:

Справочник "ТМЦ"

Счет 20 "Основное производство"

Хозяйственные операции

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

ЗАМЕЧАНИЕ: Термин "передел" означает многоэтапность в обработке информационной руды. А правильное выстраивание учетной информации по счетам - это и есть создание пластов этой руды, удобной для эффективной её переботки, в т.ч. для отчетов. Если уйти от накопления структурно-сложной информации на счетах и сделать их весьма примитивными, это придется делать виртуально каждый раз перед стартом любых аналитических отчетов (использующих только информацию документов), а второй и последующие переделы информации вообще будут недоступны.

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

В описании схемы проводок любой операций необходимо указать, как миниумум следующие сведения: 1) Назначение (смысл) проводки операции 2) Корреспонденция счетов (субсчетов) 3) Единицы учета конкретных ценностей 4) Документ, его часть или другой источник данных. Желательно также указать событие или момент активации операции. Это может быть проведение документа, пакетный запуск по выбранным документам, закрытие/открытие отчетного периода.

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

ПРИМЕР ОПИСАНИЯ:

Получение поставок и отфактуровка платежей

В графах Дб и Кр указывается полный номер счета включа субсчет (3 и 4 разряд). В графе документ можно описать дополнительные условия выполнения данной проводки или другие тонкости обработки документа или его части. Если здесь указывается только предмет (табл.часть), то имеется ввиду, что проводок порождается столько, сколько строк в предмете для каждого документа.

Учетные документы

Учетные документы являются основным "двигателем" хозяйственных операций. Их состав и описание структуры, включая все предметы (табл.части), если они есть, должны быть полностью описаны в методике. Количество учетных документов должно быть оптимальным, а именно - столько, сколько необходимо для выполнения всех задуманных операций в учетной среде. В принципе, чем меньше учетных документов, тем лучше. Меньше работы по ведению информации пользователям. Ведь каждый документ это отдельное рабочее место со своиим интерфейсом и правилами игры.

ПРИМЕР ОПИСАНИЯ:

Документ "Накладная ПРИХОДА"

Предмет ТМЦ

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

Учетные документы могут иметь одну или несколько печатных форм, а могут вообще не иметь. Печатные формы могут соответствовать установленным законодательством формам, а могут быть любыми необходимыми для внутреннего потребления, например, для управленческого учета. Перечень и образцы печатных форм желательно включить в методику на стадии ранней разработки. Это позволит исключить досадные ошибки и промахи при проектировании базы. А заодно выявить и представить Заказчику некоторые несоответствия между его требованиями. Иногда какая-нибудь печатная форма, возникнув однажды, заставляет существенно переработать структуру и интерфейс базы данных.

Перейти в оглавление статей