Добрый день. Планируем переход на новый план счетов с 2020 года.

Имеются пересекающиеся счета, например, был счет 1280* - стал 1270*. При этом 1270* был и в старом плане счетов , а в новом теперь стал 1150*, и т.д.
Перенос сальдо на новые счета будет осуществлен 31.12.2019 г. 15-м периодом.
Далее будут проведены работы по перенастройке счетов и с 01.01.2020 г. уже планируем начать работу в новом Плане счетов.

Возникает вопрос: сторнирование документов прошлого года 2019 года. Стоит задача автоматизировать процесс сторнирования, чтобы при сторно документов в 2020 году проводки делались уже по новым счетам. Например, была проводка Дт1280* Кт1031*. Сторно должно отработать уже на Дт1031* Кр1270*. Счет 1280* должен подмениться на 1270*.

Может, кто сталкивался с такой ситуацией, поделитесь, пож-та, опытом.

Статья, ссылку на которую выложил darkduck, реально очень полезная. Плюсую.
Но аспекты сторно там не рассматриваются.
Автор, у Вас в рамках данной работы намечается своеобразная повторная миграция данных.
Все дело в том, как будут переноситься остатки: попозиционно или общей проводкой переноса сальдо по всему счету.
Если попозиционно, то тогда сторнироваться должен не исходный документ, а документ переноса.
Если общей суммой сальдо по счету ГК, то ответ очевиден - сторнироваться такие документы нельзя.
Сразу после переноса остатков старые счета вообще должны быть заблокированы на уровне всех БЕ, которые их используют.
Проблема №2 - старые счета после переноса сальдо будут обнулены и вступят в новый финансовый год с нулевой суммой, если речь идет о счетах наличия.
Сторно документа прошлых лет неизбежно вызовет открытие сальдо по данному счету. Дальше что - снова перенос данных на новый счет?
Посмотрим под другим углом на это все. Если проводить аналогию между перестройкой плана счетов и продуктивным запуском с миграцией остатков через счета initial общей кучей, то сущность документа прошлого года исчезает вообще, его как бы нет и не было. Аналогичная проблема была бы, если бы Вы только запускали продуктивную систему и стояла задача зарегистрировать исправительный СФ: технология подразумевает сторно документа оригинала, которого при этом в отдельном виде и не существует.
Еще один пример запрета сторно документов прошлых лет напрашивается сам собой: миграция на ГГК, когда на дату X сальдо фиксируется и заполняются FAGL таблицы. Старые позиции в BSEG хранили историю оценки иностранной валюты, если отменять выравнивание или сторнировать их, сразу же образуются разрывы по курсовой разнице, которые не были учтены при запуске ГГК в механизмах трансляции. В результате реализован абсолютно стандартный и законный запрет на сторно и отмену выравнивания документов, прошлых периодов. Казалось бы, хочу отменить выравнивание и сторнировать, а не могу. Проект это запрещает. Все это я к тому, что подобная практика - это нормально.

Все это есть некоторые предпосылки, постулаты, которые в такой ситуации стоит просто принять. Мое мнение - если Вы перенесете сальдо общей суммой в разрезе счетов ГК, то ничего из прошлых годов Вы сторнировать не можете. Счета заблокировать, на сторно реализовать запрет. На отмену выравнивания реализовать запрет.

Но если все же решитесь подменять счет при сторно, то сделать это, конечно же, можно. В том же самом OPEN FI.

*рука лицо*
полез гуглить "новый план счетов". Че то поменялось? или только для бюджетников которым по идее сап не по карману?

А что план счетов меняется только в связи с нормативными изменениями?
Я внутри синтетического счета, который кодирован в соответствии с планом счетом страны, могу аналитических счетов создать хоть 100 штук.
И вот уже возникает потребность новой детализации, переноса остатков. Да чего угодно.
И это будет ровно тот же самый переход на новый план счетов, просто маленький))
Если проблему декомпозировать и сузить даже до заведения одного единственного счета, то вопрос автора не такой уж, извините, и глупый.
Был счет А, стал счет Б. Остатки перенесли, счет А закрыли. Что делать со сторно документа по счету А - это весьма прикладной и интересный вопрос.

это как микро-инфаркт?

со всякой такой фигней призван бороться SLT Reorg. Но я настоятельно не советую в это ввязываться.