Сон в новогоднюю ночь: деноминация и бухгалтерские системы
Андрей Гершун
для АКДИ "Экономика и Жизнь"
--------------------------------------------------------------------------------
Думаю, что деноминация станет, наверное, самой обсуждаемой темой за новогодними столами пользователей и производителей бухгалтерских систем. Им значительно повезло по сравнению с банковскими служащими, которые будут одновременно с деноминацией переходить на новый банковский план счетов, и которым, скорее всего, не доведется спать не только в новогоднюю ночь, но и весь грядущий январь.
Удаление трех нулей - это очень удобно. Несколько лет назад многие бухгалтерские системы были специально переработаны, чтобы обрабатывать большие суммы в рублях. Например, ранее некоторые пакеты отводили всего по 12-13 знаков на всю сумму, включая десятичную запятую. Кое-кто усмехнется, вспомнив, как ему приходилось оприходовать самолет раздельно, как два крыла, фюзеляж и хвост. Кстати и меньших братьев бухгалтерских систем - калькуляторов уже давно "зашкаливало", не говоря о том, что даже обыкновенные бухгалтерские счеты имеют всего по 7 рядов и рассчитаны на суммы не более чем в 10 миллионов.
Опыт деноминации уже есть у многих российских и западных пакетов, которые проводили внедрения за рубежом. Почти все страны Содружества Независимых Государств ввели в течение последних 5 лет свои собственные валюты. По сути это была та же самая деноминация, только сопровождаемая еще и изменением названия валюты (одна лишь Белоруссия обошлась без того и другого). Одной из последних денежных реформ была на Украине, которая прошла в прошлом году, заменив купоны на гривны по курсу 1:100000. Те компании, кто уже разработал технологию проведения деноминации, сейчас имеют "фору". Некоторые западные бухгалтерские системы имели шанс опробовать свои утилиты для деноминации в Польше, когда злотый был поделен на 10000. Но из-за серьезных изменений, вносимых в системы при адаптации к российскому законодательству, утилиты придется серьезно переработать.
Если поделить одно число на другое (даже такое "круглое" и "хорошее", как 1000), то нам придется столкнуться с округлением. В основу алгоритма округления деноминации было положено знакомое школьное правило: "... если при пересчете цен, тарифов, надбавок, наценок и скидок образуются дробные части копеек, сумма должна быть округлена до целой копейки. Если дробная часть копейки менее полкопейки, то она отбрасывается и сумма снижается до целой копейки, а если эта часть равна полкопейке и больше, то сумма повышается до целой копейки." Но оказывается не все так ясно. К сожалению, инструкции не дают ответа на какой счет отнести возникающую в результате округления разницу. Отсутствие ответа, по утверждению разработчиков многих программ, является сдерживающим фактором при разработке утилит для деноминации. Хотя думается, что с точки зрения налоговой инспекции, ответ был бы универсален: "если получается убыток, то отнести на 81-й счет, а если прибыль то на 80-й, лишь бы налогооблагаемая прибыль не снижалась."
Кстати, многие бухгалтерские системы уже содержат специальные процедуры для коррекции округления возникающего в процессе работы. Самым простым примером является округление статей бухгалтерского баланса и других отчетов до тысяч рублей, когда возникающая разница в 1-2 тысячи рублей обычно добавляется к какой-либо "малозаметной" статье баланса.
Округление может возникнуть не только в балансе. Например, оно также всплывет при деноминации накладных и счетов. Действительно, если у нас есть накладная на 100 единиц товара общей суммой в 123456 рублей (то есть каждая единица товара стоит 1234 рубля 56 копеек при нынешнем масштабе цен), то после деноминации накладной мы получим 123 рубля 45 копеек, а если подсчитаем сумму как 100 единиц товара по 1 рубль 23 копейки, то получим общую сумм накладной в 123 рубля 00 копеек. Конечно же разница в 45 копеек (даже в новых ценах) не настолько значительна, чтобы о ней говорить серьезно, пока у вас 100 единиц товара. Скорее всего вы получите "висящую" задолженность за покупателем на эти самые 56 копеек, которую придется потом списать вручную. А что будет, если у вас есть, например, 100 тысяч этих товаров? это уже выйдет в 560 рублей новыми! Эти 45 копеек могут вывести из строя вывести вашу бухгалтерскую систему, так как некоторые программы проводят автоматическую проверку на равенство суммы документа и всех его строк, и если результат не совпадает, они начинают пугать пользователя "страшными" предупреждающими сообщениями.
Отказываясь от трех нулей мы вероятно снизим количество ошибок, допускаемых бухгалтерами при вводе информации в компьютер. Но только эта польза будет получена в будущем, а вот переходный период будет похож на ад. В стране будут обращаться два вида купюр (с нулями и без), и хотя на первый взгляд кажется что параллельное хождение ни как не должно сказаться на бухгалтерии, но думается, количество ошибок будет огромно. Кроме этого возможна "цепная реакция", то есть распространение ошибок одних учреждений (например, банков) на другие (на их клиентов - компании). Неправильно обработанное платежное поручение или неденоминированная выписка приведет к многократным ошибкам в бухгалтерии. Весьма вероятно, что часть документов (счета, накладные) будут неправильно оформлены (вовремя маркированы, не на всех будет стоять правильная дата и т.д.), что опять же приведет к большим проблемам для предприятий. Если сейчас приходится обрабатывать многие документы с опозданием на месяц, то в начале 1998 года, опоздание будет еще больше.
Естественно, что при выполнении деноминационных пересчетов будет тяжело проводить сравнительный анализ по информации за 1997 и 1998 годы. И если сравнить статьи балансов будет не очень сложно (достаточно будет поделить колонку цифр 1997 года на 1000), то произвести сравнительный анализ по себестоимости товаров будет значительно сложнее. Таким образом для пользователей многих бухгалтерских пакетов будет потеряна возможность проведения анализа, который базируется на информации различных финансовых годов. Не забудьте, что форма №2 о финансовых результатах содержит справочную информацию за соответствующий период прошлого года. Будем надеяться, что разработчики решат проблему соответствующего масштабирования цифр за прошлый год (кстати, возможно, что некоторые пользователи захотят масштабировать 1997 год в своих системах, а некоторые нет).
Алгоритм деноминации достаточно прост: достаточно поделить все суммы в рублях на 1000. При этом необходимо учесть следующие моменты:
Если вы используете только Главную книгу, то вам крупно повезло. В таком случае достаточно ограничиться созданием новой базы данных (компании) с планом счетов, и ввести входящие сальдо 1998 года, поделенные на 1000. Это не очень большая работа, так как на начало года сальдо по счетам прибылей и убытков будет нулевое, и соответственно, объем вводимой информации должен уменьшиться раза в два. Для пользователей западных систем, эта работа может быть упрощена за счет использования модулей трансляции/консолидации.
В случае, если вы используете другие модули бухгалтерской системы, у вас есть два способа провести деноминацию: воспользоваться специальной утилитой, разработанной компанией-поставщиком или вашими программистами, или произвести деноминацию вручную. Для написания специальной программы, которая деноминирует все числа в программе, потребуются знания о форматах используемых баз данных, а они, как правило, являются закрытыми для пользователей. Второй способ можно избрать при отсутствии соответствующей утилиты деноминации. В некоторых случаях, работа по ручной деноминации остатков может быть совмещена с выверкой.
Инструкция гласит, что "все выплаты и расчеты, по денежным обязательствам, оформленным до 31 декабря 1997 г. включительно, осуществляются с 1 января 1998 г. исходя из нового масштаба цен." Это означает, что все счета, выставленные вашей компанией до Нового года, потребуется также деноминировать, и кроме того поделить все текущие задолженности покупателей и задолженности поставщикам. Кстати, не забудьте пересчитать цены на продаваемые товары.
Для того, чтобы осуществить перевод вручную, необходимо закрыть все счета контрагентов на 31 декабря (то есть, как бы оплатить) и завести их заново (то есть, выставить) на 1 января. Хотя, этот метод и трудоемок, но он может оказаться самым простым, если клиентов у компании не много. Этот способ может не сработать, если есть в бухгалтерской системе есть ограничения на выставление произвольных счетов.
Можно оставить все как есть, то есть, при приеме оплаты счетов проверять в каких рублях (старых или новых) был выставлен счет. Этот радикальный способ потребует максимального внимания персонала, который должен внимательно изучить счет на предмет даты его выставления перед тем как принять оплату.
Если номенклатура товаров не очень большая, то при деноминации склада можно также воспользоваться ручным методом. Для этого потребуется завести в складские карточки входящие сальдо в новом масштабе цен. При этом необходимо помнить, что вы не сможете запускать отчеты обрабатывающие информацию сразу за два года (предыдущий и текущий), так как в новой базе данных никакой истории за прошлый год не будет.
В некоторых компаниях бухгалтерская система используется не одна, а вместе с дополнительным блоками, которые были разработаны специально для них. Таким компаниям необходимо понимать, что деноминация затронет и эти доделки. Большой ущерб нанесет деноминация обладателям систем выставления счетов клиентам, гостиничных и других "околобухгалтерских" систем. Многие из них были разработаны за рубежом, и соответственно их авторы возможно и не будут знать о проблеме их российских пользователей. Все эти системы хранят текущие состояния расчетов с клиентами, и их также придется деноминировать.
Кстати, все дневные и часовые тарифные ставки при пересчете должны выражаться в рублях, копейках и долях копеек. Так что если вы использовали некруглые ставки и ваша система не поддерживает учет в "долях копеек", то вы нарушите постановление Минтруда.
А если кто-то из разработчиков новых бухгалтерских пакетов в запале и вовсе отказался от использования копеек в системе, то это он сильно погорячился. Некоторые другие системы требуют установки количества десятичных знаков в валюте при первоначальной настройке, и не разрешают поменять их в дальнейшем. В этом случае придется создавать новую базу с новыми настройками и переносить туда информацию из старой базы, чтобы не производить потом округление до целых новых рублей.
Но самые серьезные изменения, которые потребуются внести в программы, заключаются в требовании с 1 декабря 1997 года (интересно, кто-нибудь выдержал этот срок) до конца 1998 года показывать все цены в двух масштабах параллельно. Это означает, что должны быть переделаны не только все ценники и прайс-листы, но также и счета-фактуры и другие документы. Кстати, интересно отметить, что новая форма счета-фактуры, соответствующей этому указу еще не была опубликована. Думается, что это требование не является критичным, и многие поставщики программ решили тихо спустить это дело на тормозах.
Для пользователей бухгалтерских систем, ведущих дополнительно учет по западным стандартам, а также для зарубежных пользователей из Украины, Белоруссии и других стран, рубль является "иностранной" валютой, и соответственно все суммы в рублях должны быть также уменьшены на 1000 раз, а официальный курс рубля снизится соответственно в 1000 раз.
Если разработчики систем уже не позаботились о наших заграничных коллегах, можно порекомендовать следующий подход: завести новую валюту, которую назвать, например, NRR ("новый российский рубль"), списать все рублевые монетарные активы и пассивы в корреспонденции с каким-либо счетом, затем ввести заново сальдо по тем же самым счетам, но уже в новых рублях. Этот подход не пройдет, если существуют неоплаченные счета, оцениваемые в рублях. В этом случае можно как бы погасить (оплатить, сторнировать, и т.д.) эти счета в старых рублях и выставить новые счета в новой валюте. К сожалению, не все системы позволяют менять валюту расчетов заказчика или поставщика, и тогда придется завести их заново. Если же просто изменить курс рубля на 1 января, то это не приведет нас к желаемому результату, так как фактическая сумма не изменится, а только переоценится их стоимость.
Для некоторых мне хотелось бы напомнить, что провести деноминацию придется не только для "белого", но и для "черного" учета. И если основной валютой этой специфичной для России разновидности финансового учета был выбран доллар, не забудьте, что с 1-го января курс рубля к доллару изменится в 1000 раз.
Если в начале 1998 года произвести деноминацию всех входящих сальдо, а потом внести корректирующие проводки за 1997 год (а это можно делать до конца марта, до даты сдачи баланса), то эти новые проводки могут не попасть в новый деноминированный входящий баланс 1998 года.
Я обратился с вопросом о готовности к предстоящей деноминации к некоторым поставщикам и пользователям западных систем в России, что они собираются делать при деноминации. Все поставщики сейчас разрабатывают специальные утилиты для перевода. К сожалению, инструкции запаздывают, и на некоторые вопросы ответы так и не ясны до сих пор: куда отнести округление статей баланса или что делать с округлением нормативов и средних цен?
Практически все производители бухгалтерских программ для проведения деноминации выбрали подход, при котором создается новая база данных (компания) в которую переносится вся (или не вся) информация из старой базы данных с уже деноминированными суммами. При этом, если потребуется получить отчет за прошлый год, придется обращаться за информацией в старую базу данных, а если за 1998 год, то к новой. Если перенесется вся историческая информация за прошлые года, то у пользователей появится возможность получать информацию за текущий и прошлый года, но только в новых рублях. В некоторых системах (например, в Scala) для разных финансовых годов создаются разные базы данных, что означает, если вы захотите печатать стандартные отчеты за прошлый год и более старые года, то вам придется деноминировать и их.
Некоторые поставщики (например, Platinum и Scala) воспользовались своим опытом проведения деноминации в Польше. Но утилиты, разработанные на Западе могут и не подойти в российских условиях, так как западные программы были значительно перепрограммированы в процессе адаптации к российской бухгалтерской специфике, и соответственно западные утилиты не смогут работать с российскими версиями этих программ.
Наличие блоков трансляции/консолидации значительно облегчает перевод информации в Главных книгах западных программ. Для этого достаточно создать новую компанию, и оттранслировать закрывающий за 1997 год по курсу 1 к 1000 (если используется блок трансляции) или умножить все на коэффициент владения 0.01% (если используется блок консолидации).
Кстати, выяснилось, что многие пользователи не будут дожидаться завершения разработки утилит деноминации, а проведут ее самостоятельно. Как сказал мне финансовый менеджер одного из совместных предприятий: "все равно при переходе с года на год мы выполняем "чистку" баланса, и для нас это не будет большой проблемой, просто поделить все на 1000 при вводе входящих сальдо на 1998 год".
На октябрьской конференции Scala одной из первых западных систем объявила о завершении адаптации утилиты деноминации (ранее она была использована для пользователей Украины и Польши). Утилита сейчас проходит тестирование и начнет распространяться среди клиентов в середине декабря. Она выполнена в виде универсальной программы, для запуска которой предварительно указываются все деноминируемые поля базы данных. Также существует возможность настройки "интеллектуальных правил" для учета специфики настроек у клиента, например, когда одно и тоже поле может использоваться в рублях и в валюте. Утилита производит перевод также всей исторической информации, а для удаления последствий округления потребуется запустить встроенную функцию пересчета сальдо.
Утилита может быть использована как для преобразования российской базы, так и западной, где несмотря на то, что рубль является иностранной валютой, его также необходимо деноминировать. По мнению разработчиков компании модуль расчета заработной платы переделывать для учета десятых долей копеек не потребуется, так как количество знаков для вычислений можно задать в параметрах модуля. А для того, чтобы показывать в документах сразу две суммы, пользователи программы могут воспользоваться встроенными возможностями языка генерации документов.
Platinum уже имела опыт деноминации: специально для денежной реформы, которая прошла в Польше была разработана утилита, которая делила все суммы в злотых на 10000. Опыт, полученный при разработке этой утилиты был использован для разработки утилиты деноминации для российской версии Platinum, и ожидается, что она будет готова в конце этого года. Утилита будет конвертировать все суммы в рублях в программе и будет учитывать всевозможные отличия в настройках различных клиентов.
RBS (представляющий программу Sun на российском рынке) также провел все необходимые исследования для разработки собственной утилиты деноминации. Единственное что сдерживает разработчиков, это недостаточные разъяснения в официальных положениях и инструкциях. Но в любом случае, меня заверили, что утилита будет предоставлена пользователям к Новому году.
Ideas предлагает своим пользователям два варианта перевода. В первом, предлагается произвести автоматическое деление на 1000. Второй вариант был разработан для пользователей (в основном западных), которые иметь так называемый "контрольный след" произведенной деноминации. В этом случае деноминация проводится с помощью корректирующих проводок, которые дальнейшем можно проверить. Данные по каждому счету корректируются на необходимую сумму.
О разработках своих собственных версий утилит деноминации объявили и другие западные программы Exact, Concorde XAL (Columbus IT Partner), Navision (Импакт-Софт) и SAP.
В заключение, мне хотелось бы рассказать о своем опыте проведения деноминации. В 1994 году в Туркменистане была введена новая туркменская валюта - манат. При этом был объявлен курс обмена 1 к 50. Так как в бухгалтерской системе был модуль консолидации, я просто перевел все остатки по счетам плана счетов из одной валюты в другую по курсу 1 к 50. Каково же было мое удивление, когда на следующий день выяснилось, что на некоторых забалансовых счетах компания отражала не только рубли, но и тонны добытой нефти, которые также были успешно мною поделены на 50. И хотя положение было оперативно исправлено корректирующей проводкой, моя уверенность в простоту деноминации быстро улетучилась.
Хочется напомнить, что деноминация - это не единственная напасть, обрушивающаяся на разработчиков и пользователей бухгалтерских программ под новый 1998 год. В числе нововведений нас ожидает замена всех номеров расчетных банковских счетов, а также новая форма платежного поручения. Кроме этого возможно будут введен новый порядок учета основных средств и некоторые другие законы. Ну а если будет осуществлен форсированный переход предприятий на международные стандарты бухгалтерского учета и новый план счетов, вот тогда нам всем и не придется спать в Новом 1998 году!
