Изменение движений

(0) Нет и не может быть на этот счёт никаких конкретных рекомендаций или стандартов от 1С. Т.к. слишком разные могут быть не только причины изменения алгоритмов формирования движений, но и сами алгоритмы формирования движений. Даже применительно к твоему (относительно простому) случаю можно подойти с нескольких сторон. Учитывая общий подход, который используется в БП 3.0 для обработки проведения, который подразумевает примерно такой порядок.
- формирование (собирание) текста запроса для получения всех необходимых для проведения данных.
- выполнение этого запроса.
- заполнение таблиц с данными для проведения на основании результата запроса. Для каждой таблицы своя процедура вызывается типа ТаблицаТоваровИП = УчетДоходовИРасходовПредпринимателя.ПодготовитьТаблицуПоступленияМПЗ().
- формирование движений, заполняемых из собранных ранее таблиц. Это формирование происходит посредством вызовов отдельных процедур на каждый кусок типа УчетТоваров.СформироватьДвиженияПоступлениеТоваров().

Соответственно.
Можно изменить алгоритм формирования текстов запросов, из которых собирают таблицы для движений, чтобы уже в результат запроса ненужные данные не попали.
Можно изменить алгоритм формирования таблиц, заполняемых при обработке результата запроса, отсекая лишнее на этом этапе.
Можно изменить алгоритм самой процедуры ОбработкаПроведения (например, обойти вызов процедуры формирования какой-то части проводок).
Можно изменить алгоритм той процедуры, которая вызывается из ОбрабткаПроведения и формирует проводки, обходя таблицы, собранные на предыдущих этапах.
Можно сделать подписку на событие ОбработкаПроведения, в которой очищать уже заполненный набор записей от "лишних" движений.
Можно сделать подписку на событие ПередЗаписью набора записей регистра бухгалтерии, в которой очищать набор записей от "лишних" движений. Удобно, если аналогичный алгоритм используется для нескольких видов документов или имеет какую-то универсальную суть, когда движения должны корректироваться не только при проведении документов, но и при любых изменениях набора записей, включая программную обработку вне контекста регистратора.
Подписки можно делать в основной конфе, а можно в расширении. Так же в расширении можно вместо подписки расширить сами процедуры ОбработкаПроведения документа или ПередЗаписью набора записей с директивой &После.
Каждый из этих способов имеет право на жизнь и у каждого есть свои плюсы и минусы.

Если принципиально не изменять типовые объекты и модули основной конфигурации, то расширение или подписка.
Причём в расширении, как рекомендует (5) - тоже через подписку.
Рекомендация (4) - в расширении при помощи "ИзменениеИКонтроль" - самое дурное. Т.к. с одной стороны периодически при обновлении будет выскакивать уведомление об изменении. А с другой стороны в очередном обновлении может получиться ситуация, когда код по формированию удаляемых тобою движений перенесут куда-нибудь в другую процедуру или модуль, оставив старый изменённый тобою модуль для совместимости или ещё каких-то целей. В таком случае уведомления об изменении ты не получишь, а доработка фактически перестанет работать потому, что этот код просто перестал вызываться. Не раз на подобное наталкивался.
Не исключаю, что может быть в твоём случае целесообразнее внести изменение в сам код формирования движений (без расширений и подписок). Это позволит при последующих обновлениях в диалоге трёхстороннего сравнения/объединения при обновлениях видеть внесённые тобою изменения и сравнивать их с изменениями в обновлении типовой. И таким образом визуально контролировать комплементарность твоих доработок с каждым обновлением. Это имеет смысл при каких-то сложных доработках больших подсистем (типа НДС, расчета себестоимости и т.п.).