akigleo
Постоялец
- Регистрация
- 7 Фев 2010
- Сообщения
- 378
- Реакции
- 114
- Автор темы
- #1
Есть действующий Для просмотра ссылки Войди или Зарегистрируйся на OpenCart, которому нужно подправить ряд модулей и нужны еще доработки, связанные с разработкой дополнительных php скриптов.
Жду предложение от исполнителя в примерно таком виде:
«Готов взяться за доработку модулей. Могу сделать Задача1, Задача2, П.1…П9. Ориентировочная стоимость такая-то, срок исполнения такой-то».
Конечно, я понимаю, что для формирования точной цифры потребуется покопаться и проанализировать текущую реализацию магазина.
Однако не хочется взаимно терять время, если прикидочная стоимость выполнения работ заведомо неприемлемая.
Вводное:
--------------------
Есть ряд транспортных сайтов, которые собирают запросы на транспортные перевозки. На этих сайтах стоит форма, которая отправляет заполненные заявки на определенный почтовый ящик. Далее эти заявки парсятся скриптом, попадают в магазин и продаются заинтересованным транспортникам оптом и в розницу.
Таким образом, товаром является информация, а именно полная заявка на перевозку. В магазине отображается ее частичное содержимое без контактных данных. После оплаты выбранных заявок покупателю отправляется на e-mailполный текст заявок с контактными данными. Далее он сможет связываться с грузоотправителем напрямую.
К сожалению магазин сделан по минимуму. Многое не успелось из-за переезда программиста в другой город. Сейчас он занимается совершенно другими вопросами, поэтому дергать его смысла нет. Кроме того, человек только разбирался в php, поэтому многое делал несовершенно и долго.
--------------------
Что нужно:
-------------------
Задача 1 – усовершенствовать/подправить парсер почтовых сообщений в магазин.
Написан парсер, который запускается по cronи проверяет почтовый ящик с некоторой периодичностью. Если находит там письмо с заполненной формой на перевозку, то пытается его разобрать на запчасти. То есть ищет флаг-заголовок, например, “cargo” и все что вбито до следующего флага-заголовка заносит в определенную ячейку. И так по всем флагам. В результате формируется название и описание анонса товара для отображения в магазине без указания контактных данных. Сам текст письма сохраняется под определенным именем file.txt – это собственно и есть товар (там все описание + контактные данные отправителя).
Проблема: парсятся письма с почтовых форм нескольких сайтов. Формы со временем немного видоизменились (последовательность флагов) и парсер перестал их нормально и уверенно обрабатывать, хотя имена флагов не менялись. Вероятно, сам парсер несовершенен и требует донастройки под текущие реалии.
------------------
Задача 2 – прикрутить и настроить модуль подписки.
Смысл заключается в том, чтобы дать возможность потенциальному клиенту зарегистрироваться, настроить подписку на получение всех анонсов товаров в одном письме с определенной периодичностью. Например, раз в неделю или раз в день. То есть заказчик в своем кабинете устанавливает получать/не получать анонсы и периодичность получения. Далее, если его какие-то заявки заинтересовали, то он уже переходит в магазин и их оплачивает. Конечно, здорово было бы чтобы прямо в письме он смог выбрать нужные и перейдя по ссылке сразу увидел их в корзине. Но маловероятно, что это реализуемо.
Выше описаны текущие насущные задачи для внедрения. Ниже перечислены пожелания и алгоритм работы, по которой должен бы работать магазин.
1. По крону или при заходе на сайт, допустим, каждого 10-го посетителя, пусть проверяется закрепленный за магазином почтовый ящик. Если поступила новая заявка, то она парсится и заносится в базу магазина и далее соответственно попадает на прилавок.
2. Цена на заявки в магазине устанавливается автоматически согласно некоторым правилам. Например, если заявка в базе находится до 3 дней, то она стоит 30р; если от 4 до 7 дней – 25р; если от 7 до 30 дней – 20р; если от 1 месяца до 6 месяцев – 15р; старше года – 10 р; старше 2-х лет – 5р и т.п.
Само собой должен быть редактируемый курс пересчета между WMRи другими WMвалютами.
3. Важно, чтобы в магазине были хорошие фильтры и поиск, чтобы пользователь мог удобно работать с базой. То есть отобразить все заявки за определенный период, и/или лучше привязаться к определенному ключевому слову(ам), содержащемуся в заявке. Например, отобрать все заявки с января 2012 по май 2012, содержащие ключевые слова «Петербург» или «СПБ» или «Peterburg» . Последнее важно потому, что заранее сложно предугадать какое именно будет написание подобного слова обозначающего одно и то же.
4. Нужно, чтобы в магазине была возможность работать с разными тарифными планами.
А) Покупателем может быть произвольный посетитель, который зашел на сайт, отобрал нужный товар, оплатил и получил выборку базы.
Б) Покупатель подписался на месячную подписку, допустим за 3000р и получает все запросы, залетевшие на сайт по мере их поступления без ограничения на количество в течении оплаченного периода.
Преимуществом плана Б должно быть практически мгновенная пересылка запроса заказчику такого абонемента, в то время как по плану А запросы публикуются на сайте только на следующий день.
5. Желательно предусмотреть возможность подписки. То есть зарегистрированный пользователь магазина пусть получает анонсы, поступивших новых заявок. Допустим, в ПУ своей учетной записи пусть он настроил получение анонсов раз в 4 дня. Таким образом, скрипт магазина должен раз в 4 дня слать ему одно письмо с анонсами заявок (вид тот же, как они отображаются на сайте) и со ссылкой на заказ. Если ему что-то понравилось, чтобы он мог перейти по ссылке и разместить заказ.
Конечно, такая подписка должна быть подтверждаемой и с возможностью отписки.
6. Заявки и все с ними связанное.
- Залетевшие заявки пусть помечаются в базе как «не просмотренные». Модератор пусть заходит на сайт с удобной ему периодичностью. Например, раз в 1-2 дня и через свою админскую учетную запись дает команду отобразить все заявки с пометкой «не просмотренные» с целью отсева неудачно заполненных или агрессивных (вдруг найдется плохой человек и заполнит заявку рекламой, бранными словами и т.п.). Т.о., «хорошие» он утверждает, а «плохие» корректирует или удаляет.
- Вполне вероятно, что какая-то заявка потеряла актуальность со временем. Например, кому-то нужно было перевести личные вещи из порта А в порт Б. Это не коммерческий запрос на регулярные перевозки. Соответственно такой грузоотправитель может быть не доволен, что его регулярно «долбают» предложениями на перевозку, а ему это давно не актуально. Плохо это и покупателю, который платит за пустышку». Поэтому нужно предусмотреть форму для отправки сообщения модератору, что заявка номер такой-то более не актуальна, просим ее удалить
7. Желателен доп. вход для продавцов. Смысл следующий: многие транспортники не могут прорабатывать непрофильные для них применения. Например, кто-то работает исключительно по СПБ и запросы по Новороссийску для них не нужны. Поэтому какой-то посетитель, работающий в транспортной компании, может зарегистрироваться Продавцом и выставлять заявки на условиях, допустим, 50% прибыли с продажи такой заявки. Цена на заявку пусть формируется согласно правил системы. В учетной записе такого продавца должна быть история продаж и кнопка запроса на вывод средств.
8. Желательно прикрутить к магазину модуль массового импорта статей. Тогда можно будет добавить массу статей транспортной направленности, чтобы получать больше посетителей по НЧ запросам.
9. Возможно, имеет смысл прикрутить к магазину какие-то дополнительные модули. К примеру, я могу просто не знать об их существовании, а для специалиста очевидны какие-то выгоды их внедрения. Буду благодарен за совет и профинансирую установку, если будет предложено что-то стоящее для озвученных выше задач.
Выше описана модель работы магазина без привязки к конкретному скрипту. Допускаю, что текущий выбор не оптимальный. Однако нужно обсудить, что можно реализовать из пунктов выше на базе текущего скрипта и оценить насколько это затратно. Важно, чтобы стоимость вопроса не превысила целесообразность.
Если текущий скрипт магазина плохо приспособлен в принципе под поставленные задачи, то можно рассмотреть возможность смены скрипта магазина. В любом случае скрипт магазина должен быть с хорошей админкой, чтобы можно было редактировать записи, добавлять/удалять страницы и т.п.
Магазин должен быть реализован на известном, безопасном, проверенным временем скрипте, который бы был достаточно известен в Рунет, развивался и имел соответствующий support. Потребуются так же доп. самописные или подкорректированные стандартные модули магазина под специфику применения. Полностью самопис не подходит в принципе по очевидным причинам.
--------------------
Есть ряд транспортных сайтов, которые собирают запросы на транспортные перевозки. На этих сайтах стоит форма, которая отправляет заполненные заявки на определенный почтовый ящик. Далее эти заявки парсятся скриптом, попадают в магазин и продаются заинтересованным транспортникам оптом и в розницу.
Таким образом, товаром является информация, а именно полная заявка на перевозку. В магазине отображается ее частичное содержимое без контактных данных. После оплаты выбранных заявок покупателю отправляется на e-mailполный текст заявок с контактными данными. Далее он сможет связываться с грузоотправителем напрямую.
К сожалению магазин сделан по минимуму. Многое не успелось из-за переезда программиста в другой город. Сейчас он занимается совершенно другими вопросами, поэтому дергать его смысла нет. Кроме того, человек только разбирался в php, поэтому многое делал несовершенно и долго.
--------------------
Что нужно:
-------------------
Задача 1 – усовершенствовать/подправить парсер почтовых сообщений в магазин.
Написан парсер, который запускается по cronи проверяет почтовый ящик с некоторой периодичностью. Если находит там письмо с заполненной формой на перевозку, то пытается его разобрать на запчасти. То есть ищет флаг-заголовок, например, “cargo” и все что вбито до следующего флага-заголовка заносит в определенную ячейку. И так по всем флагам. В результате формируется название и описание анонса товара для отображения в магазине без указания контактных данных. Сам текст письма сохраняется под определенным именем file.txt – это собственно и есть товар (там все описание + контактные данные отправителя).
Проблема: парсятся письма с почтовых форм нескольких сайтов. Формы со временем немного видоизменились (последовательность флагов) и парсер перестал их нормально и уверенно обрабатывать, хотя имена флагов не менялись. Вероятно, сам парсер несовершенен и требует донастройки под текущие реалии.
------------------
Задача 2 – прикрутить и настроить модуль подписки.
Смысл заключается в том, чтобы дать возможность потенциальному клиенту зарегистрироваться, настроить подписку на получение всех анонсов товаров в одном письме с определенной периодичностью. Например, раз в неделю или раз в день. То есть заказчик в своем кабинете устанавливает получать/не получать анонсы и периодичность получения. Далее, если его какие-то заявки заинтересовали, то он уже переходит в магазин и их оплачивает. Конечно, здорово было бы чтобы прямо в письме он смог выбрать нужные и перейдя по ссылке сразу увидел их в корзине. Но маловероятно, что это реализуемо.
Выше описаны текущие насущные задачи для внедрения. Ниже перечислены пожелания и алгоритм работы, по которой должен бы работать магазин.
1. По крону или при заходе на сайт, допустим, каждого 10-го посетителя, пусть проверяется закрепленный за магазином почтовый ящик. Если поступила новая заявка, то она парсится и заносится в базу магазина и далее соответственно попадает на прилавок.
2. Цена на заявки в магазине устанавливается автоматически согласно некоторым правилам. Например, если заявка в базе находится до 3 дней, то она стоит 30р; если от 4 до 7 дней – 25р; если от 7 до 30 дней – 20р; если от 1 месяца до 6 месяцев – 15р; старше года – 10 р; старше 2-х лет – 5р и т.п.
Само собой должен быть редактируемый курс пересчета между WMRи другими WMвалютами.
3. Важно, чтобы в магазине были хорошие фильтры и поиск, чтобы пользователь мог удобно работать с базой. То есть отобразить все заявки за определенный период, и/или лучше привязаться к определенному ключевому слову(ам), содержащемуся в заявке. Например, отобрать все заявки с января 2012 по май 2012, содержащие ключевые слова «Петербург» или «СПБ» или «Peterburg» . Последнее важно потому, что заранее сложно предугадать какое именно будет написание подобного слова обозначающего одно и то же.
4. Нужно, чтобы в магазине была возможность работать с разными тарифными планами.
А) Покупателем может быть произвольный посетитель, который зашел на сайт, отобрал нужный товар, оплатил и получил выборку базы.
Б) Покупатель подписался на месячную подписку, допустим за 3000р и получает все запросы, залетевшие на сайт по мере их поступления без ограничения на количество в течении оплаченного периода.
Преимуществом плана Б должно быть практически мгновенная пересылка запроса заказчику такого абонемента, в то время как по плану А запросы публикуются на сайте только на следующий день.
5. Желательно предусмотреть возможность подписки. То есть зарегистрированный пользователь магазина пусть получает анонсы, поступивших новых заявок. Допустим, в ПУ своей учетной записи пусть он настроил получение анонсов раз в 4 дня. Таким образом, скрипт магазина должен раз в 4 дня слать ему одно письмо с анонсами заявок (вид тот же, как они отображаются на сайте) и со ссылкой на заказ. Если ему что-то понравилось, чтобы он мог перейти по ссылке и разместить заказ.
Конечно, такая подписка должна быть подтверждаемой и с возможностью отписки.
6. Заявки и все с ними связанное.
- Залетевшие заявки пусть помечаются в базе как «не просмотренные». Модератор пусть заходит на сайт с удобной ему периодичностью. Например, раз в 1-2 дня и через свою админскую учетную запись дает команду отобразить все заявки с пометкой «не просмотренные» с целью отсева неудачно заполненных или агрессивных (вдруг найдется плохой человек и заполнит заявку рекламой, бранными словами и т.п.). Т.о., «хорошие» он утверждает, а «плохие» корректирует или удаляет.
- Вполне вероятно, что какая-то заявка потеряла актуальность со временем. Например, кому-то нужно было перевести личные вещи из порта А в порт Б. Это не коммерческий запрос на регулярные перевозки. Соответственно такой грузоотправитель может быть не доволен, что его регулярно «долбают» предложениями на перевозку, а ему это давно не актуально. Плохо это и покупателю, который платит за пустышку». Поэтому нужно предусмотреть форму для отправки сообщения модератору, что заявка номер такой-то более не актуальна, просим ее удалить
7. Желателен доп. вход для продавцов. Смысл следующий: многие транспортники не могут прорабатывать непрофильные для них применения. Например, кто-то работает исключительно по СПБ и запросы по Новороссийску для них не нужны. Поэтому какой-то посетитель, работающий в транспортной компании, может зарегистрироваться Продавцом и выставлять заявки на условиях, допустим, 50% прибыли с продажи такой заявки. Цена на заявку пусть формируется согласно правил системы. В учетной записе такого продавца должна быть история продаж и кнопка запроса на вывод средств.
8. Желательно прикрутить к магазину модуль массового импорта статей. Тогда можно будет добавить массу статей транспортной направленности, чтобы получать больше посетителей по НЧ запросам.
9. Возможно, имеет смысл прикрутить к магазину какие-то дополнительные модули. К примеру, я могу просто не знать об их существовании, а для специалиста очевидны какие-то выгоды их внедрения. Буду благодарен за совет и профинансирую установку, если будет предложено что-то стоящее для озвученных выше задач.
Выше описана модель работы магазина без привязки к конкретному скрипту. Допускаю, что текущий выбор не оптимальный. Однако нужно обсудить, что можно реализовать из пунктов выше на базе текущего скрипта и оценить насколько это затратно. Важно, чтобы стоимость вопроса не превысила целесообразность.
Если текущий скрипт магазина плохо приспособлен в принципе под поставленные задачи, то можно рассмотреть возможность смены скрипта магазина. В любом случае скрипт магазина должен быть с хорошей админкой, чтобы можно было редактировать записи, добавлять/удалять страницы и т.п.
Магазин должен быть реализован на известном, безопасном, проверенным временем скрипте, который бы был достаточно известен в Рунет, развивался и имел соответствующий support. Потребуются так же доп. самописные или подкорректированные стандартные модули магазина под специфику применения. Полностью самопис не подходит в принципе по очевидным причинам.
«Готов взяться за доработку модулей. Могу сделать Задача1, Задача2, П.1…П9. Ориентировочная стоимость такая-то, срок исполнения такой-то».
Конечно, я понимаю, что для формирования точной цифры потребуется покопаться и проанализировать текущую реализацию магазина.
Однако не хочется взаимно терять время, если прикидочная стоимость выполнения работ заведомо неприемлемая.