Выбираем подсистему учета Основных Средств

Как-то мало в нашей печати уделяется внимания вопросам выбора системы автоматизации учета основных средств и нематериальных активов. Конечно, для небольших предприятий с ограниченным набором основных эта проблема не является актуальной. Весь учет имеющихся фондов и ежемесячный расчет амортизации они ведут на основе общей бухгалтерской программы, используя при этом аналитику по бухгалтерским счетам и возможности описания типовых хозяйственных операций. Однако, для промышленных предприятий, владеющих несколькими тысячами станков, автомашин, зданий такой подход уже не представляется возможным. Им необходимо налаживать учет во всей полноте. Тем более, что в корпоративных системах класса MRP-II перечень основных фондов является одним из исходных данных планирования загрузки оборудования (Capacity Resorse Planning).

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

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

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

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

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

В современном ПО все эти подключения дополнительных таблиц также должны быть настраиваемыми.

Пару слов о визуализации самих перечней. В Windows-программе она просто обязана быть иерархической - таковы нынешние принципы графического интерфейса, которые обеспечивают удобство поиска конкретной карточки в перечне. Для ОС и НМА нужны как минимум две иерархии: по структуре подразделений предприятия и по группам/подгруппам основных фондов.

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

Кстати, стоит обратить на то, как работает операция модернизации. Дело в том, что возможны разные алгоритмы ее учета: балансовая стоимость меняется в месяце модернизации, а износ только в следующем; и то, и другое меняется в текущем месяце; и то, и другое меняется в следующем. Неплохо, если программа умеет все это делать.

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

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

И еще о начислении износа. Как мы уже говорили, программа должна правильно учитывать дату перемещения между отделами, МОЛ, балансовыми счетами и распределять износ между "источником" и "приемником", пропорционально приписанному каждому из них количеству дней в текущем месяце. Следует иметь в виду, что в течение одного месяца таких перемещений может быть несколько.

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

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

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

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

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

Теперь о вроде бы несвоевременных проблемах. В современных условиях просто безрассудство - приобретать программу учета ОС, в которой не автоматизирован процесс их переоценки. Пару лет назад эта ежегодная процедура отнимала столько усилий, необходимых для чего-нибудь более полезного! Кто гарантирует нас от нового витка инфляции и новых проблем?

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

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

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

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

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

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

Но наиболее тесно модуль "ОС и НМА" должен быть связан с подсистемой подготовки первичных документов. Во избежание избыточных ошибок, возникающих при двойном вводе, желательно забирать из приходных документов данные с описанием (хотя бы частичным) основного средства, из документов на перемещение или списания - данные о датах движения ОС и т.д. и пр. Впрочем, возможен и обратный вариант связи: по инвентарным карточкам или записям о движении ОС создаются новые первичные документы. Тоже неплохо!

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

e-mail: sensr@kompac.spb.su

Менеджер по PR и рекламе ООО "Компас" Таисия Бойко

e-mail: market@compass.spb.ru