логотип
Главная

Рейтинг@Mail.ru

Стратегия переноса данных информационной базы 1С

В данной статье рассмотрим оптимальный с точки зрения автора порядок действий при выполнении задачи переноса данных с использованием различных обработок (правил) переноса данных.

Достаточно часто эту задачу ограничивают переносом только остатков на определенную, как правило начало года, дату. При этом считается, что перенос документов при таком подходе не нужен. Так ли это, попробуем разобраться.

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

Чисто технически безусловно можно перенести данные об остатках однократно на определенную дату. Но нужно, чтобы эти данные были сформированы и не изменялись впоследствии. А вот этого на практике никогда не бывает. Учет традиционно ведется задним числом, причем, я бы сказал, очень задним. Остатки на начало года будут окончательно сформированы в лучшем случае в феврале, чаще в марте. А начинать работать в новой информационной базе нужно уже 1 января. Напоминаю, сейчас мы рассматриваем вариант переноса только остатков, именно поэтому документы нового года нужно создавать уже в новой базе начиная с 1 января.

Часто решение описанной проблемы видят в повторном переносе остатков. Однако не все так хорошо, как хотелось бы. Повторный перенос - это всегда риск получить новые проблемы.

Здесь я немного отвлекусь и отвечу на частый вопрос: "Возможен ли вообще повторный перенос". Возможен без всяких оговорок, если между переносами никаких изменений ни в источнике ни в приемнике не было. Это понятно, переносите сколько угодно раз, получите тот же результат. Если в приемнике никаких изменений не было, а изменялась лишь база-источник, то результат будет с высокой долей вероятности без проблем. Если синхронизация объектов производится по внутренним идентификаторам, то точно без проблем, если по реквизитам - с высокой долей вероятности без проблем. Чтобы пояснить последнее утверждение, приведу простой пример возникновения проблемы: синхронизация контрагентов по ИНН, скопировали контрагента с пустым ИНН, заполнили ИНН, скопировали повторно. Если между повторными переносами изменялись и база-источник и база-приемник, то риск получения всевозможных несоответствий многократно возрастает.

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

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

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

Исходя из вышесказанного можно сформулировать правильную стратегию так: правильный перенос остатков - это всегда  в том числе перенос документов с начала года.

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

© Борис Балясников, последние изменения январь 2017г.

© ООО "Профи-центр", г.Бирск: тел. (34784) 4-25-50, факс: (34784) 4-25-50, icq: 565351574, 591661865, mail@profiufa.ru +18