1. Принцип краудфайдинга и Совместной покупки (далее СП):
1.1. Представленные в интернете сервисы краудфайдинга построены по единой схеме и, судя по всему, на одной-двух платформах.
Особой разницы между благотворительными и инвестиционными версиями нет.
Механизм контроля инвестиций в проектах сводится к обещанию быть честными, иногда подкрепленному какими-либо регистрационными документами.
При внесении платы указываются регистрационные данные инвестора, которые, видимо, доступны учредителю проекта.
Дальнейшее сотрудничество происходит уже по личным каналам связи без участия краудфайдинговой платформы.
Примеры:
1.2. СП в основном построена по принципу форума или обычного интернет-магазина где имеется заказчик партии товара, который организовывает заказ у продавца и рассылку розничным покупателям.
Примеры:
http://forumodua.com/forumdisplay.php?f=186
http://forum.spscript.ru/ пример модуля для форума phpBB
2. Принцип проекта модуля СП и краудфайдинга:
2.1. Имеется партия одного товара определенного объема.
2.2. Имеется набор однотипных товаров по одинаковой цене, составляющих партию (например: обувь разных размеров).
2.3. Имеется товар не материального типа:
2.3.1. Стоимость равномерно распределена на каждого покупателя.
2.3.2. Покупатель может указать вносимую сумму.
В первом случае пользователь вносит часть суммы с возможностью выбора количества товара из партии.
Во втором – пользователь должен оплатить часть товара с возможностью выбора его типа или типов, при этом, они должны стать недоступны другим пользователям.
Третий случай - по принципу первого.
Отсюда следует, что максимальное количество пользователей, заказавших товар должно (может) равняться количеству товара в партии.
Кроме того необходима возможность приобретения всей партии товара одним пользователем.
Необходимо предусмотреть возможность отказа от приобретения товара до окончания формирования покупки с возвратом денег (вероятно, с удержанием неустойки).
В случае, если заказ не сформирован до окончания срока, пользователь имеет право на полное возмещение внесенной им сумы.
3. Возможный список настроек для товара:
3.1. Количество пользователей, необходимое для оформления покупки (количество единиц товара в партии, количество долей).
3.2. Дата окончания формирования покупки.
3.3. Тип СП (см. пункт 2.).
3.4. При 2 типе СП необходима возможность настройки типов товара, входящих в партию.
3.5. Общая стоимость партии.
3.6. Возможность выбора способа приобретения товара: штук, долей, указание конкретной сумы.
3.7. При редактировании партии, возможность просмотра уже оплативших пользователей, предположительно, с возможностью манипуляции этим списком.
4. Пользовательские функции:
Пользователь должен:
4.1. Видеть в личном кабинете список товаров, которые оплатил, но еще не получил.
4.2. Видеть срок окончания формирования заказа и количество подписавшихся на него.
4.3. Вероятно, иметь возможность отказаться от покупки.
4.4. Получить уведомление о выполнении заказа или его отмене.
5. Реализация:
5.1. Профессиональный дизайн интерфейса за много миллионов баксов:



5.2. База данных:
К таблице товаров:
- Поле идентификации is_SP;
- Количество единиц (0-ввод суммы вручную заказчиком);
- Дата окончания формирования заказа (Null – бессрочный, но надо ли такое?);
Поле со списком id пользователей, присоединившихся к заказу.
К таблицам заказов, карточек пользователей тоже необходимо что-то прилепить.
5.3. Контроллеры и представление:
- Модификация контроллера для раздела заказов в аккаунтах;
- Модификация контроллера вывода товара с учетом новых возможностей;
- Модификация контроллеров вывода списка товаров с учетом новых возможностей.
5.4. Модель:
- Модификация модели для товара с учетом новых полей;
- Модификация модели для заказов.








