Tworzenie bazy danych "univer" w bazie danych Oracle 18c

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.

Szukamy wsparcia dla projektu opartego na Yii , trzeba wprowadzać poprawki i dopracowania bazy, częściowo jest kontakt z poprzednim wykonawcą .....................

Ogólne informacje Konieczne jest opracowanie prostej, minimalistycznej systemu webowego, którego głównym celem jest prowadzenie bazy klientów, tworzenie zapisów na wizyty oraz automatyzacja procesu potwierdzania wizyt przez SMS, wysyłanie jednorazowych linków przez API z samego serwisu. Projekt jest realizowany etapami. Na pierwszym etapie konieczne jest wdrożenie jedynie podstawowej funkcjonalności (MVP), aby system mógł być używany w rzeczywistej pracy. Po uruchomieniu i przetestowaniu będzie stopniowo rozszerzany o nowe moduły.Podstawowa funkcjonalność pierwszego etapu autoryzacja użytkowników; baza klientów; tworzenie i edytowanie zapisów; lista zapisów (lub prosty kalendarz); przełączanie między punktami sprzedaży; integracja z operatorem SMS przez API; wysyłanie SMS z dowolnym tekstem lub linkiem do potwierdzenia wizyty; potwierdzenie lub anulowanie wizyty przez klienta za pomocą jednorazowego linku; wyświetlanie statusu potwierdzenia bezpośrednio obok zapisu klienta. Na początkowym etapie zamiast pełnoprawnego kalendarza dopuszcza się użycie prostego wykazu zapisów według dni. Każdy dzień powinien zawierać chronologiczny wykaz rezerwacji z podaniem czasu, imienia klienta, usługi, pracownika oraz statusu potwierdzenia. W przyszłości ten wykaz można będzie zastąpić pełnoprawnym kalendarzem bez zmiany struktury systemu. W systemie powinna być możliwość przełączania się między punktami sprzedaży. Każdy punkt sprzedaży ma własną listę zapisów (lub kalendarz), ale wszystkie korzystają ze wspólnej bazy klientów.