Ситуация, конечно, стандартная, но бардачная.
SAP, безусловно, ничего по этому поводу не рекомендует (официально), да и не может: проблемы индейцев шерифа не волнуют. Да и проблема здесь, по сути, не совсем связана с ОПЭ. В реальности это очень большой временной разрыв между продуктивным стартом и появлением подтвержденных данных на дату его начала.
Какие выходы из положения я могу предложить:
1) Не стартуем с 01.01.2014, продолжаем работать в старой системе. Официальную дату старта переносим, к примеру, на 01.04.2014. К моменту окончания закрытия года (например, 15.03.2014) прекращаем работать в старой системе (объявляем "заморозку" операций), выгружаем из старой системы остатки на 15.03.2014 со стоимостью, грузим в новую. Остаток марта потом довводим вручную в новую систему после запуска. Промежуточные месяцы закрываются в старой системе.
Плюсы: все идеально с точки зрения учета.
Минусы: ОПЭ отменяется.
2) Стартуем 01.01.2014, но ОПЭ проводится не в "чистом" продуктивном клиенте, а в его копии, куда грузятся условные данные на 31.12.2013 из старой системы. Старая система продолжает работать параллельно. Т.е., данные, наработанные за промежуток между началом ОПЭ и появлением данных на начало года, по сути, объявляются тренировочными и ничего не значащими (а целью ОПЭ, к примеру, - "привыкание" пользователей к работе в новой системе и "живое" тестирование многочисленных разработок). К моменту окончания закрытия года производятся действия, описанные в варианте 1. Промежуточные месяцы закрываются в старой системе.
Плюсы: скорее всего, с точки зрения учета все будет отлично.
Минусы: двойной ввод данных в течение промежуточного периода.
3) Стартуем 01.01.2014, ОПЭ проводится непосредственно в "живом" продуктиве (то, что описали вы). Точных данных нет в течение 3 месяцев, что будет грузиться в систему для хоть какого-то старта с 01.01.2014 - непонятно (я ваш объем проекта не знаю, тем более). Предположим, что грузятся некие условные данные на 31.12.2013, выгруженные из старой системы, вероятность того, что они сильно разойдутся с реальностью, невелика. Сразу вопрос: в какой системе бухгалтерия планирует закрывать промежуточные месяцы (январь, февраль, март). Видимо, в новой, иначе у нас ошибка логики и BSOD

Далее варианты:
Вариант А. Движения вводятся в новую систему в порядке возникновения операций. В этом случае даже если поплывут количества на момент Ч, то несильно (это можно скорректировать инвентаризацией). Хуже, если полезут цены и, соответственно, остатки по счетам запасов (а это обязательно произойдет, если у вас средние скользящие цены или если метод оценки в старой системе и новой сильно различается). Скорее всего, бухгалтерия устроит истерику у генерального, и придется откатывать все сделанное под ноль и делать заново. (С) Сизиф. Минус сон по ночам, общение с семьей на ближайшие пару-тройку месяцев без выходных.
Плюсы: отсутствуют.
Минусы: одни сплошные минусы, этот вариант примерно соответствует ходьбе по краю пропасти без страховки.
Вариант Б. Движения вообще не вводятся в систему (в части движения материалов), сидим и ждем, пока закроются в старой (один из ваших вариантов).
Нереально, поскольку бухгалтерия-то хочет закрывать промежуточные месяцы в новой системе, и ей требуется для этого полный набор данных, включая материальные движения.
Итог: конфликт со здравым смыслом (если бухгалтерия и получит данные, то, с большой вероятностью, неправильные). Вариант нежизнеспособен.
ИТОГО: лучше такие бесчеловечные эксперименты, как вы пишете, над собой не производить, а выбрать опцию (1) или, в крайнем случае, (2).