Добрый день!
Впервые обращаюсь за помощью на этом ресурсе, поэтому не до конца понимаю, какую информацию нужно предоставлять на первом этапе.
Я представляю фирму, которая специализируется на выполнении определленных работ на дому у заказчика.
Исходными данными является таблица Exell с заказами. Заказы поступают на электронную почту Оператора в течение дня в виде файлов Excell. Каждая строка таблицы соответствует одному заказу. Последовательность данных в ячейках не меняется.
Оператор переносит вручную строки с новыми заказами в общий реестр, к которому организован веб-доступ. Пример реестра прикрепляю. Реестр представляет из себя практически такую же таблицу, но добавлено несколько столбцов.
В одном из этих столбцов оператор из выпадающего списка выбирает исполнителя.
В другом указывается статус заказа. При введении нового заказа в этом поле устанавливается статус «новый» (желательно – в автоматическом режиме).
В третьем столбце указывается стоимость заказа для исполнителя – цифра подтягивается из другой заданной таблицы в соответствие номенклатурному номеру услуги и в общем случае – разная для каждого из исполнителей.
Еще один столбец – сумма оплаты НАМ от Заказчика за данную работу. Данные подтягиваются в соответствие номенклатурному номеру из третьей заданной таблицы. ЭТОТ СТОЛБЕЦ МОЖЕТ ВИДЕТЬ ТОЛЬКО ОПЕРАТОР. Исполнители его не видят.
Важно иметь возможность фильтроваться по исполнителю, наименованию услуги, статусу. Также важно иметь возможность поиска по значению в полях «номер заказа», «адрес» и т.д.
После внесения новых заказов и выбора исполнителей оператор нажимает кнопку «отправить в работу» (должна быть такая кнопка). При этом статус «новый» меняется на «передан в работу». После этого выбранные исполнители получают на эл. почту уведомления о том, что им передан заказ с предложением зайти на нашу страничку и принять его в работу.
Исполнитель заходит под своим логином на страничку, но при этом видит не все заказы, внесенные оператором, а только те, которые распределены на него. Для нас было бы удобно, если бы мы знали о том, что новые заказы просмотрены. Но Исполнитель руками переводит статус заказа в «принят в работу». После созвона с клиентом и согласовании даты выполнения заказа, исполнитель указывает согласованную дату в колонке примечаний (или специальной колонке для даты выполнения заказа). Выполнив заказ, исполнитель переводит статус в «выполнен». Также должны быть статусы «отказ при созвоне», «отказ по тех.причинам», «снят заказчиком».
В конце отчетного периода оператор переносит все заказы со статусом «выполнен» в Excell для формирования отчета для Заказчика. После проведения сверки с Заказчиком, оператор меняет статусы «выполнен» на «закрыт».
Исполнитель видит только свои заказы, при этом у него есть возможность фильтроваться по статусам (для формирования счета на оплату за «выполненные»).
Возможность вносить изменения в заказ есть только у оператора. Исполнитель может только поставить статусы, о которых я писал выше, дату выполнения заказа и заполнить поле примечания.
Готов подробно обсудить каждый этап всего процесса.
Budget: 14000 UAH Deadline: 20 days
Пишите, все обсудим! Опыт в C# .NET JS более 10 лет, множество промышленных проектов!
Всех благ!
Напишите в телеграм: talianchuk
Готов сделать на этом дизайне
19 February 2019
Павел, дизайн в данном случае вторичен. По ссылке, которую Вы дали, я не смог разобраться, какой функциал доступен. Если напишете немного подробнее, возможно, сориентируюсь.
Я не говорил что там функционал,я сказал что это дизайн, функционал это ваше тз
19 February 2019
Дизайн, как я уже говорил, вторичен. Готов ответить на вопросы по ТЗ, т.к. опыта составления подобный ТЗ не имею, поэтому допускаю, что задача описана не полностью, не однозначно, не корректно и т.д. Лучше спросите, потому что я не знаю, на чем нужно сделать акцент, чтобы Вы могли правильно оценить сроки и стоимость работ
Напишите в телеграм: talianchuk
Там все обсудим, если со мной будете работать получите то что хотите.
19 February 2019
мне комфортнее обсуждать проект на одной площадке. Вы же понимаете, что обсуждение идет не только с Вами)) Тем более, что я не пользуюсь телеграм.
Не совсем понял - у Вас сейчас это всё организовано при помощи Excel-файлов или это то, что требуется сделать? Я бы предложил сделать в виде веб-сервиса на каком-нибудь фреймворке (к примеру, yii).
19 February 2019
сейчас организовано в виде excel файлов. Заказы на исполнителей передаются по почте в абсолютно ручном режиме. Пока заказов было немного, это устраивало. Сейчас количество заказов увеличивается.
Пока мы готовим конфигурацию 1С под этот проект, нужно организовать возможность передачи и контроля выполнения заказов исполнителями. Не уверен, что фреймворк в этом случае обеспечит весь необходимый функционал, например, разграничение прав доступов исполнителей (они должны должны видеть только "свои" строки). Но я не являюсь специалистом, поэтому готов обсуждать разные варианты.
Заказы на исполнителей передаются по почте в абсолютно ручном режиме
Каким образом планируете передавать их в будущую систему - она также должна брать их с почты или будет как-то подругому?
Пока мы готовим конфигурацию 1С под этот проект
Система будет в дальнейшем взаимодействовать с 1с?
Не уверен, что фреймворк в этом случае обеспечит весь необходимый функционал, например, разграничение прав доступов исполнителей
Фреймворк для того и используется, чтобы на базовом каркасе создать необходимый функционал. Разграничение прав и другое можно сделать.
Я предлагаю сделать в виде веб-сервиса с доступом через браузер, а Вы сами в каком виде видите данную систему? У Вас есть какие-либо свои пожелания?
19 February 2019
Каким образом планируете передавать их в будущую систему - она также должна брать их с почты или будет как-то подругому?
исполнители будут получать заказы из веб-формы, которую я планирую сделать (возможно, с Вашей помощью). Каким образом будут обрабатывать заказ исполнители - меня не волнует. Я просто должен понимать, что заказ передан, принят в работу.
Оператор в будущем будет как и сейчас получать заказы по электронной почте и добавлять из в веб-форму (вручную или в автоматическом режиме)
19 February 2019
Система будет в дальнейшем взаимодействовать с 1с?
Сейчас об этом речь не идет. Возможно, это будет не 1С, а другая платформа. Привязываться не нужно.
19 February 2019
Фреймворк для того и используется, чтобы на базовом каркасе создать необходимый функционал. Разграничение прав и другое можно сделать.
Я предлагаю сделать в виде веб-сервиса с доступом через браузер, а Вы сами в каком виде видите данную систему? У Вас есть какие-либо свои пожелания?
Главная задача - возможность передавать заказы и сверяться по суммам оплаты (входящей и исходящей). Я вижу это как веб сервис. Оператор накидывает строки-заказы в таблицу. Исполнитель видит свои строки-заказы и сумму, которую получит за выполнение. Выполнил заказ - поменял статус на "выполнено". В конце отчетного периода взяли все заказы со статусом "выполнено", согласовали сумму к оплате, оплатили, поменяли статус на "закрыто/оплачено". Продолжаем работать по новым заказам. Как-то так
Я вижу это как веб сервис.
Я тоже считаю такой вариант наиболее подходящим.
Оператор накидывает строки-заказы в таблицу.
Думал, Вы хотели бы чтобы они автоматически загружались в систему из почты. Но можно и вручную добавлять в систему. Можете скинуть пример исходного файла заказов?
21 February 2019
Думал, Вы хотели бы чтобы они автоматически загружались в систему из почты. Но можно и вручную добавлять в систему. Можете скинуть пример исходного файла заказов?
Автоматическая загрузка - это конечно удобно, но тогда придется делать проверку на дублирование строк. Файл excel, который получает оператор, иногда содержит ТОЛЬКО новые заказы, а иногда и предыдущие, т.е. ранее полученные нами заказы.
делать проверку на дублирование строк
Можно сделать автоматическую проверку при добавлении заданий.
P.S. Пожалуйста, можете отвечать используя кнопку "Ответить" под моими сообщениями. А то мне уведомления об ответах не приходят.
21 February 2019
не могу понять, как здесь прикрепить файл
Загрузите куда-нибудь вроде гугл диска и сюда ссылку вставьте. Либо напишите мне в ЛС, дам почту, туда вышлете.
И ещё скиньте, пожалуйста, образцы номенклатурной таблицы для рассчёта стоимости и отчёта заказчику, который оператор будет делать в конце месяца.
Добрый день.
Недавно с колегой реализовывали похожую задачу для Интернет провайдера (учет заявок на ремонт, подключение, ведение базы, уровни доступа).
Если есть желание, возможно обсудить и сформировать более точно ТЗ
Можно тут, но голосом все таки будет лучше.
Скайп andrey.hodirev
21 February 2019
Андрей, добрый день!
С субботу будет удобно?
There is an active production platform with a catalog and automatic updates of external offers and prices. Stack: — Node.js / TypeScript; — PostgreSQL; — existing price refresh service and cron; — separate ready Python module for validation and selection of offers; — staging and production. It is necessary to make targeted improvements to the existing price refresh pipeline without completely rewriting the backend. MANDATORY SCOPE 1. Integration of the Python module — The Python module remains a separate component; — returns a structured result: offers, selected offer, statuses, and risk flags; — Node.js validates the result and performs a write to the database; — provide for error handling and partial/failed runs; — the legacy pipeline is not turned off until QA is completed. 2. Launch refresh by list Add launch: — by one slug/id; — by the provided list of slug/id. Assume CLI or existing service API. A new user interface is not required. 3. Shadow Mode New results must be recorded separately and not affect production until QA. Shadow fields required: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Expanding the existing offers table Add: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags or storage in existing JSON; — unique constraint to protect against duplicates. It is not required to create a new parallel offer system if the existing table can be safely expanded. 5. UPSERT, STALE, and DB transaction Replace the current DELETE → CREATE scheme: — UPSERT existing and new offers; — offers missing in the full successful snapshot are translated to STALE; — in case of API error, partial result, or incomplete snapshot, active offers should not become STALE; — updating offers, selected offer metadata, and shadow fields for one model is performed within one DB transaction; — in case of an error, a full rollback is performed. 6. Canonical-safe refresh Price refresh should not change: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Only offer, price, and shadow data are updated. 7. Preserving current cron logic Preserve: — existing cron; — rolling batches; — cooldown; — checking PRICE_REFRESH_MIN_DAYS before calling the external API; — legacy production pipeline until Shadow QA is completed. 8. Audit output One option is sufficient: — shadow columns in the existing admin table; or — CSV export. Minimum data: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. A new complex dashboard is not required. 9. Staging and QA — DB migrations; — staging deployment; — smoke test on 5 provided models; — then Shadow Mode on approximately 50 models; — fixing technical errors identified during these runs; — brief documentation of the Python → Node.js contract and rollback procedure. OPTIONALLY ASSESS SEPARATELY Simple technical promotion without a new UI: — promotion of one model by slug; — promotion of a list of slugs; — transferring confirmed shadow values to production; — technical check after rollout. RESULT — Pull Request; — DB migrations; — working integration Python → Node.js; — Shadow Mode; — UPSERT, STALE, and transactional update; — launch by slug/id; — staging deployment; — smoke-test results; — brief documentation; — at least 7 days of bug fixes for the implemented scope after acceptance. IN RESPONSE, INDICATE 1. Fixed price for the mandatory scope. 2. Separate cost for the promotion mechanism. 3. Timeline. 4. Hourly estimate. 5. When you are ready to start. 6. Experience with PostgreSQL transactions, migrations, and ingestion pipelines. 7. What questions need to be clarified before starting. 8. Whether staging, QA, migrations, and bug-fix period are included. Template responses without specific estimates will not be considered. Access to production is not provided at the first stage. Work begins with limited code review and staging.
A centralized server system for collecting and storing data from Planfix, 1C, Meta Ads, and Google Ads is needed, as well as a web dashboard for displaying and analyzing this data. All data, change history, calculations, and aggregated metrics must be stored exclusively in the server database. The dashboard should not store or duplicate business data. It must retrieve the necessary information from the server database via API according to user requests and display it in the form of KPIs, charts, tables, and detailed reports.
We are looking for support for a project based on Yii , we need to make edits and improvements to the database, there is partially a connection with the previous contractor .....................
It is necessary to migrate the database from CRM G-PLUS to MyChatBot Database volume - 26 thousand leads 2 funnels - Call center and Sales department with their own funnels Lead cards (besides name and number) have many different fields Leads also have voice recordings of calls. These also need to be transferred I expect an approximate amount and implementation timeline from the candidate
Create a dashboard for monitoring and analyzing the performance of the company's location network (branches) in Google Business Profile (GBP) through the official Google Business Profile API. Process via a script based on Google Apps Script (link to Google Sheets). Record data in Google Sheets (which serves as a database for Looker Studio). Update: Daily (with an indication of the last update date). Create a Google Cloud service account. The script runs once a day (trigger at 03:00 AM) and sends a request to the GBP API. It retrieves metrics for the previous day for each location (locationId). Records data in a flat format (row = unique combination of Date + Branch ID + Metrics). Key Performance Indicator CardsCard NameGBP MetricDynamic FormatProfile ViewsImpressions (Search + Maps)Percentage %, Sparkline (blue)CallsLocal Services Phone CallsPercentage %, Sparkline (green)Website ClicksWebsite ClicksPercentage %, Sparkline (purple)Direction RequestsDirection RequestsPercentage %, Sparkline (orange)Average RatingAverage Review RatingAbsolute change (e.g., +0.1), Sparkline (yellow)New ReviewsNew Reviews CountPercentage %, Sparkline (turquoise)