4 ноября 2015 г. Президентом Республики Беларусь подписан Указ № 450 «О проведении деноминации официальной денежной единицы Республики Беларусь».

В соответствии с Указом с 1 июля 2016 г. проводится деноминация официальной денежной единицы Республики Беларусь. С указанной даты и по 31 декабря 2016 г. обращающиеся денежные знаки образца 2000 года в виде банкнот подлежат замене на денежные знаки образца 2009 года в виде банкнот и монет в соотношении 10 000 белорусских рублей в денежных знаках образца 2000 года к 1 белорусскому рублю в денежных знаках образца 2009 года.

Особенностью нынешней деноминации является ее проведение в середине года.

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

Итак, рассмотрим подходы, точнее мой подход, который я считаю целесообразным применить для решения этой задачи:

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

2. Производится анализ данных и подготовка к их обработке. Обрабатываться будет вся база данных. Время проведения операции - 1 июля 2016 г. Но тренироваться можно и нужно заранее.

Подозреваю, что фирмы-франчайзи и прочие разработчики ПО на платформе 1С предлагают Вам провести обработку делением всех показателей на 10000 с помощью wrap и подобных ей обработок. При такой обработке нарушится сопоставимость показателей на разных уровнях аналитики. Представим себе, что у Вас есть 1000 покупателей с дебиторской задолженностью, у каждого из них задолженность выражена в среднем 5-10 накладными или актами. Теперь представим, что каждая позиция акта будет округляться. Изменятся суммы документов, изменится общая задолженность контрагента и задолженность всех контрагентов. Причем очень значительно, т.к. многие суммы не смогут быть выражены копейками. Применяемый коэффициент - 10000 и при округлении цен до сотен копейки еще смогут корректно отразить все суммы с учетом деноминации. Иначе пойдут ошибки из-за округлений. Кроме этого показатели до даты деноминации будут рассчитываться "на лету", следовательно, собственные отчеты также подлежат переработке. Ну и, конечно, переход на другую конфигурацию с переносом остатков посередине года, либо деноминация только остатков на 01 июля - самый хороший вариант для мазохистов. Ни один типовой бухгалтерский отчет Вы не сможете сформировать, если он захватывает дату деноминации.

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

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

Свежие новости...

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

В случае наличия подготовленного файла конфигурации и настроенных параметров обработки базы благодаря прямому доступу к данным и современному "железу" время обработки всей базы данных (вместе с пересчетом итогов и сохранением измененной конфигурации) средней фирмы за 3-4 года работы можно сократить до 5-10 минут. Универсальный механизм обрабатывает курсы валют, оклады, цены, числовые значения с типом данных «неопределенный», содержимое документов с корректным пересчетом суммы взаиморасчетов и итогов по колонкам, движения документов и проч. Он приспособлен и к изменению структуры конфигурации.

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