BAS: automatyczne wczytywanie pozostałości do Google Sheets

Opis projektu: Poszukujemy doświadczonego programisty 1C do wdrożenia funkcjonalności CRM (moduł „Zgłoszenia”) w nietypowej konfiguracji 1C. Baza jest dostosowana, działa i rozwija się z powodzeniem od 7 lat. Dodatkowe prace są prowadzone pod kontrolą Architekta bazy (etatowego programisty 1C), który będzie kuratorem projektu, zatwierdzi architekturę i przeprowadzi przegląd kodu. Zajmujemy się sprzedażą opon, felg oraz usługami wulkanizacji. Celem modułu jest połączenie wszystkich kanałów przychodzących (Asterisk, strona internetowa, bot Telegram, agregator komunikatorów, wizyty) w jeden system przetwarzania leadów. Co należy zrobić: Nowy dokument „Zgłoszenie” — centralne miejsce pracy menedżera (pola, lejek statusów, znaczniki UTM, formularz doboru opon). Moduł „Zgłoszenie na Odbiór” — ewidencja punktów odbioru, slotów czasowych i statusów gotowości towaru. Logika integracji z Asterisk — automatyczne przypisanie przychodzących/wychodzących połączeń i nagrań audio do Zgłoszeń według numeru telefonu i czasu. Historia interakcji i KPI — chronologiczny rejestr kontaktów (połączenia, wiadomości), obliczenie czasu podjęcia pracy i cyklu transakcji. Wprowadzenie na podstawie — powiązanie Zgłoszenia z dokumentami, zapisami na wulkanizację, formularzami przechowywania i TDT. Interfejs — jednolity dziennik CRM z kolorową indikacją, filtrami i zakładką historii w karcie Klienta. Szczegółowe i dokładnie opracowane Techniczne Zadanie (TZ) przekażemy kandydatom, którzy przejdą wstępną selekcję. Nasze wymagania wobec wykonawcy: Doskonale znasz zarządzane formularze i architekturę 1C (8.3). Doświadczenie w tworzeniu nietypowych systemów CRM / modułów ewidencji leadów w 1C. Rozumienie działania usług HTTP, Webhooków i integracji z APT (Asterisk) / komunikatorami. Czysty, zrozumiały kod i umiejętność pracy w zespole z Architektem bazy. Przestrzeganie terminów i adekwatna komunikacja. Warunki pracy: Format: Praca zdalna przez Bezpieczną Transakcję (Seir/Escrow) na Freelancehunt. Budżet: Jesteśmy gotowi wysłuchać Twoich ocen dotyczących kosztów i terminów po zapoznaniu się z TZ. W wyniku tego projektu możliwe długoterminowe współprace przy kolejnych zadaniach i integracjach. W odpowiedzi prosimy podać: Twoje doświadczenie w pracy z nietypowymi (dostosowanymi) konfiguracjami 1C. Przykłady podobnych zadań (moduły CRM, integracje z telefonią lub stronami internetowymi). Napisz słowo kodowe „OPONA” na początku odpowiedzi, abyśmy wiedzieli, że uważnie przeczytałeś opis projektu. Czekamy na Twoje odpowiedzi! Warunki płatności: Pracujemy wyłącznie przez Sejf (Freelancehunt) z podziałem na 3 etapy: Etap 1 (30%): Podstawowa architektura — dokumenty „Zgłoszenie”, „Zgłoszenie na odbiór”, słowniki, wprowadzenie na podstawie. Etap 2 (40%): Logika integracji — API/usługi HTTP (Strona, Bot), przypisanie połączeń Asterisk, rejestr interakcji. Etap 3 (30%): Interfejsy — pulpit CRM, indikacja, statystyka/KPI, karta klienta, końcowe testowanie. Każdy etap jest rezerwowany w Sejfie osobno i wypłacany po sprawdzeniu kodu przez naszego Architekta bazy.

Potrzebne jest automatyczne wyświetlanie schematu ruchu towarowo-pieniężnego według przybliżonego szablonu podanego w załączonym pliku. Pliki wyjściowe, w których znajduje się informacja wyjściowa, to pliki zrzutu z baz danych w excelu.

Potrzebne wsparcie dla programu samoturu, serwerów katalogów baz danych oraz serwera online. Serwerów baz danych 5 szt.

Baza klientów była zbierana przez kilka lat z różnych źródeł, dlatego numery telefonów są zapisane w różnych formatach, jeden klient istnieje pod kilkoma ID, miasta wprowadzane ręcznie w różnych językach, obszar prawie nigdzie nie jest wypełniony. Z tego powodu niemożliwe jest normalne segmentowanie bazy. Co należy zrobić: 1. Audyt bazy (płatny osobno, pierwszy etap). Ile kartotek, ile telefonów poza formatem, ile duplikatów, ile unikalnych zapisów miast. Na podstawie wyników — doprecyzowana ocena pozostałych prac. 2. Standaryzacja telefonów. Wszystkie numery należy doprowadzić do formatu +380XXXXXXXXX. Numery, które nie mogą być jednoznacznie rozpoznane, — nie usuwać i nie zgadywać, a przenieść do osobnej listy. 3. Łączenie duplikatów. Zasada: jeden numer telefonu = jeden ID klienta. Przy tym jeden klient może mieć nieograniczoną liczbę numerów. Historia zamówień, e-maile, adresy, tagi i pola niestandardowe muszą zostać zachowane. 4. Analiza kartotek, na których „przyczepiono” wiele numerów. 5. Miasta i obszary. Nazwy miejscowości — z jednego słownika ukraińskiego (API Nowej Poczty lub KATOOTG). Obszar musi być zawsze wypełniony, aby jednym filtrem można było wyeksportować wszystkich klientów z Kijowa i obszaru, a nie osobno Brovary, osobno Irpień itd. 6. Ochrona przed ponownym zanieczyszczeniem: normalizacja telefonu i miasta na wejściu (formularze strony, integracje, ręczne wprowadzanie) + regularna kontrola nowych zapisów w tle. Wymagania: — praktyczne doświadczenie w pracy z API SIMLA / RetailCRM (v5): eksport, aktualizacja, łączenie kartotek, limity zapytań; — doświadczenie w zadaniach związanych z deduplikacją danych; — zrozumienie ukraińskich adresowych słowników. Warunki pracy: pełny backup przed jakimikolwiek zmianami; najpierw dry-run z raportem o planowanych zmianach do zatwierdzenia, a dopiero potem uruchomienie na bazie produkcyjnej; log wszystkich operacji z możliwością cofnięcia. Bez nieodwracalnych usunięć bez zgody. W odpowiedzi napisz: — terminy i koszt

Potrzebna jest centralna serwerowa system zbierania i przechowywania danych z Planfix, 1C, Meta Ads i Google Ads, a także webowy dashboard do ich wyświetlania i analizy. Wszystkie dane, historia zmian, obliczenia i agregowane wskaźniki muszą być przechowywane wyłącznie w serwerowej bazie danych. Dashboard nie powinien przechowywać ani duplikować danych biznesowych. Ma on uzyskiwać niezbędne informacje z serwerowej bazy przez API zgodnie z zapytaniami użytkownika i wyświetlać je w postaci KPI, wykresów, tabel i szczegółowych raportów.