Да кто ж вас заставлял то читать, не нужно было так мучиться. Классику читайте что ли. Кстати, если уж быть совсем по делу, то указали бы на множество грамматических ошибок, а то корректоры сайта наверное тоже ушли рыдать горькими слезами.

Илона!
 
Я проверил Ваш вопрос на "нулевом" IDES версии ECC6 EHP4 с активированной ГГК. У меня получилось провести частичный платеж. Затем в режиме редактирования документа REBZ*-поля были открыты. К сожалению, дальше проверить не удалось - моя тестовая система в этот момент всегда падала.
Подозреваю, дело не только в самой ГГК, но и в некоторых дополнительных настройках, например специфичных для сплиттинга.
 
Так как функциональность корректировочной с-ф является весьма специфичной разработкой российского офиса САП, то рекомендую обратиться за разъяснениями по этому поводу именно туда. Но есть небезосновательные подозрения, что Вас отправят в сторону консалтинга.

При активации Новой Главной Книги отсутсвует возможность удаления/изменения поля Ссылка на счет/Платеж к (BSEG-REBZG).
Т.е. если раньше при сторно, например, счета-фактуры выполнялась проверка на наличие ссылок на данный счет-фактуру в платежах, и пользователю предлагалось перед сторно удалить все ссылки на сторнируемый с-ф, то сейчас пользователю нужно не просто удалить ссылку, но и сторнировать этот платеж.
Интересная ситуация возникает, когда приходит исправительный счет-фактура к счету-фактуре, проведенному и частично оплаченному в закрытом периоде. Сторнировать исправленный с-ф не дает проверка на наличие частичной оплаты (заполнение поля REBZG в платеже), а сторнировать платеж не дает закрытый период.

Статья обрывается на таблице 4. Где табл.5 и дальше?

Еще бы было написано что такое Open Fi, в какой транзакции настраивается и какой конкретно программный код для решения данной задачи надо вставить.

Еще бы было написано что такое Open Fi, в какой транзакции настраивается и какой конкретно программный код для решения данной задачи надо вставить.

Действительно, при чем тут ERP-система.
Это же две несвязанные между собой сущности: реинжиниринг и ERP-система! Внедряют одни в одно время, реинжиниринг делают другие в другое время. Главное, чтобы был он - тот, который за это платит :-)

Все логично, но причем здесь ERP-система? Бизнес-консалитнг и бизнес-инжиниринг - вот о чем идет речь в статье.

Изменение бизнес-процессов в ходе проекта внедрения ERP-систем невозможно, как мне кажется. По крайней мере, серьезные изменения. Слишком велики риски и слишком мало времени. Отсюда и кривые внедрения.

Поддерживаю Рашида - статья написана живо, но ни о чем. Аналогия - не доказательство, это аксиома. Плохая консалтинговая компания отличается от хорошей наличием собственной методологии, анализом проектов, привлечением экспертов, меньшей жадностью и большей заботой о репутации. В идеале на средний уровень качества компания выходит независимо от уровня консультантов.

1. Статья отражает мнение автора, сложившееся на основе весьма поверхностного знакомства с обсуждаемым предметом. К сожалению, метод "от частного к общему" иногда приводит к парадоксальным результатам, таким как пронизанные личными обидами опусы бывших руководителей проектов, с неподдельным удивлением обнаруживающих в процессе внедрения, что "ERP-система показывает только те данные, что были в неё введены" (таких как http://www.business-process.ru/kis/erp/hold_advisers_erp.html), либо приведённая статья.
В данном случае, идёт путаница в терминологии, либо полноценная подмена понятий. Объект критики в статье - не отраслевые решения (без которых внедрить систему в той или иной области бизнеса затруднительно - например SAP IS-A в автомобильной промышленности), а z-решения, т.е. дописывание системы под требования конкретного заказчика. А вот с критикой z-решений, изложенной в статье, трудно не согласиться. Основных же причин появления z-решений всего 3:
1) Недостаточная квалификация специалистов по внедряемой системе - от этого, увы, не застрахован ни один заказчик и ни один интегратор; спасти здесь может только система контроля результатов (проектных решений, документации по разработкам и настройкам) на проекте, которая позволит выявлять недостаточно квалифицированные ресурсы и замещать их по мере необходимости.
2) Нежелание или неспособность предприятия пересматривать и изменять порядок своей работы. Зачастую стихийно сложившиеся "изобретённые колёса", либо существующий бардак в части оргструктуры и бизнес-процессов успешно преподносятся топ-менеджменту предприятия как "конкурентные преимущества" и само предприятие требует переписывания целых блоков системы под "требования бизнеса". Перед этим зачастую бессильны даже самые квалифицированные консультанты - ведь они только могут аргументировать, перечислить "за" и "против" каждого из вариантов, тогда как непосредственно принятие решения всегда остаётся за менеджментом заказчика, зачастую руководствующимся не объективными а субъективными соображениями (сохраним наши "конкурентные преимущества").
3) Витиеватые требования законодательства. Тут, как говорится, без комментариев.
 

2. Не могу не согласиться с Олегом Точенюком, что 99% внедрений выполняется в условиях жёстких, а иногда и жесточайших ограничений по времени и ресурсам. А как известно "дёшево", "хорошо" и "быстро" не бывает. Так что не надо удивляться очевидным вещам.
 
3. К сожалению, на 100% российских проектов наблюдаю жуткую ситуацию: после продуктивного старта документация, подготовленная на этапе внедрения и переданная команде поддержки, перестаёт актуализироваться и через 3-6 месяцев перестаёт быть источником информации о системе. Причины: повсеместная экономия на количестве и качестве ресурсов в службах поддержки. Так что совсем не всегда "неизвестно как работающая система" - это вина "бестолковых" и "ленивых" консультантов.

Мда... ставить телегу впереди паровоза - это веселое занятие...

Вот именно этим тут постоянно и занимаются. Переписывают и переподписывают вот эти самые документы. Ну процесс у них такой.

Ну, если реальные заказчики ЕРП (акционеры и руководители компании) готовы рисковать бюджетами таких проектов, они не будут мотивировать персонал для активного участия в проектных работах... Но лучше, как говорится, один день потерять, потом за 5 минут долететь... - некоторая мотивация участников обернется экономией в разных областях и процессах.
Что же касается "интуитивно понятного интерфейса" apple - посадите за Mac человека который ни разу не видел MacOS. Увидите, что интуитивность интерфейса вдруг куда-то испарится... Чтобы что-то узнать, нужно в любом случае потратить время и усилия и с пользователями нужно грамотно работать; если говорить заезженными фразами "управлять их ожиданиями". Для этого в крупных проектах у заказчиков создаются команды бизнес-экспертов, полностью вовлекаемых в проект.