Synchronizacja Prom.ua, Rozetka, cenników + fiskalizacja (PRRO)

Mamy chatbota na SendPulse i potrzebna jest konfiguracja, aby przez niego była możliwość zakupu subskrypcji na zamknięty klub za pomocą Stripe, która będzie automatycznie odnawiana co miesiąc, a także dawała możliwość zarządzania subskrypcją oraz automatycznie otwierała i zamykała dostęp w przypadku rozpoczęcia lub zakończenia subskrypcji Co jest już gotowe W Stripe stworzono produkt z miesięcznym pobieraniem i link do płatności. Bot w SendPulse istnieje, prowadzi użytkownika do płatności i potrafi dodawać tagi oraz pracować z polami kontaktowymi. Brakuje połączenia między dwoma systemami: obecnie, jeśli osoba płaci przez Stripe, SendPulse o tym nie wie Co trzeba zrobić Skonfigurować w Stripe webhook na zdarzenia checkout.session.completed, invoice.paid i customer.subscription.deleted Napisać handler (funkcja serverless lub gotowe narzędzie no-code, takie jak Albato, n8n), który przyjmuje webhook, wyciąga email klienta i typ zdarzenia Przez API SendPulse aktualizować pole lub tag kontaktu (na przykład, club_active = tak/nie) w zależności od zdarzenia Skonfigurować w SendPulse automatyzację, która na podstawie tego pola otwiera dostęp do zamkniętego kanału przy udanej płatności i zamyka przy anulowaniu lub nieudanym pobraniu Podłączyć Stripe Customer Portal, aby uczestnik mógł samodzielnie anulować subskrypcję lub zmienić kartę, a to również docierało do SendPulse przez ten sam webhook jeśli macie sposób na połączenie łatwiejsze bez zewnętrznych webhooków, również to rozważymy! Co powinno wyjść na końcu Działający proces: osoba płaci w Stripe, w ciągu kilku minut otrzymuje dostęp do kanału, przy anulowaniu lub niepowodzeniu pobrania dostęp jest automatycznie zamykany, bez udziału administratora. Plus krótka dokumentacja: gdzie co jest skonfigurowane, jak uruchomić handler ponownie, jeśli się zawiesi, i gdzie szukać w przypadku skargi uczestnika na zamknięty dostęp Kogo szukamy Doświadczenie w pracy z API Stripe i webhookami, doświadczenie z API SendPulse (lub gotowość do szybkiego zapoznania się z nim, dokumentacja jest otwarta), umiejętność uruchomienia prostego handlera serverless lub skonfigurowania połączenia w Albato/n8n. Gotowość do pokazania podobnego przypadku z portfolio będzie plusem

O firmie i bieżącej pracy Firma sprzedaje towary przez: kilka sklepów Rozetka; 5–8 sklepów Prom.ua; kilka sklepów Epicentr. Wolumen: orientacyjnie 50–100 zamówień dziennie. Planowane jest podłączenie good w najbliższym czasieUżywane systemy i metody płatności Rozetka; Prom.ua; Epicentr; Nowa poczta; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Metody płatności: płatność przy odbiorze przez Nową pocztę / NovaPay; RozetkaPay; bezpośredni przelew na IBAN; planowana płatność przez link za pośrednictwem monobank. NovaPay i RozetkaPay przekazują pieniądze w sumie według rejestrów: w rejestrze NovaPay wskazane są TTN; w rejestrze RozetkaPay wskazane są zamówienia. Główne cele Skonfigurować KeyCRM tak, aby właściciel mógł w jednym miejscu: -Widzieć wszystkie zamówienia ze wszystkich sklepów. -Nie tracić zamówień i TTN. -Widzieć aktualny stan każdej wysyłki. -Widzieć faktyczny ruch pieniędzy w zamówieniach. -Automatycznie łączyć otrzymane płatności z odpowiednimi zamówieniami. -Widzieć nieprzypisane płatności, niedopłaty, nadpłaty i inne rozbieżności. -Kontrolować działania pracowników. -Minimalizować pracę ręczną.-Automatyczną fiskalizację - Zbudować odpowiednią automatyzację ruchu zamówienia Przeprowadzić audyt istniejącego KeyCRM Sprawdzić: -aktualne statusy, pola i automatyzacje; -bankowe i płatnicze połączenia; -role i prawa pracowników; -historię działań; -aktualne ustawienia Checkbox; -możliwość realizacji wymagań standardowymi środkami KeyCRM. Na podstawie audytu dostarczyć: -listę znalezionych problemów; -wykaz niezbędnych ustawień; -wykaz zadań, dla których potrzebna jest integracja API lub zewnętrzna usługa; -zalecenia dla lepszej pracy serwisu -ocenę terminów i kosztów. Skonfigurować przyjmowanie i przetwarzanie zamówień Wymagane: ustawić jednolitą sekwencję przetwarzania zamówień; ustawić obowiązkowe pola, bez których zamówienie nie może być przekazane do następnego etapu; stworzyć kontrolę zamówień, które się nie załadowały, załadowały z błędem lub pozostały bez odpowiedzialnego. Skonfigurować ruch i weryfikację płatności Podłączyć do KeyCRM wszystkie używane konta i usługi płatnicze: PrivatBank; monobank; NovaPay; RozetkaPay; ekspedycja monobank po jego podłączeniu. Należy zrealizować: -Automatyczne pobieranie dostępnych wyciągów i transakcji. -Wyświetlanie faktycznych wpływów dla każdego FOP i konta. -Automatyczne przypisanie bezpośredniej płatności na IBAN do zamówienia według numeru zamówienia w komentarzu. -Weryfikację całkowitej wypłaty NovaPay z rejestrem i dalsze przypisanie wierszy rejestru do zamówień według TTN. -Weryfikację całkowitej wypłaty RozetkaPay z rejestrem i dalsze przypisanie wierszy rejestru do zamówień według numeru zamówienia. -Automatyczne przetwarzanie płatności przez link po podłączeniu ekspedycji. -Osobną listę płatności, które nie mogą być automatycznie przypisane. Identyfikacja: -niedopłaty; -nadpłaty; -częściowe płatności; -duplikowane płatności; -płatności bez znalezionego zamówienia; -zamówienia oznaczone jako opłacone bez potwierdzonego wpływu. -Codzienna weryfikacja kwot według FOP, kont i metod płatności. -Status „Opłacono” powinien być ustawiany automatycznie po potwierdzonym zaksięgowaniu pieniędzy na odpowiednim IBAN. Pracownicy nie powinni mieć prawa ustawiać go ręcznie. Jeśli standardowe możliwości KeyCRM są niewystarczające, integrator powinien: proponować integrację API lub zewnętrzny moduł; opisać jego logikę; osobno ocenić rozwój; zapewnić dziennik błędów i ponowne przetwarzanie; nie przypisywać płatności automatycznie przy niejednoznacznym dopasowaniu. Skonfigurować kontrolę zagubionych zamówień Potrzebna jest osobna lista robocza lub raport: zamówienie wpłynęło, ale nie zostało podjęte do pracy; zamówienie potwierdzone, ale nie przekazane do magazynu lub drop; zamówienie gotowe, ale TTN nie została stworzona; TTN stworzona, ale paczka nie została przekazana przewoźnikowi; paczka długo się nie porusza; klient nie odbiera paczki; była przekierowanie; rozpoczęto zwrot; zwrotna paczka nie została odebrana przez firmę; zamówienie dostarczone, ale płatność nie została zaksięgowana; płatność otrzymana, ale nie przypisana do zamówienia; zamówienie pozostało w statusie pośrednim dłużej niż dopuszczalny czas. W przypadku każdego wyjątku powinny być: odpowiedzialny; czas reakcji; zadanie lub powiadomienie; jasny powód; link do zamówienia. 4.7. Skonfigurować prawa i kontrolę pracowników Obowiązkowe ograniczenia: -pracownicy nie mogą usuwać zamówień; -pracownicy nie mogą ręcznie ustawiać statusu „Opłacono”; -pracownicy nie mają dostępu do połączeń bankowych, kluczy API i ustawień administracyjnych.Skonfigurować Checkbox Obecnie paragony z KeyCRM nie są tworzone. Integrator musi: -sprawdzić istniejące konta, kasy i kasjerów Checkbox; -podłączyć kasy odpowiednich FOP; -ustawić metody płatności; -ustawić automatyczną fiskalizację dla uzgodnionych scenariuszy; -ustawić przetwarzanie błędów; -ustawić paragony zwrotu; -przeprowadzić testy.Skonfigurować raporty dla właściciela Właściciel powinien widzieć: -liczbę nowych i nieprzetworzonych zamówień; -problemowe wysyłki; -paczki w oddziale; -zwroty; -dostarczone zamówienia bez otrzymanej płatności; -otrzymane, ale nieprzypisane płatności; -niedopłaty i nadpłaty; -ręczne zmiany pracowników.Format może być realizowany standardowymi listami, filtrami, analizą, zadaniami lub zewnętrznym raportem — sposób proponuje integrator. Przeszkolić pracowników Po konfiguracji przeprowadzić szkolenie: właściciela — kontrola, raporty, błędy i prawa; menedżerów — przetwarzanie zamówień; pracownika dropu — przekazanie zamówienia i kontrola TTN; pracownika magazynu — tworzenie TTN i wysyłka; odpowiedzialnego za finanse — przetwarzanie nieprzypisanych płatności i rozbieżności. Dostarczyć krótkie instrukcje lub nagrania wideo podstawowych operacji. Oczekiwany rezultat Po wykonaniu prac: -wszystkie zamówienia są przetwarzane w KeyCRM; -przegapione i zawieszone zamówienia są automatycznie identyfikowane; -każda TTN jest powiązana z zamówieniem i śledzona; -problemowe paczki trafiają do odpowiedzialnych pracowników; -bankowe i płatnicze wpływy są widoczne w CRM; -jednoznaczne płatności są automatycznie przypisywane do zamówień; -rejestry NovaPay i RozetkaPay są weryfikowane z wpływami i zamówieniami; -niejednoznaczne płatności trafiają na ręczną weryfikację; -pracownicy nie mogą usunąć zamówienia ani ręcznie oznaczyć go jako opłacone; -właściciel widzi ruch pieniędzy i listę odchyleń; -Checkbox działa zgodnie z uzgodnionymi scenariuszami; -zespół jest przeszkolony do pracy. Format propozycji od integratora Przed rozpoczęciem wdrożenia wykonawca powinien dostarczyć: -Wynik audytu. -Proponowany schemat konfiguracji. -Co będzie realizowane standardowymi środkami KeyCRM. -Co wymaga API lub zewnętrznej usługi. -Koszt standardowej konfiguracji. -Osobny koszt rozwoju. -Terminy według etapów. -Wykaz niezbędnych dostępów. -Plan testowania i uruchomienia.

Opracowanie międzynarodowej aplikacji mobilnej pod klucz (Projekt + Kod) W celu obniżenia kosztów, możliwe jest zakupienie gotowego projektu 1. Ogólne wymagania dotyczące projektu Platforma: Rozwój wieloplatformowy na frameworku Flutter (jeden kod dla iOS i Android). Typ platformy: Społeczny zakład / Gry o dyscyplinę (Peer-to-Peer 도전戰). Zadanie Wykonawcy: Pełny cykl rozwoju (UI/UX Projekt w Figma, frontend, backend-serwer, baza danych, integracja czujnika IoT i bramki płatniczej). Wielojęzyczność: Pełne wsparcie lokalizacji (i18n) oraz obsługa wielu walut. 2. Wymagania dotyczące UI/UX Projektu Potrzebny jest nowoczesny, neonowo-technologiczny interfejs w ciemnych kolorach (Tryb Ciemny). Kolory akcentujące: Głęboki grafitowy (tło), jasny zielony (finanse, saldo), jasny czerwony (tryb ochrony, zdarzenia karne). Funkcjonalność: Wyświetlanie 4 głównych ekranów dolnej nawigacji (Dashboard, Pokoje Gier, Portfel, Ustawienia urządzenia). Potrzebne są dynamiczne animacje zmiany salda i wyskakujących alertów. 3. Architektura finansowa (Escrow/Holding/Split) Aplikacja do utrzymania depozytów zgodnie z zasadami dyscypliny. Kluczowa jest integracja bramki płatniczej, która obsługuje Split Payments (Podział płatności) oraz Holding funduszy (Stripe Connect dla rynku globalnego/analogiczne dla lokalnego). Logika transakcji (komendy API backendu): Doładowanie: Środki użytkowników są przypisywane do ich konta i zamrażane na transakcyjnym (escrow) koncie systemu płatniczego. Nie trafiają bezpośrednio na konto firmy. Tryb SOLO: Po wystąpieniu zdarzenia wyzwalającego z czujnika IoT w zakazanych godzinach backend wydaje polecenie systemowi płatniczemu przelania stałej kwoty (kary) z konta transakcyjnego użytkownika na konto rozliczeniowe firmy. Tryb GROUP (Pokój): Użytkownicy tworzą wspólną pulę (na przykład 10 osób po 10 dolarów). Pieniądze są zamrażane w ramach konkretnego Pokoju Gier. Po wystąpieniu zdarzenia wyzwalającego u jednego z uczestników jego kara automatycznie się dzieli: 15% (prowizja platformy) trafia na konto rozliczeniowe firmy, a 85% pozostaje w puli nagród pokoju. Po zakończeniu terminu wyzwania backend automatycznie dzieli zgromadzoną pulę nagród między zwycięzców, a system płatniczy dokonuje automatycznego przelewu (Payout) na ich karty. 4. Struktura kabinetów Kabinet 1: „Osobisty Tracker” (Tryb SOLO) Wskaźnik statusu monitorowania (Aktywny/Dostępny/Zablokowany). Konfigurator interwałów czasowych ochrony (Time Picker) oraz ustawienia wartości kary wyzwalacza. Panel stanu zewnętrznego urządzenia IoT (poziom naładowania czujnika w %, poziom sygnału, status synchronizacji). Kabinet 2: „Pokoje Gier” (Tryb GROUP) Narzędzia do tworzenia prywatnych pokoi (generowanie linków/zaproszeń dla przyjaciół) oraz lista publicznych globalnych lig. Tabela wyników (Leaderboard) uczestników z wyświetlaniem ich aktualnego statusu w czasie rzeczywistym, timer do końca wyzwania oraz wbudowany czat grupowy. Wspólny dział: Wielowalutowy portfel Wyświetlanie salda z automatycznym konwertowaniem lokalnych walut w czasie rzeczywistym. Historia transakcji z przejrzystym logiem wydatków, prowizji i wygranych. 5. Wymagania dotyczące Backend i Integracji IoT Stos: Node.js/Python/Go (do wyboru wykonawcy, uzasadnione). Łącze z IoT: Odbieranie pakietów danych z zewnętrznego modułu Wi-Fi. Czas wysyłania powiadomień Push (przez FCM) na smartfon w momencie wystąpienia zdarzenia z czujnika – mniej niż 1 sekunda. Logika antyfraudowa: Serwer musi analizować przesyłane przez czujnik dane telemetryczne wbudowanego akcelerometru (accel_x/y/z). Jeśli zdarzenie występuje przy zerowej zmianie osi przyspieszenia, transakcja jest oznaczana przez system jako podejrzana (ochrona przed statycznym trzymaniem czujnika), użytkownik otrzymuje powiadomienie.

Musimy podłączyć system płatności do strony high risk. Główne wymagania — akceptacja środków fiat oraz wypłata środków w kryptowalucie. Preferowane no kyc. Tylko dla tych, którzy mieli podobne doświadczenie. Cena — do uzgodnienia