Nasza stara samodzielna system się wyczerpał, musimy rosnąć. Szukamy doświadczonego profesjonalisty do wdrożenia ERPNext. Obowiązkowo z doświadczeniem, nasza sfera to handel hurtowy i detaliczny. Będzie bardzo wiele różnych standardowych i niestandardowych rozwiązań, a także klasyczne podłączenie PRRO, Banków Momo i Privat, Nowa Poczta, Marketplace'y i tak dalej. Gotowi?! :) W takim razie przesyłajcie swoje CV i poznajmy się.

Ogólne informacje: Jest bot Telegram, napisany w Pythonie (aiogram v3, aiohttp, MySQL, Redis). To usługa do interakcji między zleceniodawcami a wykonawcami (profile, projekty itp.). Wymagane umiejętności: - Pewne doświadczenie z aiogram v3 (nie v2!), asyncio, aiohttp; - Znajomość Telegram Bot API (webhooki); - Doświadczenie w pracy z MySQL, Redis; - Umiejętność rozumienia cudzej kody; - Komunikatywność, odpowiedzialność. Potrzebuję na bieżącej wersji bota bezpośrednio na serwerze naprawić błąd-problem Problem polega na tym: Nie funkcjonują w pełni czaty (Nory), powinien być czyściciel, który będzie działał zgodnie z algorytmem, ale teraz działa z błędami, czyści niezgodnie z harmonogramem - Czat między zleceniodawcą jest potrzebny do omawiania z wykonawcą kwestii roboczych. - Czat (nory już wszystkie zostały stworzone, potrzebne jest, aby je czyścił i ustawiać w kolejce - Użytkownik bot tworzy czaty (parne nory, już je mamy) i ustawia je w kolejce, jeśli w czacie dokonano transakcji, rozmówcy w nim są (w jednym czacie wykonawca, w drugim czacie zleceniodawca); jeśli czat jest zamknięty lub nie dokonano transakcji i użytkownicy nie pisali tam przez 7 dni; bot usuwa stamtąd zleceniodawców lub wykonawców i ustawia ten czat (norę z powrotem w kolejce) - Zleceniodawca może przejść do czatu z każdym wykonawcą, który odpowiedział na zlecenie - Zleceniodawca i wykonawca znajdują się w dwóch równoległych czatach, aby nie było możliwości zobaczenia bezpośredniego konta rozmówcy i nie było możliwości napisania do niego bezpośrednio * Nie zmieniamy działania czatów i wszystkiego innego Najważniejsze, aby poprawka nie pociągnęła za sobą innych problemów

System automatycznych powiadomień o uzupełnieniu zapasów analityka. Na 8n8. Mała automatyzacja dla e-commerce. Raz na dobę system oblicza szybkość sprzedaży dla każdego produktu i wysyła na Telegram, że czas zamówić (z zalecaną ilością) i na ile dni wystarczy zapas. Co robimy: Pobieranie danych: KeyCRM API (historia zamówień) + zapasy/zamówienia z Rozetka (API lub eksport) Przechowywanie w SQLite na moim VPS (Contabo, Linux) Obliczanie średniej sprzedaży, zapasu w dniach, punktu zamówienia Analiza ABC: priorytetyzacja, który produkt uzupełniać jako pierwszy (klasa A — główne pod względem przychodu — ważniejsze) Codzienny bot Telegram + uruchamianie przez cron Wszystkie progi (czas dostawy, zapas bezpieczeństwa, zapas docelowy) — w konfiguracji

Witam! Potrzebuję wizualnie dostosować system InvenTree (open-source) do prezentacji projektu kawiarni. Składny backend i integracja z kasą (POS) nie są wymagane — ważna jest zewnętrzna przeróbka interfejsu, aby pokazać różnicę „Było / Stało”. Stos technologiczny projektu: Python (Django) + React (Mantine UI). Co należy zrobić w interfejsie: Dostosowanie marki, Zmiana nazw w menu bocznym i tabelach, Usunięcie pól inżynieryjnych z formularzy, Skonfigurowanie jednego przepisu „składania” napoju (na przykład, Cappuccino), aby przy ręcznym odpisywaniu ze magazynu wszystkie składniki były wyraźnie odliczane, dodanie funkcji w postaci dodatkowych raportów oraz wyjaśnienie zasad działania wprowadzonych zmian. Wszystkie szczegóły omówimy osobiście. Wymagania dla wykonawcy: Doświadczenie w pracy z Django i React (Mantine UI). Zdolność do szybkiego wykonania zadania — projekt potrzebny do prezentacji. Pracujemy przez Safe (Bezpieczną transakcję). W odpowiedzi zacznij od słowa „KAWA”, aby widział, że przeczytałeś do końca. Napisz swoje terminy i cenę.

Potrzebna jest niewielka poprawka w programie, który formuje zamówienia do druku. Zadanie: Dodaliśmy do asortymentu miękkie szkło z nadrukiem. W zamówieniach nazwa nadruku będzie wyróżniona symbolami #...# dla poprawnego rozpoznawania. Przykład: Miękkie szkło, #Abstrakcja biała# 2.0mm, Kształt: Prostokąt... Wymagane: jeśli w tekście zamówienia znajduje się fragment między symbolami #...#, program powinien rozpoznać go jako zamówienie z nadrukiem; przy formowaniu PDF lub arkusza do druku takie zamówienie należy wyróżnić innym kolorem (jakimkolwiek widocznym, uzgodnimy podczas realizacji); reszta logiki działania programu ma pozostać bez zmian. Przykład zamówienia dodaję poniżej do testowania.