Управленческий учет. Автоматизация учета и управления в малом и среднем бизнесе

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

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

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

В первом случае, например, групповая операция начисления зарплаты, выглядит так (персональные данные замаскированы):

Начисление зарплаты группа 4 операции

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

Проводки операции группы

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

Коллаж – групповая операция, проводки и первичный документ

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

Программно-техническая платформа

Программно-технически весь комплекс управленческого учета организуется в некоторую базу данных (БД), обслуживаемую системой управления БД (СУБД), наделенной семантической функциональностью (моделью ХС) и средствами связи (интерфейса) с внешним по отношению к БД миром – например, компьютерной сетью, в которой работают рабочие станции (РС), исполняющие программы на стороне пользователя – клиенты СУБД и модели управленческого учета ХС.

Для практической реализации систем управленческого учета мы очень давно, более 30 лет, используем платформу бухгалтерской программы «Финансы без проблем» ФБП [4,5], имеющую классическую архитектуру «клиент-сервер» и позволяющую очень быстро строить УС самого разного назначения и масштаба – от системы управления для единственного пользователя на одном компьютере до глобальных сетей ЭВМ, связанных через Интернет. Программная платформа ФБП, «Финансы без проблем», была создана по сути одним человеком – Аркадием Водяником из Мариуполя26.

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

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

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

На рисунках показаны экраны работающих программ сервера и клиента ФБП. Сегодня вычислительные возможности компьютеров позволяют одновременно запускать на одном сервере до сотни отдельных учетных систем и обслуживать несколько сотен удаленных пользователей – клиентов. А использование WEB интерфейса и современных браузеров позволяет обеспечить практически не ограниченный, в том числе публичный, доступ к такой системе.

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

Сервер «Финансы без проблем» на 20 имен пользователей, база 2023TSTZ, апрель 2023 года

Клиент «Финансы без проблем», пользователь S, сервер 2023TSTZ, журнал операций

3. Управленческий план счетов

Управленческий план счетов как основа классификации хозяйственных событий. Взаимосвязь бухгалтерского и управленческого плана счетов

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

План счетов бухгалтерского учета

Используя метод двойной записи, для предприятий в РФ рационально положить в основу управленческой системы План счетов бухгалтерского учета финансово-хозяйственной деятельности организаций (утвержденный приказом Минфина РФ от 31 октября 2000 г. N 94н)27.

Чрезмерное усложнение Плана счетов может быть причиной ненадежности учета, поэтому в нашей практике выработано ограничение детализации плана счетов всего двумя уровнями – счет и субсчет. То есть в ФБП и в наших управленческих системах отсутствуют объекты аналитического учета типа конто и субконто28 1С.

Аналитика должной детализации обеспечивается включением дополнительно к балансовым счетам внебалансовых счетов, которые могут иметь, а могут и не иметь остатков на субсчетах и играть просто роль аналитических справочников. Кроме того, присвоение как балансовым, так и внебалансовым счетам любого множества экстрапараметров намного более гибко и полно описывает состояние элементов управленческого Плана счетов. Можно сказать, что План счетов бухгалтерского учета является балансовой областью Плана счетов управленческого учета на платформе ФБП.

Фрагмент «управленческой» части плана счетов

План счетов управленческого учета

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

На рисунке показан фрагмент «управленческой» части плана счетов учета системы для промышленного предприятия.

Видны счета номенклатуры ТМЦ SKLAD (3429 позиций), списка складов SKLADS (48 позиций) и ряда других, частично в данной учетной системе не используемых (железнодорожные станции и их коды, например, не используются в конкретно этой системе, поэтому станций в плане нет, но виден единственный «зародышевый» субсчет для поддержания единой функциональности системы. Когда будет необходимо, план счетов будет дополнен кодами и названиями станций и им можно будет сразу пользоваться.

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

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

Даже в том предельном случае, когда на особо малом предприятии и диспетчерскую, и ремонтную службу несет один единственный шофер с одним или двумя автомобилями в гараже.

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

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

Классификация и группировка хозяйственных операций. Принцип раздельного описания атрибутов операций и их вычислимых результатов. База знаний системы управленческого учета

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

Впервые этот термин в программном продукте «из коробки» применила фирма «Хакерс Дизайн» в 1990 или 1991 году и он тогда имел этот же смысл, затем термин и подход подхватил «Турбо-бухгалтер», «1С», «Инфин» и многие десятки других бухгалтерских продуктов большей или меньшей распространенности.

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

Состав записи операции

Операция ТМЦ приход

Типовая операция – оприходование ТМЦ, товарно-материальных ценностей. Она начинается с группового заголовка «ТМЦ приход», затем следует (в наших системах) указание на организацию, к которой относится данная операция, то есть она трансформированном иде потом попадет в учетные системы бухгалтерскую и налоговую организации -POLY, уточнение вида операции tmcpr03 задает способ, как именно приходуются данные ТМЦ (товары, материалы, малоценные предметы и т.п.), далее указывается склад приходования SK421, код поставщика 6050363 (здесь каждая позиция кода может иметь определенный смысл, что позволяет ориентироваться в списках из тысяч поставщиков), регистрируются номера счет-фактуры 0141220-МСК и товаро-транспортной накладной 1301/03, затем указывается количество =1 и сумма = 12262 рубля, в том числе НДС 20%, после чего следует номенклатурный код ТМЦ 4Е8000443 и фрагмент его наименования. Завершает операцию комментарий 0141220-МСК// 1301/03, метка оператора L, штамп времени регистрации операции 1601105541 и уникальный код операции AAAA-201.

Оператор L, который зарегистрировал операцию, не обязан знать ничего о том, как именно система управленческого учета поступит с записанной информацией. А система, в свою очередь, автоматически вычислит управленческие счета, участвующие в операции, определит суммы проводок по оприходованию стоимости ТМЦ без НДС на балансовый счет (товаров, материалов или иного вида ТМЦ), выполнит проводку оприходования НДС на чет НДС приобретенные, запишет поступление данного ТМЦ на склад, добавит данный склад в список «а где еще есть такой вид ТМЦ», если склада не было в этом списке, создаст запись в книгу покупок и журнал учета счетов-фактур полученных, то есть выполнит заодно все действия, которые требуются для налогового учета. И как итог – сформирует приходную накладную, первичный документ операции.

Остается задача сохранения оригинала документа поставщика, на основании которого производится регистрация прихода. Сегодня наиболее рациональным способом является создание скана или фотоснимка документа и сохранение этого скана там же на сервере со ссылкой на место хранения и имя единицы хранения, совпадающее с штампами операции его регистрации. В данном случае код хранения – L-1601105541-AAAA-201. Сам бумажный документ может быть отправлен в защищенное хранилище физических документов, а вся дальнейшая работа происходит с каталогизированным собранием электронных копий.

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

Дата совершения и дата регистрации операции

Дата регистрации операции в системе может совпадать с датой совершения описываемого ею события, а также быть выполненной раньше или позже.

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

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

Точно так же, если необходимо обеспечить запись некоторой последовательности завершающих период (день или месяц, например) операций, такую последовательность можно пометить признаком «в конце дня», и она автоматически будет помещена после последней операции дня очереди «в общем порядке», как будто завершающие операции действительно регистрировались позже.

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

Дерево видов операций

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

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

Хозяйственная операция содержит определенное количество параметров и атрибутов, которые задаются ответами на вопросы при регистрации операции. Порядок следования вопросов задается деревом видов операций.

Фрагмент дерева видов операций – Финансы, рубли приход и расход

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

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

В существующих сегодня версиях ФБП ребер первого порядка – до 15, к каждому ребру первого порядка может быть присоединено тоже до 15 ребер второго порядка, и так далее.

Два порядка ребер задают, таким образом, до 15х15=225 первичных классов и подклассов операций, и на практике большее количество пока не потребовалось.

Ребро (в дереве ФБП принято название «ветвь») может быть абсолютным, то есть его можно только выбрать при создании операции, а может быть ветвью-вопросом, образуя в поле ввода место, куда можно поместить некое вводимое значение. Оно может быть ведено с клавиатуры, или с другого устройства ввода (например, со сканера штрих-кода), или выбрано из списка, который предлагает встроенная в ветвь программа, и так до крайней вершины цепочки ветвей, которая образует путь формирования операции.

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

Крайняя ветвь заканчивается «листом», концевой группой записей дерева, которая задает проводки – двухместные операции вида Дт-Кт-сумма (обобщенная), то есть счет дебет – счет кредит – число.

Обычно здесь находится не число или ссылка на число, а программа на языке ФБП, так называемый файл-коэффициент (название историческое, отражает возможность записать туда некий множитель суммы операции, которая задается в явном виде вне дерева. Сейчас эта форма практически не применяется).

Файлы-коэффициенты – это файлы вида FCXXXX. RPT, где XXXX – буква, цифра или иной допустимый в имени файла символ. Имена мнемонические, что облегчает их отыскание и распознавание.

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

Фрагмент списка файлов-коэффициентов (примерно 10% списка) одной практической системы приеден на рисунке, он позволяет оценить охват множества хозяйственных операций, которые регистрируются в системе.

Кроме файла-коэффициента, в листе дерева может присутствовать еще один файл – программа создания первичного документа, которая присоединяется к паре фиктивных (не существующих в Плане счетов) субсчетам create и document. Аналогично файлам-коэффициентам первичные документы имеют имена файлов программ PDXXXX. RPT. Их в общем случае меньше, так как не каждая операция требует создания первичного документ.

Фрагмент списка файлов-коэффициентов

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

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

Отличительной особенностью систем на платформе ФБП является открытый программный код, позволяющий пользователям самостоятельно углублять и развивать свои знания и возможности используемой системы.

5, Рациональная структура

учетной системы (УС)

Технические средства. Серверы, рабочие станции, сети, клиенты, пользователи и их коллективная работа

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

Коллективная работа в УС

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

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

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

Архитектура клиент-сервер

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

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

Надежнее, если все данные УС будут находиться на сервере, а клиентское ПО будет обмениваться с ним данными по запросу только в течение сеанса. Такое клиентское ПО называется «тонким клиентом» – в отличие от ПО с полной функциональностью, как, например, сделано в 1С, когда на клиентских машинах открывается по несколько сотен файлов базы данных и часто с их копированием – репликацией – на клиентский ПК.