7
0
Бюджет: 14000 UAH Термін: 20 днів
Пишите, все обсудим! Опыт в C# .NET JS более 10 лет, множество промышленных проектов!
Всех благ!
У списку не показані ставки, приховані замовником чи фрилансером з Plus, а також ставки, що порушують правила
Ставки поки відсутні
Фрилансери знайомляться з завданням — скоро тут з'являться пропозиції.
-
Павел Программист 18 лютого 2019Напишите в телеграм: talianchuk
Готов сделать на этом дизайне
-
Андрій Кононенко
19 лютого 2019
Павел, дизайн в данном случае вторичен. По ссылке, которую Вы дали, я не смог разобраться, какой функциал доступен. Если напишете немного подробнее, возможно, сориентируюсь.
-
Павел Программист 19 лютого 2019
Я не говорил что там функционал,я сказал что это дизайн, функционал это ваше тз
-
Андрій Кононенко
19 лютого 2019
Дизайн, как я уже говорил, вторичен. Готов ответить на вопросы по ТЗ, т.к. опыта составления подобный ТЗ не имею, поэтому допускаю, что задача описана не полностью, не однозначно, не корректно и т.д. Лучше спросите, потому что я не знаю, на чем нужно сделать акцент, чтобы Вы могли правильно оценить сроки и стоимость работ
-
Павел Программист 19 лютого 2019
Напишите в телеграм: talianchuk
Там все обсудим, если со мной будете работать получите то что хотите. -
Андрій Кононенко
19 лютого 2019
мне комфортнее обсуждать проект на одной площадке. Вы же понимаете, что обсуждение идет не только с Вами)) Тем более, что я не пользуюсь телеграм.
-
Артем Демин 19 лютого 2019Не совсем понял - у Вас сейчас это всё организовано при помощи Excel-файлов или это то, что требуется сделать? Я бы предложил сделать в виде веб-сервиса на каком-нибудь фреймворке (к примеру, yii).
-
Андрій Кононенко
19 лютого 2019
сейчас организовано в виде excel файлов. Заказы на исполнителей передаются по почте в абсолютно ручном режиме. Пока заказов было немного, это устраивало. Сейчас количество заказов увеличивается.
Пока мы готовим конфигурацию 1С под этот проект, нужно организовать возможность передачи и контроля выполнения заказов исполнителями. Не уверен, что фреймворк в этом случае обеспечит весь необходимый функционал, например, разграничение прав доступов исполнителей (они должны должны видеть только "свои" строки). Но я не являюсь специалистом, поэтому готов обсуждать разные варианты.
-
Артем Демин 19 лютого 2019
Заказы на исполнителей передаются по почте в абсолютно ручном режиме
Каким образом планируете передавать их в будущую систему - она также должна брать их с почты или будет как-то подругому?
Пока мы готовим конфигурацию 1С под этот проект
Система будет в дальнейшем взаимодействовать с 1с?
Не уверен, что фреймворк в этом случае обеспечит весь необходимый функционал, например, разграничение прав доступов исполнителей
Фреймворк для того и используется, чтобы на базовом каркасе создать необходимый функционал. Разграничение прав и другое можно сделать.
Я предлагаю сделать в виде веб-сервиса с доступом через браузер, а Вы сами в каком виде видите данную систему? У Вас есть какие-либо свои пожелания?
-
Андрій Кононенко
19 лютого 2019
Каким образом планируете передавать их в будущую систему - она также должна брать их с почты или будет как-то подругому?
исполнители будут получать заказы из веб-формы, которую я планирую сделать (возможно, с Вашей помощью). Каким образом будут обрабатывать заказ исполнители - меня не волнует. Я просто должен понимать, что заказ передан, принят в работу.
Оператор в будущем будет как и сейчас получать заказы по электронной почте и добавлять из в веб-форму (вручную или в автоматическом режиме)
-
Андрій Кононенко
19 лютого 2019
Система будет в дальнейшем взаимодействовать с 1с?
Сейчас об этом речь не идет. Возможно, это будет не 1С, а другая платформа. Привязываться не нужно.
-
Андрій Кононенко
19 лютого 2019
Фреймворк для того и используется, чтобы на базовом каркасе создать необходимый функционал. Разграничение прав и другое можно сделать.
Я предлагаю сделать в виде веб-сервиса с доступом через браузер, а Вы сами в каком виде видите данную систему? У Вас есть какие-либо свои пожелания?
Главная задача - возможность передавать заказы и сверяться по суммам оплаты (входящей и исходящей). Я вижу это как веб сервис. Оператор накидывает строки-заказы в таблицу. Исполнитель видит свои строки-заказы и сумму, которую получит за выполнение. Выполнил заказ - поменял статус на "выполнено". В конце отчетного периода взяли все заказы со статусом "выполнено", согласовали сумму к оплате, оплатили, поменяли статус на "закрыто/оплачено". Продолжаем работать по новым заказам. Как-то так
-
Артем Демин 20 лютого 2019
Я вижу это как веб сервис.
Я тоже считаю такой вариант наиболее подходящим.
Оператор накидывает строки-заказы в таблицу.
Думал, Вы хотели бы чтобы они автоматически загружались в систему из почты. Но можно и вручную добавлять в систему. Можете скинуть пример исходного файла заказов?
-
Андрій Кононенко
21 лютого 2019
Думал, Вы хотели бы чтобы они автоматически загружались в систему из почты. Но можно и вручную добавлять в систему. Можете скинуть пример исходного файла заказов?
Автоматическая загрузка - это конечно удобно, но тогда придется делать проверку на дублирование строк. Файл excel, который получает оператор, иногда содержит ТОЛЬКО новые заказы, а иногда и предыдущие, т.е. ранее полученные нами заказы.
-
Артем Демин 22 лютого 2019
делать проверку на дублирование строк
Можно сделать автоматическую проверку при добавлении заданий.
P.S. Пожалуйста, можете отвечать используя кнопку "Ответить" под моими сообщениями. А то мне уведомления об ответах не приходят.
-
Андрій Кононенко
21 лютого 2019
не могу понять, как здесь прикрепить файл
-
Артем Демин 22 лютого 2019
Загрузите куда-нибудь вроде гугл диска и сюда ссылку вставьте. Либо напишите мне в ЛС, дам почту, туда вышлете.
-
Артем Демин 22 лютого 2019
И ещё скиньте, пожалуйста, образцы номенклатурной таблицы для рассчёта стоимости и отчёта заказчику, который оператор будет делать в конце месяца.
-
Андрей Ходырев 21 лютого 2019Добрый день.
Недавно с колегой реализовывали похожую задачу для Интернет провайдера (учет заявок на ремонт, подключение, ведение базы, уровни доступа).
Если есть желание, возможно обсудить и сформировать более точно ТЗ
Можно тут, но голосом все таки будет лучше.
Скайп andrey.hodirev -
Андрій Кононенко
21 лютого 2019
Андрей, добрый день!
С субботу будет удобно?
Актуальні фриланс-проєкти в категорії Бази даних та SQL
Не вказано
47 ставок
Є діюча production-платформа з каталогом та автоматичним оновленням зовнішніх пропозицій і цін. Стек: — Node.js / TypeScript; — PostgreSQL; — існуючий сервіс оновлення цін і cron; — окремий готовий Python-модуль валідації та вибору пропозицій; — staging і production. Необхідно точково доопрацювати існуючий pipeline оновлення цін без повного переписування backend. ОБОВ'ЯЗКОВИЙ СКОП 1. Інтеграція Python-модуля — Python-модуль залишається окремим компонентом; — повертає структурований результат: offers, selected offer, statuses та risk flags; — Node.js валідує результат і виконує запис у БД; — передбачити обробку помилок і partial/failed runs; — legacy pipeline не відключається до завершення QA. 2. Запуск оновлення за списком Додати запуск: — по одному slug/id; — по переданому списку slug/id. Допустимо CLI або існуючий службовий API. Новий користувацький інтерфейс не потрібен. 3. Shadow Mode Нові результати повинні записуватися окремо і не впливати на production до QA. Потрібні shadow-поля: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Розширення існуючої таблиці offers Додати: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags або зберігання в існуючому JSON; — unique constraint для захисту від дублів. Нову паралельну систему пропозицій створювати не потрібно, якщо існуючу таблицю можна безпечно розширити. 5. UPSERT, STALE і транзакція БД Замінити поточну схему DELETE → CREATE: — UPSERT існуючих і нових пропозицій; — відсутні в повному успішному snapshot пропозиції переводяться в STALE; — при API error, partial result або незавершеному snapshot активні пропозиції не повинні ставати STALE; — оновлення пропозицій, metadata вибраної пропозиції та shadow fields по одній моделі виконується всередині однієї транзакції БД; — при помилці виконується повний rollback. 6. Canonical-safe refresh Оновлення цін не повинно змінювати: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Оновлюються тільки offer, price і shadow data. 7. Збереження поточної cron-логіки Зберегти: — existing cron; — rolling batches; — cooldown; — перевірку PRICE_REFRESH_MIN_DAYS до виклику зовнішнього API; — legacy production pipeline до завершення Shadow QA. 8. Audit output Достатньо одного варіанту: — shadow-колонки в існуючій admin table; або — CSV export. Мінімальні дані: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. Новий складний dashboard не потрібен. 9. Staging і QA — DB migrations; — staging deployment; — smoke test на 5 переданих моделях; — потім Shadow Mode приблизно на 50 моделях; — виправлення технічних помилок, виявлених під час цих прогонів; — коротка документація контракту Python → Node.js та rollback procedure. ОПЦІОНАЛЬНО ОЦІНИТИ ОКРЕМО Простий технічний promotion без нового UI: — promotion однієї моделі по slug; — promotion списку slug; — перенесення підтверджених shadow values в production; — технічна перевірка після rollout. РЕЗУЛЬТАТ — Pull Request; — DB migrations; — робоча інтеграція Python → Node.js; — Shadow Mode; — UPSERT, STALE і транзакційне оновлення; — запуск по slug/id; — staging deployment; — smoke-test results; — коротка документація; — не менше 7 днів виправлення багів по реалізованому scope після приймання. В ОТКЛИКУ УКАЗАТИ 1. Фіксована ціна за обов'язковий scope. 2. Окрему вартість механізму promotion. 3. Термін. 4. Оцінку годин. 5. Коли готові почати. 6. Досвід з PostgreSQL transactions, migrations та ingestion pipelines. 7. Які питання потрібно уточнити до початку. 8. Включені чи staging, QA, migrations та період виправлення помилок. Шаблонні відповіді без конкретної оцінки розглядатися не будуть. Доступ до production на першому етапі не надається. Робота починається з обмеженого code review та staging.
Не вказано
39 ставок
Потрібно розробити централізовану серверну систему збору та зберігання даних із Planfix, 1С, Meta Ads і Google Ads, а також веб-дашборд для їх відображення та аналізу. Усі дані, історія змін, розрахунки та агреговані показники повинні зберігатися виключно в серверній базі даних. Дашборд не повинен зберігати або дублювати бізнес-дані. Він має отримувати необхідну інформацію із серверної бази через API відповідно до запитів користувача та відображати її у вигляді KPI, графіків, таблиць і деталізованих звітів.
1000 UAH
48 ставок
Щукаємо для підтримки проекта на базі Yii , треба вносити правки та доопрацювання бази , частково є звязок з попереднім виконавцем .....................
Не вказано
39 ставок
Потрібно зробити міграцію бази з CRM G-PLUS на MyChatBot Обєм бази - 26 тис. лідів 2 воронки - Кол центр та Відділ продажу зі своїми вирвами Картки лідів (крім імені та номеру) мають багато різних полів Ліди також мають голосові записи дзвінків. Їх також потрібно перенести Від кандидата очікую орієнтовну суму та терміни реалізації
Не вказано
29 ставок
Створити дашборд для моніторингу та аналізу ефективності мережі локацій (філій) компанії у Google Business Profile (GBP). через офіційний Google Business Profile API. Обробкачерез Скрипт на базі Google Apps Script (підв'язати до Google Таблиці). Запис даних у Google Таблиця (яка виступає як база даних для Looker Studio). Оновлення: Щодня (з індикацією дати останнього оновлення).Створити сервісний акаунт Google Cloud Скрипт раз на добу (тригер о 03:00 ночі) надсилає запит до GBP API. Отримує метрики за вчорашній день по кожній локації (locationId). Записує дані в таблицю в плоскому форматі (рядок = унікальне поєднанняДата + ID Філії + Метрики). Картки ключових показниківНазва карткиМетрика GBPФормат динамікиПерегляди профілюImpressions (Search + Maps)Відсоток %, Sparkline (синій)ДзвінкиLocal Services Phone CallsВідсоток %, Sparkline (зелений)Переходи на сайтWebsite ClicksВідсоток %, Sparkline (фіолетовий)Побудова маршрутівDirection RequestsВідсоток %, Sparkline (помаранчевий)Середній рейтингAverage Review RatingАбсолютна зміна (наприклад, +0.1), Sparkline (жовтий)Нові відгукиNew Reviews CountВідсоток %, Sparkline (бірюзовий)
Завантаження...
Завантаження...