Битрикс

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.

Technical Task: Website Recovery from BackupType of work: rollback/recovery of the website, fixing errors after a failed updatePlatform: the site operates on two systems, OpenCart and WordPress (two separate admin panels) Hosting: ukraine.com.uaProblem DescriptionOn 17.07.2026, the filter module was updated. The update was unsuccessful, and the site had to be rolled back to the previous version. However, during the rollback, the site partially broke:some pages do not work;some buttons do not work;some important functionality has stopped working.TaskFully restore the website from the backup dated 16.07.2026 to a fully operational state. The restoration must cover both systems (OpenCart and WordPress):website files;databases;hosting settings;all interface elements and functionality.Result: the website operates without failures, all pages, buttons, and functions are correct on both platforms.Requirements for the PerformerBefore starting work, make a backup of the current (broken) state of the website.Consider the connection between OpenCart and WordPress (shared database, integration, data synchronization, etc.), check that both systems work coherently after the rollback.After restoration, conduct a check of key pages and functions on both platforms.Acceptance of WorkAfter completing the task, a minimum of 4 days is expected for the client to check the website's operation. Final acceptance will occur after confirming stable operation.

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