Компьютер в бухгалтерском учете и аудите 1999'3

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Бухгалтерский счет — начало начал

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

Оказывается, что если в случае “ручного” учета можно ответить: “Самую разнообразную”,— то при проектировании автоматизированных систем управления (иначе, корпоративных информационных систем), выбор структуры счета может оказывать самое непосредственное влияние на функциональность системы, ее быстродействие, удобство пользовательского интерфейса. Авторы считали, что уже давным-давно сама жизнь дала ответ на этот вопрос. Как вдруг оказалось, что вновь и вновь открываются дискуссии о преимуществах того или иного подхода, пользователи задают разработчикам недоуменные вопросы: “А почему у Вас сделано так, а не иначе?” Если есть вопросы, то ничего не поделаешь — надо давать ответы, отмалчиваться нельзя. Поэтому у нас возникло желание публично изложить свои взгляды на эту, только кажущуюся второстепенной, проблему.

Еще до появления первых автоматизированных систем на западе завоевал популярность подход, при котором номер счета учета представлял из себя довольно длинную последовательность чисел (кодов), условно разбитую на части (сегменты). Первый из сегментов представлял из себя, собственно, номер счета в привычном нам понимании, второй — номер субсчета, далее шли сегменты, каждый из которых представлял собой аналитический шифр того или иного уровня. В дальнейшем мы будем называть такое описание бухгалтерского счета сегментированным. Среди всех систем сегментированных описаний можно было выделить две разновидности — назовем их условно “позиционная” и “ограничительная”. В случае ограничительной системы каждый сегмент такого составного бухгалтерского или управленческого счета учета отделен от предыдущего каким-нибудь ограничителем, например, точкой. Получается нечто, схожее с <счет>.<субсчет>.<аналитический шифр1>.<аналитический шифр 2> и т.п.

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

СССССААААБББВВВВВВВ,

где С - позиции в номере счета/субсчета, а А, Б, В — аналитика 1,2 и 3 уровней соответственно.

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

Сразу же можно сказать, что позиционная система обладает существенными недостатками по сравнению с системой ограничительной. Если мы окажемся непредусмотрительными, изначально определяя размер того или иного сегмента, то со временем у нас могут возникнуть большие проблемы. Например, мы отвели 4 позиции на аналитику по контрагентам, а в результате массовых отгрузок физическим лицам у нас оказалось больше 10 000 партнеров. Для того чтобы расширить сегмент, нам придется менять структуру множества бухгалтерских счетов, а это в общем и целом — солидные трудозатраты. Для сегментной системы в общем случае этой проблемы не существует. Кроме того, мы считаем, что “читабельность” у ограничительных счетов гораздо выше, чем у счетов позиционных. Это уже вступают в силу законы зрительного восприятия.

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

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

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

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

Но не стоит забывать, что основная масса отечественных пакетов программ для автоматизированного бухгалтерского и управленческого учета начала создаваться гораздо позже, чем западные. К этому времени уже были ясны недостатки сегментированного подхода (мы поговорим об этом ниже), поэтому большинство из них (“1С”, “Галактика”, “Инфин”, “Компас — Комфорт”, “БЭСТ” и др.) взяли на вооружение иную тактику описания счетов. Тактика эта у приведенных выше продуктов во многом отличается, но всех их объединяют общие базовые принципы. Заключаются они в следующем.

В поле “номер счета” записываются только номера синтетического счета и субсчета в российском нормативном понимании этих слов. Иногда даже вводятся два отдельных поля для счета и субсчета. Часто для синтетического счета вообще не выделяется отдельная запись Плана счетов. Данные по нему собираются из нескольких субсчетов. В этом случае каждая строка соответствующей таблицы представляет собой субсчет.

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

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

Таким образом, при описании новой проводки пользователь в момент ввода аналитики первого уровня увидит в качестве подсказки название соответствующего справочника. Из этого самого справочника программа будет загружать и перечень значений для выбора. Выбранное значение будет занесено в журнал хозяйственных операций (ЖХО) в качестве аналитики к счету учета. Точно так же вводятся и все остальные аналитические признаки — ровно столько, сколько отведено в Плане для данного счета/субсчета.

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

Справочники аналитических шифров можно описывать по-разному. В классическом варианте реляционной аналитики (“1С”, “БЭСТ”, “Парус” и др.) пользователь сам может создавать произвольные справочные таблицы и присваивать им коды, разработчики и знать не знают, да и знать не хотят, какую аналитику будет вводить пользователь. По партнерам? Пожалуйста!!! По научно-исследовательским темам? Нет проблем!!! Пользователю предоставляются богатейшие возможности построения индивидуальной системы учета с помощью недорогой типовой программы. Эту же произвольность допускает и сегментированный подход, но... По сравнению с реляционным описанием этих “но” не так уж и мало!

Второй разновидностью реляционной аналитики является подход, когда все возможные аналитические справочники заранее определены разработчиком. Пользователь может только выбирать нужный код из ограниченного авторами ПО набора. В этом случае разработчик также определяет поля первичных документов, связанные с этими же аналитическими кодификаторами. В результате при описании проводки в таблице ЖХО вообще могут отсутствовать отдельные поля для аналитических шифров к счетам. Шифры вычисляются алгоритмами расчета результатов “на лету”, а данные для этого берутся из упомянутых полей первичных документов. Такой подход был применен при разработке пакета “Компас — Комфорт”.

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

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

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

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

Итак, сначала поговорим о тех недостатках сегментированного подхода, которые привели, на наш взгляд, к появлению реляционной аналитики.

Во-первых, в любом Плане Счетов в зависимости от конкретного номера счета могут присутствовать два варианта аналитического учета. Первый из них — иерархический, когда одна разновидность аналитики зависит от другой. Например, анализируя расчеты с поставщиками по 60 бухгалтерскому счету, мы сначала рассматриваем всех контрагентов (уровень 1), а уже внутри каждого контрагента - конкретный договор на поставки (уровень 2).

Второй вариант предполагает полную независимость нескольких разновидностей шифров друг от друга. Например, для полноценного учета основных средств (ОС) часто бывает необходимо анализировать состояние 01 счета по видам ОС и материально ответственным лицам (МОЛ). Эти справочники в общем случае никоим образом не связаны.

Комбинирование двух данных вариантов при сегментированном описании затруднено, а в реляционной схеме все алгоритмы обработки создаются элементарно!

Давайте рассмотрим все ту же ситуацию с основными средствами. Пусть нам требуется вести аналитический учет по следующим уровням:

  1. Виды ОС (здания, сооружения и т.п.) — для сбора формы № 5 и баланса;
  2. Материально ответственные лица (МОЛ) — порядка ради;
  3. Номенклатура ОС.

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

А теперь, собственно, проблема.

Когда бухгалтер совершает очередную операцию движения ОС (например, выбытие), целесообразно в виде подсказки отображать ему на экране все виды ОС, всех МОЛ, но только те объекты ОС, которые относятся к выбранному МОЛ. Иначе неизбежны ошибки, ведь номенклатура ОС на больших предприятиях огромна, а наименования ОС в справочнике номенклатуры вводятся пользователем скупо и разнообразием особенно не отличаются. Поэтому выбрать из двухсот “бетономешалок” те, что относятся к данному МОЛ — задача не столько пользователя, сколько программы.

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

Что же нам дает реляционная аналитика? Виды ОС и МОЛ описываются как простые линейные справочники, для справочника номенклатуры указывается, что “родительским” справочником является справочник МОЛ. В результате, при вводе данных в справочник номенклатуры программа сначала запросит код МОЛ, потом отобразит фильтр справочника номенклатуры по выбранному МОЛ, а для всех вновь введенных объектов установит значение кода “родителя”, равное коду выбранного МОЛ. Кстати, многие разработчики такой схемы предусмотрели даже два вида нумерации в подчиненном справочнике: сплошная для всех или сплошная внутри “родителя”. Сегментированная аналитика таких возможностей предоставить не может. А ведь это не только удобство ввода информации, но и скорость!

Во-вторых, сегментированный подход ведет к жуткому разбуханию Плана счетов. Представьте себе: как только у Вас появляется новый партнер, который может являться и поставщиком, и потребителем, Вы должны не только описать его реквизиты в справочнике, предназначенном для быстрой подготовки первичных бухгалтерских документов, но и внести в План записи, описывающие новые подвиды как минимум 60, 61, 62 и 64 счетов. На скорость занесения проводок в базу данных такая необходимость тоже влияет далеко не самым лучшим образом.

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

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

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

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

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

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

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

Многие разработчики, использующие реляционную аналитику, справились с этой задачей. Так, в программе “ИНФИН” оператор может выбрать вид справочника:

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

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

Следующее преимущество реляционной системы проявляется при разработке аналитических отчетов. Допустим, для 01 счета мы определили аналитику: группы ОС (уровень 1), МОЛ (уровень 2) и номенклатура ОС (уровень 3). При сегментированном подходе сформировать отчет по 01 счету “от сгруппированного к детальному” мы сможем только в последовательности, установленной выше. Ведь фактически мы, сканируя шаблон счета, не сможем оценить, является ли какой-либо из уровней аналитики подчиненным другому уровню. И, соответственно, определить, не является ли нумерация элементов подчиненного уровня несплошной.

Конечно, можно написать алгоритм и для другой последовательности (МОЛ-> группы ОС -> номенклатура ОС), но это будет достаточно сложно и привязано к настройкам каждого счета в отдельности. То есть разработчик заранее определит зависимость уровней аналитики отдельного счета и именно для него построит алгоритм.

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

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

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

Наконец, последний недостаток сегментированных счетов снова связан с составлением отчетов, но уже в так называемом “сквозном” или управленческом варианте.

Предположим, что надо собрать полный отчет по всем нашим взаимоотношениям с партнером Х. Понятно, что сведения эти могут быть разбросаны по самым разным счетам и субсчетам. Например, 60/01 — расчеты по отфактурованным поставкам (здесь может быть задана аналитика и по партнеру, и по номеру счета-фактуры), 60/02 — неотфактурованные поставки, 61 — авансы выданные и т.д.

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

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

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

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

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

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

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

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

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

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

Справедливости ради мы должны заметить, что эти недостатки не являются неотъемлемыми свойствами классического подхода. Они вполне преодолимы! Просто не всем разработчикам это пришло в голову. Например, если авторы системы предусмотрели, что пользователь может редактировать шаблон ввода данных о документе, то любой элемент ввода может быть описан в виде “ТАБЛИЦА->ПОЛЕ”. В результате, если ТАБЛИЦА описывает классический справочник, программа сможет его использовать и при формировании документа, и в процессе разноски по бухгалтерским счетам.

Еще один способ преодоления недостатков “классики” заключается в комбинировании классического и эвристического вариантов, примененном, например, при разработке пакета “Компас + SQL”.

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

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

Схожая идеология была реализована и в программе “Инфин”. В ней первые 19 справочников являются эвристическими, а все последующие — классическими. Это позволяет использовать первые 19 справочников как в специализированных модулях (например, “Документы”), так и в специальных расчетах.

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

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

Гл. эксперт ООО “Компас”,
к. т. н. Игорь Якобсон

Специалист департамента
информационных технологий
компании “Русаудит” Алексей Смирнов

Copyright © 1994-2016 ООО "К-Пресс"