Work with BAS CORP

Project Description: We are looking for an experienced 1C developer to implement CRM functionality (the "Requests" module) in a non-standard 1C configuration. The database is custom, successfully operating and developing for 7 years. Improvements are being made under the supervision of a Database Architect (in-house 1C programmer), who will act as the project curator, approve the architecture, and conduct Code Review. We are engaged in the sale of tires, wheels, and tire fitting services. The goal of the module is to consolidate all incoming channels (Asterisk, website, Telegram bot, messenger aggregator, visits) into a single lead processing system. What needs to be done: New document "Request" — the central workspace for the manager (fields, status funnel, UTM tags, tire selection form). "Pickup Request" module — accounting for pickup points, time slots, and product readiness statuses. Integration logic with Asterisk — automatic linking of incoming/outgoing calls and audio recordings to Requests by phone number and time. Interaction history and KPI — chronological register of contacts (calls, messages), calculation of time taken to work and deal cycle. Input based on — linking Requests with invoices, tire fitting appointments, storage forms, and waybills. Interface — a unified CRM journal with color indication, filters, and a history tab in the Client card. A detailed and thoroughly developed Technical Specification (TS) will be provided to candidates who pass the initial selection. Our requirements for the performer: Excellent knowledge of managed forms and 1C architecture (8.3). Experience in creating non-standard CRM systems / lead accounting modules within 1C. Understanding of HTTP services, Webhooks, and integrations with PBXs (Asterisk) / messengers. Clean, understandable code and ability to work in conjunction with the Database Architect. Adherence to deadlines and adequate communication. Working conditions: Format: Remote work through a Secure Transaction (Seir/Escrow) on Freelancehunt. Budget: We are ready to hear your estimates on cost and timelines after reviewing the TS. Based on the results of this project, there is a possibility of long-term cooperation on subsequent tasks and integrations. In your response, please indicate: Your experience working with non-standard (custom) 1C configurations. Examples of similar tasks (CRM modules, integrations with telephony or websites). Write the code word "TIRE" at the beginning of your response so we know you have read the project description carefully. We look forward to your responses! Payment conditions: We work strictly through Escrow (Freelancehunt) divided into 3 stages: Stage 1 (30%): Basic architecture — documents "Request", "Pickup Request", reference books, input based on. Stage 2 (40%): Integration logic — API/HTTP services (Website, Bot), linking Asterisk calls, interaction register. Stage 3 (30%): Interfaces — CRM desktop, indication, statistics/KPI, client card, final testing. Each stage is reserved in Escrow separately and paid after code verification by our Database Architect.

Automatic display of the goods and cash flow scheme is needed according to the approximate template provided in the attached file. The output files containing the source information are export files from databases in Excel.

Support is needed for the self-tour program, catalog database servers, and the online server. There are 5 database servers.

The client database has been collected over several years from various sources, so the phone numbers are recorded in different formats, one client exists under multiple IDs, cities are entered manually in different languages, and the region is almost never filled in. Because of this, it is impossible to properly segment the database. What needs to be done: 1. Database audit (paid separately, first stage). How many cards, how many phone numbers are out of format, how many duplicates, how many unique city entries. Based on the results — a refined estimate of the remaining work. 2. Standardization of phone numbers. All numbers should be brought to the format +380XXXXXXXXX. Numbers that cannot be unambiguously recognized should not be deleted or guessed, but listed separately. 3. Merging duplicates. Rule: one phone number = one client ID. At the same time, one client can have an unlimited number of numbers. Order history, emails, addresses, tags, and custom fields must be preserved. 4. Parsing cards that have many numbers "attached" to them. 5. Cities and regions. Names of settlements — from a single directory in Ukrainian (API of Nova Poshta or KATOHTG). The region must always be filled in so that all clients from Kyiv and the region can be exported with one filter, not separately for Brovary, separately for Irpin, etc. 6. Protection against re-contamination: normalization of phone and city at the input (website forms, integrations, manual entry) + regular background checks of new entries. Requirements: — practical experience with the SIMLA / RetailCRM (v5) API: exporting, updating, merging cards, request limits; — experience with data deduplication tasks; — understanding of Ukrainian address directories. Working conditions: full backup before any changes; initially a dry-run with a report on planned changes for approval, and only then launch on the live database; log of all operations with the possibility of rollback. No irreversible deletions without approval. In your response, please include: — timelines and cost

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.