Исходя из этого появляется желание каким-то образом автоматизировать работы по контировке первичных документов и формированию проводок. Понятно, что нельзя "намертво" "зашить" в программу такие алгоритмы, поскольку постоянно меняются и нормативы и правила расчета. Кроме того, при едином плане счетов каждое предприятие может вести свою уникальную систему субсчетов. Таким образом, необходимо отделить правила построения операций от программы таким образом, чтобы пользователь мог самостоятельно настроить эти правила, а программа их правильно проинтерпретировать.
Реализуя идею построения системы, основанной на понятии "хозяйственная операция" разработчики "Хакерс Дизайн" нашли чрезвычайно привлекательное интерфейсное решение. После записи определения операций в специальной базе знаний, называемой "деревом операций", их ввод в базу данных минимизирует общение пользователя с клавиатурой. Как мы уже видели ранее, ввод операции осуществляется выбором нужных пунктов из последовательно предлагаемых меню. Единственное что нужно ввести - это число текущего месяца и сумму операции, а дальше автоматическую генерацию необходимых проводок и расчет их сумм сделает программа. При этом из выбираемых пунктов меню как бы конструируется фраза, отражающая суть выполняемых действий. После ввода сведений о совершенной операции всегда можно просмотреть проводки, которые построила программа.
К достоинствам внутримашинного хранения бухгалтерских записей в виде операций, подразумевающих проводки, а не самих проводок, следует отнести тот факт, что в этом случае в значительной степени снижается трудоемкость исправления ошибок. Например, какая-то сумма вместо того, чтобы быть отраженной как использование прибыли, была отнесена на общехозяйственные расходы, а потом включена в себестоимость. В этом случае скалькулированная себестоимость оказывается неверной, а вслед за ней неверным окажется расчет прибыли и налоговых платежей. При использовании традиционного для систем автоматизации представления информации в базе данных в виде проводок, многие из них придется удалить, для того чтобы, исправив допущенную ошибку, полностью повторить расчет и выполнить повторный ввод пересчитанных данных. В случае же использования операций, только подразумевающих проводки последние будут автоматически переформированы при изменении лишь одной ошибочной операции.
Другим примером автоматических пересчетов является оценка себестоимости продукции при учете материалов по средним ценам. Предположим, мы провели оприходование нескольких партий материала, скалькулировали среднюю цену единицы и на ее основе оформили бухгалтерские записи по списанию в производство. Потом выяснилось, что при вводе данных о приходе была допущена ошибка и, тем самым, средняя цена была определена неверно, что повлекло за собой неверное определение включенных в себестоимость сумм. При ручном счете или использовании бухгалтерских программ, основанных на традиционном подходе, придется исправлять ошибки по всей цепочке или формировать сторнирующие записи и "проводить" все заново. В случае же использования "Финансов без проблем" ошибку надо будет исправить только в одном месте, а все зависимые вычисления будут проделаны автоматически.
Неспроста уже несколько раз в этой книге проводилась аналогия с электронными таблицами. Бухгалтерские расчеты выполняемые "Финансами без проблем" на основе записи операций также отличаются от расчетов программами, построенными "от проводки", как расчеты с помощью электронных таблиц от расчетов с использованием карандаша и калькулятора. В последнем случае достаточно допустить одну ошибку в исходных данных, чтобы последующие результаты и все выписанные на бумагу цифры были неверными. Совсем другое дело, когда мы ввели в клетки электронной таблицы формулы, определяющие порядок наших расчетов. В этом случае достаточно исправить неверные исходные данные, а всю остальную работу программа выполнит автоматически.
Такое свойство "виртуальности", "перевычисляемости" проводок, положенное в основу "Финансов без проблем" как нельзя кстати может пригодиться именно в нынешних условиях, когда из-за ввода нормативных актов в действие задним числом бухгалтерам приходится выполнять двойную работу по выполнению самых разнообразных перерасчетов. Счастливым пользователям "Финансов без проблем" часто просто не надо их делать! Достаточно внести изменения в определение операций, затрагиваемых такого рода законодательными актами, а все остальное сделает программа.
Еще одно "за" концепцию оформления бухгалтерских записей в виде операций состоит в том, что правила контировки могут быть описаны опытным бухгалтером один раз, а потом ввод может осуществляться простым оператором, поскольку процесс "машинного" оформления операций состоит в ответе на простые вопросы программы, "конструирующие" фразы, отражающие содержательный смысл операции и уже заложенные в базу знаний. Таким образом, вероятность ошибиться становится меньше и главбух может использовать свое время более рационально, чем тогда, когда ему приходилось контролировать правильность контировки документов за малоопытными подчиненными.
Однако, такое построение программы, при всех его достоинствах, таит в себе немало подводных камней. Неумелое переопределение некоторых операций может автоматически вызвать процесс полного пересчета результатов по всем действиям, совершенным до этого момента. Поэтому к построенным определениям правил надо относиться чрезвычайно "бережно" и осторожно, особенно если по этим правилам зарегистрировано много операций. Вот почему так важна продуманность решений на начальном этапе освоения программы, особенно если Вы собираетесь автоматизировать как можно больше сложных в алгоритмическом отношении расчетов.
"Финансы без проблем" и внешние программы
Настройка программы на выполнение разнообразных расчетов возможна не только на основе использования встроенных средств программирования. Программа имеет достаточно развитые возможности "общения" с внешними приложениями оформленными в виде *.exe и *.com файлов, а также с DLL-библиотеками. Таким образом, программистам предоставляется возможность самостоятельно "усовершенстовать" "Финансы без проблем", адаптируя программу к особенностям использования на конкретном предприятии или в конкретном регионе. Рассмотрение этих возможностей начнем с описания взаимодействия программы с приложениями, оформленными в виде *.exe или *.com файлов. Для вызова внешних программ в языке файлов-форм используется встроенная функция [ru ]. Ее общий формат:
[ru s1,s2,n], где s1 - строка, содержащая имя вызываемой
программы;
s2 - строка с передаваемыми аргументами ;
n - режим восстановления экрана:
0 - очистить, а затем восстановить,
1 - оставить как есть (для тех случаев, когда вызываемая программа ничего на экран не выводит).
Внешняя программа, вызванная функцией [ru ], результаты своей работы должна поместить в первую строку файла RU.TXT.
Рассмотрим следующий пример.
В вариант стандартной поставки "Финансов без проблем" входит файл-формы PLATEZKA.RPT, обеспечивающий формирование первичного документа "Платежное поручение". С помощью псевдопроводки "создать документ" он может быть "пристыкован" к операциям. Однако, каждый раз при формировании документа он заставляет нас вводить банковские реквизиты контрагента. Кроме того, организованный в нем последовательный ввод значений не очень-то удобен. Было бы намного приятнее выбирать необходимые значения из справочника, устанавливающего соответствие кода субсчета, передаваемого в форму, банковским реквизитам контрагента - расчетному счету, МФО и названию банка.
Для решения этой задачи можно использовать следующую простую программу BANK.EXE, написанную на языке СУБД Clipper Summer'87. При ее "сборке" должны использоваться библиотеки clipper.lib, extend.lib и ct1.lib:
parameters FBP_par
* если нет параметров - не работаем
* список параметров должен быть заключен в двойные кавычки
if pcount() = 0
clear
? 'Программа может работать только вместе с "Финансами без проблем"'
? 'Параметры не указаны. Нажмите любую клавишу'
inkey(0)
quit
endif
set scoreboard off
* файл BANK.DBF должен иметь следующие поля
* SUB_SCET - символьного типа, длина 9
* KONTRAG - символьного типа, длина 100
* RS - символьного типа, длина 11
* MFO - символьного типа, длина 10
* BANK1 - символьного типа, длина 50
* BANK2 - символьного типа, длина 50
* длина полей может быть и иной, но тогда надо изменить настройки
* вызова программы функцией [ru ]
* для приведенного в книге примера критична длина полей RS и MFO
* при изменении их в файле BANK.DBF должны быть изменены параметры
* функции [cp ]
* BANK.DBF должен быть предварительно проиндексирован по полю SUB_SCET
use bank index bank
* функция [ru ] должна должна передать программе
* код субсчета, выбранный при регистрации операции и
* название субсчета, разделенные точкой с запятой
subscet = token( FBP_par, ';', 1 )
kontrag = token( FBP_par, ';', 2 )
* ищем запись, относящуюся к данному контрагенту
seek rtrim(subscet)
* если такой записи нет, то добавляем запись с данным кодом и
* наименованием субсчета
if .not. found()
append blank
replace sub_scet with subscet, kontragent with kontrag
do EditRecord
endif
* оформляем экран - функция [ru ] должна использоваться
* с параметром восстановления экрана
set color to n/bg