Флеймер
Вот еще для разминочки.
1) Гарантии
Продажа по гарантии - регистрация гарантии,
сервисное обслуживание по гарантии - скидки на обслуживание и бесплатные ремонты,
Выставление счетов за поддержку гарантии.

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

Флеймер
2) Подбор доступного к отгрузке количества или даты выполнения.
По заказу на продажу система проверяет доступное на складе количество, количество в производстве и в пути. И по этим данным расчитывает возможность и ближайшую дату отгрузки.

Это алгоритм MRP-II. Любая система, претендующая на статус ERP, должна позволять данную операцию. Соответственно, система даже должна создать заказ покупки у поставщика (или производственный заказ) на недостающее количество. Вот только объясните мне как разрулить ситуацию с помощью системы:
Существует заказ поставщику. Но поставщик подтверждает лишь частично заказ, да и частично поставит товар - замену. Как отреагирует на это система?
Существует 10 заказов с различной датой поставщику. Поставщик в одной поставке подвозит весь 1 заказ, частично 2 и частично 3. При этом в 1 заказе возникает товар - замена.
Во второй поставке снова частично 2 заказ, частично 4 и полностью 5. И ошибочно привозит товар Х. (товар Х надо принять на ответственное хранение, его возможно прийдется вернуть поставщику). Как на это отреагирует складской модуль? Как в системе будет учтен товар принятый на хранение и на ответственное хранение в рамках одной поставки?
Флеймер
4) Расчет и включение в счет фрахта. Либо разбросать на цену, либо включить в счет отдельной строкой.

Как любят говорить о товарных издержках и о плюсах которые они несут! Беда только в большинстве западных систем при учете товарных издержек возникают "дополнительные" проводки, увеличивающие оборот. Ну да ладно. Может быть и не возникают. Ведь и в правду хороший функционал. Только это капля в море.
Флеймер
5) Контроль цены отгрузки. Она не должна быть меньше себестоимости.


интересная функциональность. А когда определяется себестоимость? Если в момент выбора товара в строке заказа продажи - тогда как система считает себестоимость товара, которого нет в наличии и он находится в стадии оформления заказа поставщику? Стандартная себестоимость нам поможет? А если метод списания - по серийным номерам (по партиям), а себестоимость по партиям (серийникам) сильно различается, и какой серийник будет отгружен определяет склад? Как тогда происходит контроль? Плюс, получается текущая себестоимость должна считаться онлайн. Т.е. Пакетное задание коррекции себестоимости должно быть запущено перед каждым запуском подобной проверки. Себестоимость штука не постоянная - Тот же фрахт её может изменить. И что же, наконец, происходит, когда себестоимость меняется в процессе обработки заказа. Только не говорите мне, что это не возможно.
Флеймер
6) Настройка иерархии утверждения в закупках.

Почему только в закупках? Расширяем функциональность. Контроль утверждения любого документа в системе. Еще контроль версий и workflow. Может быть это уже другой класс систем?

Флеймер
7) Контроль фондов по счетам или заказам на приобретение. Он у вас учитывает полученные но еще не оплаченные счета? Он у вас может проводится по отдельным бухгалтерским счетам и аналитикам.

Кто может проводится по отдельным счетам? Контроль? или полученные, но не оплаченные счета? Предложение оплат поставщикам + Резервирование денег (аналогичное резервированию товаров) на счете есть?

Флеймер
10) Учет перехода права собственности по закупке.
При переходе границы импортный товар становится нашим но не ложится на склад, а только на счет "Товары в пути". Или вы для этого будете плодить склады и гонять внутренними перемещениями?

Вот ведь интересная штука. А если в договоре прописан переход права собственности еще заграницей или в России на складе в новоурюпинске? С позиции Управленческого и бухгалтерского учета переход права собственности может происходить в разное время. И почему всего лишь счет "Товары в пути"? А если интересуют конкретные контрольные точки товара зарубежом, на каждой из которых товар может компоноваться, объединятся и дальше транспортироваться другим транспортным средством по другой цепочке? Да еще с механизом контроля графика доставки. И чтоб при переходе границы (не раньше, не позже) товару еще и ГТД присвоили и дальше этот ГТД должен неотрывно следовать за этим товаром.

Флеймер
11) Процесс выверки банковской выписки.
Отбор кредиторских счетов
Генерация платежек(импорт в клиент банк)
Экспорт банковской выписки (БВ)
Выверка БВ с платежками

12) Прогноз денежного потока.
Примерно так: Деньги на счетах + СФ дебитором - СФ кредиторов это все расписано по датам
Различные документы включаются опционально. Возможен прогноз с учетом трендов.

Хорошая функциональность. Подобных механизмов еще много можно привести. А прогнозирование вообще может далеко завести.

Могу сказать, что заявлять о наличии функциональности можно в "нормально" спроектированных западных системах. Но реально ли с этой функциональностью работать? Вот, например, стандартный Навижн (с которым я имею дело) всех вопросов что я задал или не делает, или делает через одно место. И не делает еще много чего. И много чего еще делает через одно место. И я даже не касался вопросов бухгалтерского учета. Хотя в общем все, о чем говорил Флеймер заявлено. И у OEBS куча недостатков, о которых просто никто не слышал, ибо это страшная маркетинговая тайна.