Я бы использовал то, что есть - SAP. Блок SD в R/3 очень даже навороченный. Имеется и поддержка сервиса. Чего нет, можно и дописать, благо система открытая - садись и abap-ь.
Или, как минимум, посмотрел сперва имеющийся функционал. Оцень полезно бывает с точки зрения построения архитектуры системы

кроме того, все равно придется сопрягать финансы с CRM - как минимум по платежам и задолженностям. Если делать все в R/3 - проблемы не будет как таковой. Если пользовать SAP CRM - проблема решается штатными средствами

Так_забежал_просто1. Забавно, что вариант "заказать разработку программы в софтовой фирме" в таких ветках обычно даже не обсуждается :) А, возможно, зря.
2. На самом деле, за самостоятельную разработку есть смысл браться только в том случае, если в коллективе есть пара разработчиков, прошедших через несколько проваленных проектов и сделавших из этого определённые выводы. И надо чётко представлять, сколько конкретно времени на какую часть проекта уйдёт. И что с ним будет дальше.
3. С другой стороны, по собственному опыту, в SAP'е много чего нужного не хватает. Как и в любой тиражной системе. Ну да, можно дописать то, чего не хватает. Но это получится переписывание с нуля всего модуля, в конечном итоге. У SAP'а движок довольно неудобный для программирования, т.к. не объектный ни разу (ну да, да, есть там какие-то объекты, даже 2 вида :) и представляет собой нагромождение каких-то почти не связанных решений разной степени удачности.
4. Конечно, если уже есть SAP, выбрасывать жалко... ;)

1 что такое "движок у SAP"?
2 Внутренний язык программирвоания ABAP вполне ООП. Найдите 2 отличия :)
3 что касется "придется с 0 переписывать" - так Вы просто её готовить не умеете

Так_забежал_простоНебольшое продолжение. Немного коррелирует с п.2
"Об убогости и незаменимости пакетного ввода". Убогость: ну какое мне дело до того, что там пользователю на экране показывают, если я программирую бизнес-логику? Ан нет, фактически, приходится, вместо того, чтобы вызывать стандартную функцию с заданными параметрами, программным образом вводить на экран всё то же самое, что вводит пользователь. А если потом интерфейс изменится? А если автор интерфейса решит контролами побаловаться? В общем, муть. Незаменимость: а чем его заменишь? Нету другой возможности вызывать из своих программ стандартные саповские функции. BAPI? Я вас умоляю. Он делает совсем не то. САПовские программы сами не используют BAPI_...-функции. Потому что они глючны. Я сам видел очевидные ляпы.

1 bapi-функции работают нормально. По карйней мере, у нас был единственный случай, когда "удалось" обнаружить ошибку. Она (ошибка) была поправлена в следующием месяце
2 конечно, bapi - функции не пользуются стандартным функционалом, просто потому, что они сами - оболочка над стандартным функционалом. Я знаю о чем говорю, и могу привести примеры
3 пакетный ввод, как Вы сами же и указали, убожество. Ну и не используйте его
4 Видно, что внедрение sap нанесло Вам сильное морально увечье. Функционал SAP - нормальный функционал, пригодный для реализации в большинстве компаний. Просто все не так просто, как хочется. Программировать ведь хорошо тоже не просто научиться, почему же Вы воспринимаете систему как коробочный продукт, с которым можно разобраться за пару месяцев? Функционал системы построен на серьезной, академической базе. Внедрение требует значительных знаний экономической теории, знаний в области финансов, контроллинга, огранизации поставок. ERP-системы - это действительно сложно.
5 ABAP - это достаточно убогий язык. Но система, это не язык программирования.Извините, но Ваш подход - подход сноба, которому инструмент нужен не для как инструмент реализации поставленных задач, а средство получения эстетического удовлетворения.
6 Проекты по внедрению ERP-системы, ориентированные на программирование, обречны на провал