Грядущая деноминация, вне всякого сомнения, добавляет головной боли всем жителям страны. В то же время есть много категорий людей, на чьи плечи ложится обязанность по техническому обеспечению выполнения этого мероприятия. Не в последнюю очередь деноминация затрагивает разработчиков программного обеспечения и тех, кто занимается сопровождением готовых программ. Нынче все субъекты хозяйствования столкнулись с необходимостью модернизации используемого программного обеспечения и корректной переоценки рублевых величин. По роду занятий мне тоже приходится участвовать в этом процессе. И если с собственными разработками мне разобраться легко, то необходимость проведения деноминации в продуктах 1С, используемых для учета на множестве предприятий, заставляет напрягать извилины и искать наиболее оптимальные пути решения данного вопроса. Процесс осложняется тем, что мои познания в работе с конфигурациями 1С довольно поверхностные. Но задачи поставлены, и их необходимо решать.
В данной заметке я хочу рассказать о примерном алгоритме действий, выбранном на основе долгих консультаций с бухгалтерами и разработчиками программ, изучения материалов в интернете и согласования с заказчиками. Возможно, кому-то данный материал пригодится в качестве небольшого пособия к действию.
В первую очередь хочу сказать, что если у вас используется стандартная конфигурация, приобретенная у любого из официальных поставщиков продуктов 1С и в дальнейшем не дорабатываемая самостоятельно, то самым простым и наименее затратным способом проведения деноминации будет обращение к этому поставщику за обновлением конфигурации и проведением всех необходимых мероприятий по переходу к новому учету. Если же конфигурация разрабатывалась с нуля, дорабатывалась и изменялась собственными силами или с привлечением сторонних разработчиков, то ее подготовка к деноминации будет более затратной.
Итак, из всех предлагаемых и обсуждаемых вариантов проведения деноминации в программах 1С был выбран вариант с разделением базы данных на 2 не связанные между собой части: в одной будет храниться весь учет до деноминации, во второй будет вестись учет после нее. Надо понимать, что как и все другие предлагаемые варианты, этот не лишен недостатков. В частности, станет невозможным автоматическое создание накопительных отчетов, получение актов сверок, расчет отпусков и выполнение ряда других задач за период, в который попадает дата деноминации. Возможно, часть этих процессов удастся автоматизировать в дальнейшем, но готового инструмента для этого нет. Об этом стоит предупредить персонал, который работает с 1С.
Последовательность действий такова:
- Заранее, не дожидаясь даты деноминации, необходимо соответствующим образом подготовить вашу конфигурацию к работе с новыми деньгами. Для этого делаем копию рабочей базы данных (саму рабочую конфигурацию мы трогать вообще не будем, все изменения будут выполняться только на копиях). С этой копией вам предстоит выполнить несложную, но кропотливую работу. Необходимо поменять разрядность (добавить 2 знака после запятой) всех числовых реквизитов, хранящих цены и суммы в рублях, во всех справочниках, документах, константах. Также необходимо проверить и при необходимости заменить округления чисел и формулы для вывода сумм прописью во всех печатных формах документов и справочников, в обработках, в отчетах и в глобальных таблицах. Далее необходимо также найти и подкорректировать во всех программных модулях, включая глобальный модуль, все процедуры округления рублевых величин. Объем работы довольно большой, поэтому для средней конфигурации отведите на этот этап несколько дней. Обязательно проверьте правильность выполненного изменения конфигурации, последовательно открывая используемые справочники, документы, отчеты.
- Вместе с заказчиком решите, какие участки учета будут закрыты до даты проведения деноминации, а какие будут закрываться позже. Например, для обеспечения возможности отгрузки продукции с 1 июля необходимо обеспечить корректные цифры складских остатков и цен на отгружаемый товар на 30 июня, а, скажем, заработная плата за июнь будет считаться позже. Желательно также проверить наличие в учете товаров, расценок, услуг по ценам менее 100 неденоминированных рублей (1 копейка в новых ценах). Возможно, самое время избавиться от них, если это неликвидные старые остатки, или изменить учетную единицу измерения.
- 30 июня бухгалтера закрывают отдельные участки учета, сверяют остатки. Важно предупредить персонал, что любые дальнейшие изменения на закрытых участках учета за период до даты деноминации будут сопровождаться для них кучей ручной работы и большой вероятностью ошибок, так как все измененные итоговые цифры им придется деноминировать и переносить во вторую копию базы данных вручную. Почти все предприятия и предприниматели, с которыми я сталкивался, согласны сделать нерабочим (или ограничить работу с 1С) один из дней – либо 30 июня, либо 1 июля. Лучше, конечно, сделать выходным 1 июля с учетом предстоящих выходных и того факта, что банковская инфраструктура и контрагенты могут оказаться не готовы к полноценной работе в первый день жизни с новой валютой.
- Снова делаем копию рабочей базы данных. Конфигурацию этой копии объединяем с конфигурацией, подготовленной в пункте 1. Теперь это будет основная база данных, учет в которой будет вестись с даты деноминации. Назовем ее для удобства “БД 1-07-16”
- Теперь в БД 1-07-16 необходимо выполнить свертку данных на 1 июля. Сверткой называется обработка, которая рассчитывает и записывает в базу остатки на определенную дату, а затем удаляет все документы и операции за предшествующий период. В результате получается практически “чистая” база данных с заполненными справочниками и константами, начальными остатками на счетах и местах хранения, но без документов за предыдущий период. Выполнять свертку можно с помощью стандартной обработки wrap.ert, обычно расположенной в каталоге extforms (если не нашли, скачать можно отсюда).
- После проведения свертки производится сама процедура деноминации. Для этого используется все та же обработка wrap.ert. В ней на вкладке “Деноминация” необходимо задать коэффициент деноминации 10000, установить флажок “Суммы” и указать счет для списания (обычно “00”). Также при необходимости можно указать список счетов, по которым не нужно проводить деноминацию.
- Теперь в новой базе данных БД 1-07-16 нужно проверить и подкорректировать некоторые константы, касающиеся округления расчетов. С учетом того, что при деноминации меняется также обозначение и код национальной валюты, необходимо добавить новую валюту BYN с кодом 933 в справочник валют и установить ее в качестве основной. Как сработает замена базовой валюты, я еще не проверял. Скорее всего, потребуется ручная корректировка некоторых справочников (договора, банковские счета и т.п.).
- Проверяем правильность выполненной деноминации и корректность работы новой конфигурации в целом. Исправляем выявленные недочеты.
- С 1 июля полностью работаем в новой версии. Незакрытые участки учета за июнь месяц и второй квартал продолжаем вести в старой конфигурации. После закрытия и проверки всех оставшихся итогов за первое полугодие необходимо снова сделать свертку и деноминацию (выполняем на очередной копии базы данных за первое полугодие) и перенести сформированные деноминированные остатки в БД 1-07-16. Скорее всего, для переноса придется написать отдельную обработку. При небольшом объеме данных перенос можно выполнить вручную. Можно рассмотреть и другой вариант: все документы и справочники из БД 1-07-16 выгружаются во внешний файл стандартной обработкой export77.ert, затем выполняется повторная свертка и деноминация базы согласно пунктам 4-8, затем в новую базу загружаются сохраненные во внешнем файле данные с помощью обработки import77.ert.
Вышеуказанный алгоритм действий только предполагаемый. Он не отрабатывался на практике (кроме первых двух пунктов) и будет проверен только в процессе проведения деноминации. В любом случае, нам всем предстоит пройти через это, кому-то, возможно, в первый раз, кому-то уже в третий (и, вероятно, не последний). Если у кого появятся какие-нибудь замечания и предложения по данному материалу, милости прошу к обсуждению в комментариях.
