Новости

Вопрос деноминации продолжает оставаться одним из

наиболее обсуждаемых как среди бухгалтеров, так и среди

разработчиков бухгалтерских программ. На прошедшей неделе

состоялся "круглый стол", посвященный этой теме. Его

организовала корпорация "парус". Разработчики поделились

подходами к решению вопроса и заявили о готовности взять

тяготы переходного периода у пользователей на свои плечи.

Недавно на страницах "фг" мы рассказывали о подготовке

к деноминации, предпринятой фирмой "интеллект-сервис". В

ближайшее время намечается семинар на эту тему, который

проведет фирма "1с-рарус" в зале салона "финансист". Фирма

"комтех+" объявила об адаптации своих программ к решению

вопросов, связанных с деноминацией. Похоже, что фирмы весьма

серьезно подошли к этому вопросу. И, судя по их реакции,

проблем оказалось несколько больше, чем казалось поначалу.

Весь комплекс проблем можно разделить на три большие группы

- организационную, методическую и техническую.

Организационные проблемы.

Темпы распространения автоматизации опережают темпы

развития инфраструктуры, обеспечивающей поддержку поль-

зователей. В результате многие фирмы-разработчики имеют по

нескольку тысяч клиентов и всего несколько десятков слабо

подготовленных дилеров. Для распространения игровых или

обучающих программ это нормально. Но полный переход

бухгалтерий на компьютерный учет требует тесной поддержки со

стороны дилеров. Можно спрогнозировать, что в первые рабочие

недели января тысячи бухгалтеров захотят обратиться к

авторам программ или их представителям. Ни один из

поставщиков не сможет мгновенно решить их проблемы.

Возникнет очередь.

Вот почему "интеллект-сервис" собирается заранее

распространять специальные модули, облегчающие переход. А

"парус" даже разработал план "диспетчеризации",

подразумевающий упреждающий обзвон клиентов с целью

согласования графика встреч, а также нанял дополнительные

группы специалистов на работу в самые жаркие дни.

Методические и технические проблемы.

Любая бухгалтерия построена по общей схеме, но

развивается индивидуально. Разработчики пытаются решить в

первую очередь общие проблемы. А многие нюансы решаются по-

льзователем "полуавтоматически". В повседневной практике это

нормально. Но в переходный период все по-другому.

Автоматизаторы как бы становятся ответственными за все.

Бухгалтеры ждут от них помощи в решении всех проблем, не

только технических, но и методологических.

Инструкции, разъясняющие порядок операций по учету

деноминации, к сожалению, не могут учесть всех возникающих

вопросов. И если инструкция допускает возможность сделать

операцию двумя способами, то автоматизатору приходится, во-

первых, предусмотреть оба способа, во-вторых, рекомендовать

бухгалтеру какой-либо из них.

Технических проблем также немало. Большинство программ

использует понятие основной или базовой валюты. Деноминация

затронула именно эту основу. Интересно, что среди сотен

российских разработок нашлись системы, построенные по схеме,

не предусматривающей такого понятия, как основная валюта.

Все считается в неких "условных единицах", по отношению к

которым все валюты (и рубль в том числе) имеют курс.

Просмотр документа и построение отчета происходят в любой из

валют. Пользователь таких программ в новом году определяет

валюту как "рубль новый" и все. При построении отчета за

произвольный период бухгалтер запрашивает валюту его

построения (доллар, рубль старый, рубль новый). Однако

программ, построенных по такому принципу, немного. А правила

округления младших разрядов, не совпадающие со строгой

математической логикой, заставят и этих разработчиков

сделать определенные доработки.

Переходный период.

Главные проблемы возникнут в момент переходного

периода. Под ним подразумевается время между календарным

окончанием года и моментом его окончательного закрытия в

бухгалтерской отчетности и сдачи в налоговую инспекцию. В

это время бухгалтер работает с документами старого года в

одних деньгах и нового - в других.

Желательно, чтобы при этом остатки на счетах

переводились программой в обе стороны, причем многократно -

из одного учетного периода в другой, как вперед, так и

назад. Самая очевидная опасность - потеря значности.

Деноминировав стоимость некоторого первичного объекта учета,

можно в результате округления потерять последнюю значащую

цифру в результате округления. Обратно восстановить

последний знак будет уже невозможно.

Помимо этого сама процедура деноминации может привести

к ситуации, когда сумма аналитических сальдо не будет равна

деноминированному синтетическому сальдо. Могут возникнуть

сложности в сторнировании. Кроме того, мы не затронули

проблемы расчетных задач. Например, расчет больничных или

начисление износа. Так что разработчики готовятся не зря. Но

ведь, в конце концов, всегда есть запасной вариант - начать

новый год с чистого листа на новой базе или даже новой

программе.

Контактный телефон (095) 281-95-20

e-mail: root@sfin.msk.ru