1. Внимание! Строго запрещен ап своих тем чаще чем раз в 7 дней! Если ваши услуги/товары никому не интересны - UP вам не поможет! Хотите чтобы тема была сверху всегда - оплачивайте закрепление!

[Работа] Ищу программиста для платной поддержки и доработки ряда модулей

Тема в разделе "Рекламный раздел", создана пользователем akigleo, 6 фев 2013.

Информация :
  1. akigleo

    akigleo

    Регистр.:
    7 фев 2010
    Сообщения:
    264
    Симпатии:
    27
    Есть действующий магазин на OpenCart, которому нужно подправить ряд модулей и нужны еще доработки, связанные с разработкой дополнительных php скриптов.
    Вводное:
    --------------------
    Есть ряд транспортных сайтов, которые собирают запросы на транспортные перевозки. На этих сайтах стоит форма, которая отправляет заполненные заявки на определенный почтовый ящик. Далее эти заявки парсятся скриптом, попадают в магазин и продаются заинтересованным транспортникам оптом и в розницу.
    Таким образом, товаром является информация, а именно полная заявка на перевозку. В магазине отображается ее частичное содержимое без контактных данных. После оплаты выбранных заявок покупателю отправляется на 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. Ориентировочная стоимость такая-то, срок исполнения такой-то».
    Конечно, я понимаю, что для формирования точной цифры потребуется покопаться и проанализировать текущую реализацию магазина.
    Однако не хочется взаимно терять время, если прикидочная стоимость выполнения работ заведомо неприемлемая.