Kilka oddziałów i synchronizacja danych w Subiekcie GT

Gdy każdy oddział widzi inne dane

Najczęstszy objaw problemu pojawia się wtedy, gdy jeden oddział ma aktualne ceny, a inny nadal wyświetla wcześniejsze wartości. Zdarza się też, że stan magazynowy nie odpowiada rzeczywistej liczbie towarów, dokument wystawiony w jednym miejscu nie jest widoczny w drugim albo kontrahent został dodany ponownie pod podobną nazwą.

W Subiekcie GT dane mogą być współdzielone przez kilka stanowisk, ale sposób ich udostępniania musi odpowiadać organizacji pracy. Inne rozwiązanie sprawdzi się przy oddziałach połączonych jedną siecią lokalną, a inne przy lokalizacjach korzystających z połączenia między miastami. Istotne jest również rozdzielenie bieżącej pracy programu od późniejszej wymiany danych.

Najczęstsze warianty połączenia oddziałów

W sieci LAN, czyli lokalnej sieci komputerowej obejmującej jedno miejsce lub budynek, kilka stanowisk może korzystać z jednej bazy Subiekta GT. Program działa wtedy na komputerach połączonych z serwerem, czyli urządzeniem przechowującym bazę danych i udostępniającym ją pozostałym stanowiskom.

Przy większej odległości stosuje się sieć WAN, czyli połączenie między oddzielnymi lokalizacjami. Może ono wykorzystywać bezpieczny tunel VPN, czyli szyfrowane połączenie tworzące logiczny kanał między sieciami. W takim wariancie trzeba sprawdzić opóźnienia, stabilność transmisji i sposób dostępu do serwera.

Możliwa jest również praca z wykorzystaniem zdalnego SQL. SQL, czyli język zapytań do baz danych, jest używany przez silnik Microsoft SQL Server, który przechowuje informacje Subiekta GT. Zdalny dostęp do serwera SQL nie oznacza jednak, że dowolne wystawienie portu do internetu jest bezpieczne. Dostęp wymaga kontroli użytkowników, reguł zapory sieciowej i szyfrowania połączenia.

Co może być synchronizowane

W typowym układzie między oddziałami wymienia się kartoteki towarów, ceny, stany magazynowe, dane kontrahentów i dokumenty. Kartoteka to uporządkowany zbiór informacji o towarze lub kontrahencie, między innymi nazwa, symbol, jednostka miary i stawka podatku. Dokumenty sprzedaży i przyjęcia magazynowe wpływają z kolei na historię operacji oraz dostępne ilości.

Przed rozpoczęciem prac trzeba określić, które dane mają być wspólne, a które lokalne. Jeden oddział może zarządzać centralną listą cen, natomiast inne miejsca mogą mieć własne dokumenty magazynowe. Jeżeli wszystkie stanowiska otrzymają możliwość zmiany tych samych pól bez ustalonych reguł, szybko pojawią się rozbieżności.

W przypadku integracji ze sklepem internetowym dotyczy to wyłącznie Subiekta GT, ponieważ jest on systemem sprzedażowo-magazynowym. Rewizor GT, Rachmistrz GT, Gratyfikant GT i Gestor GT mogą być obsługiwane oraz wdrażane, ale nie zakłada się dla nich integracji ze sklepem internetowym w ramach tego modelu pracy.

Dlaczego powstają konflikty danych

Konflikt danych powstaje wtedy, gdy co najmniej dwa stanowiska zmienią ten sam obiekt, zanim informacja o wcześniejszej zmianie zostanie przekazana dalej. Obiektem może być towar, cena, kontrahent albo dokument. Przykładowo jeden oddział zmienia cenę kartotekową, a drugi w tym samym czasie modyfikuje ten sam towar lub korzysta z nieaktualnej kopii danych.

Źródłem problemu bywa także niespójna numeracja dokumentów, różne ustawienia podatkowe, ręczne tworzenie tych samych kartotek oraz niejednoznaczne symbole towarów. Część trudności wynika z błędnej konfiguracji sieci, a nie z samego Subiekta GT. Przerwane połączenie w trakcie zapisu może pozostawić niepełną operację lub zablokować zasób, czyli element bazy chwilowo zajęty przez inne działanie.

Przed ingerencją w bazę wykonuje się jej kopię bezpieczeństwa. Kopia pozwala wrócić do stanu sprzed zmian, jeżeli test synchronizacji ujawni błąd albo dojdzie do nieprawidłowego połączenia danych.

Jak wygląda uporządkowanie środowiska

Prace zaczynają się od ustalenia topologii, czyli sposobu połączenia urządzeń, serwerów i oddziałów. Sprawdzane są serwery, stanowiska, adresacja sieciowa, zapory, konta użytkowników oraz wersje używanych składników. Analizuje się również, czy wszystkie stanowiska korzystają z tej samej bazy, czy z osobnych baz wymagających późniejszej wymiany danych.

Następnie porządkowane są kartoteki. Usuwa się niejednoznaczności w symbolach, ustala właściciela danych i określa, które miejsce może zmieniać ceny, stany oraz dane kontrahentów. W razie potrzeby przygotowuje się mapowanie, czyli przyporządkowanie odpowiadających sobie rekordów w różnych bazach.

Dalszy etap obejmuje konfigurację dostępu do SQL Servera, ustawienie reguł zapory i sprawdzenie komunikacji między oddziałami. Nie otwiera się przypadkowo dostępu do całego serwera. Zakres połączeń powinien być ograniczony do wymaganych urządzeń i usług, a konta użytkowników powinny mieć tylko potrzebne uprawnienia.

Synchronizacja cen, towarów i stanów

Najbezpieczniej rozpocząć od ustalenia źródła prawdy. Jest to wskazana baza albo oddział, którego dane traktuje się jako nadrzędne przy rozstrzyganiu rozbieżności. Bez takiej zasady program lub osoba wykonująca import może nie wiedzieć, która cena albo nazwa towaru ma pozostać obowiązująca.

Synchronizacja towarów powinna uwzględniać symbole, jednostki miary, stawki podatku, kody kreskowe i grupy towarowe. Kod kreskowy jest identyfikatorem odczytywanym przez skaner, ale sam nie gwarantuje poprawnego dopasowania, jeżeli w bazie występuje przy kilku różnych kartotekach.

Stany magazynowe wymagają szczególnej ostrożności. Stan jest wynikiem dokumentów, a nie tylko liczbą wpisaną ręcznie. Jeżeli jeden oddział przyjmuje towar, drugi sprzedaje go przed otrzymaniem aktualizacji, a trzeci wykonuje korektę, końcowa ilość może być inna niż suma lokalnych zapisów. Dlatego analizuje się dokumenty źródłowe, daty operacji i sposób rozliczania ruchu między oddziałami.

Praca pół-offline i odzyskiwanie połączenia

Praca pół-offline oznacza, że oddział może przez pewien czas wykonywać ograniczone działania bez stałego połączenia z centralną bazą, a później przekazuje zmiany do wspólnego środowiska. Takie rozwiązanie wymaga jasnego określenia, które operacje są dozwolone bez połączenia i jak są oznaczane do późniejszego przetworzenia.

Największe ryzyko dotyczy dokumentów wystawionych równolegle oraz tych samych kartotek tworzonych lokalnie. Pomocne są zakresy numeracji, unikalne symbole i zasada, że nowe towary tworzy się według jednego schematu. Unikalny symbol oznacza identyfikator, który nie może wskazywać dwóch różnych kartotek.

Po przywróceniu łączności nie powinno się od razu wykonywać masowej wymiany na żywym środowisku. Najpierw sprawdza się kolejkę zmian, czyli zestaw operacji oczekujących na przekazanie, oraz testuje import na kopii bazy. Dopiero po potwierdzeniu zgodności można włączyć ustalony proces dla bieżącej pracy.

Co można sprawdzić bez ingerencji w bazę

Samodzielnie można ustalić, czy problem dotyczy wszystkich stanowisk, jednego oddziału czy pojedynczego użytkownika. Warto zanotować dokładny czas wystąpienia błędu, nazwę dokumentu, symbol towaru i komunikat programu. Takie informacje pomagają odróżnić problem z danymi od problemu z połączeniem.

Można również sprawdzić, czy komputer widzi serwer w sieci, czy działa połączenie VPN oraz czy problem pojawia się przy każdym towarze. Bezpieczne jest zamknięcie programu na stanowisku, na którym wystąpił błąd, i ponowne uruchomienie po potwierdzeniu, że nie trwa zapis dokumentu.

Nie należy samodzielnie usuwać rekordów, zmieniać identyfikatorów w bazie, kopiować plików bazodanowych między oddziałami ani odtwarzać kopii bez ustalenia jej pochodzenia. Nie powinno się też wyłączać zapory na stałe ani wystawiać usługi SQL bez ograniczeń do internetu.

Błędy przy samodzielnej konfiguracji

Częstym błędem jest założenie, że wystarczy udostępnić folder z programem. Subiekt GT korzysta z bazy danych i usług serwera, więc samo udostępnienie plików nie zapewnia poprawnej ani bezpiecznej pracy wielooddziałowej.

Innym błędem jest uruchomienie synchronizacji bez wcześniejszej kopii. Jeżeli proces zmieni wiele kartotek lub dokumentów, ręczne cofnięcie zmian może być bardzo trudne. Nieprawidłowe jest również wielokrotne importowanie tej samej paczki danych. Może to prowadzić do duplikatów, czyli powtórzonych zapisów opisujących ten sam towar albo kontrahenta.

Problemy powoduje także zmiana ustawień w trakcie pracy oddziałów bez poinformowania pozostałych stanowisk. Wspólne zasady numeracji, cen i tworzenia kartotek muszą być znane osobom korzystającym z programu. Sama konfiguracja techniczna nie zastąpi procedury organizacyjnej.

Kiedy przyczyna leży poza synchronizacją

Nie każda różnica stanów oznacza awarię wymiany danych. Jeżeli dokument został zapisany jako roboczy, nie został zatwierdzony albo znajduje się na innym magazynie, może nie wpływać na prezentowany wynik. Podobnie korekta wystawiona w jednej części programu nie musi zmienić danych oczekiwanych przez konkretny raport.

Warto też odróżnić brak połączenia z serwerem od błędu uprawnień. Uprawnienia określają, jakie działania może wykonać użytkownik, natomiast połączenie sieciowe decyduje, czy komputer może dotrzeć do usługi. Komunikat o odmowie dostępu nie zawsze oznacza awarię sieci.

Jeżeli dane są poprawne w Subiekcie GT, ale nie zgadzają się w sklepie internetowym, przyczyna może znajdować się w integracji, filtrach eksportu lub mapowaniu kategorii. Gdy problem dotyczy Rewizora GT, Rachmistrza GT, Gratyfikanta GT albo Gestora GT, nie należy automatycznie stosować ustawień właściwych dla Subiekta GT.

Czy oddziały muszą pracować na jednej bazie?

Nie zawsze. Jedna baza upraszcza dostęp do wspólnych kartotek i bieżących stanów, ale wymaga stabilnego połączenia oraz właściwie skonfigurowanego serwera. Osobne bazy mogą lepiej odpowiadać oddziałom pracującym niezależnie, jednak wtedy potrzebny jest kontrolowany mechanizm wymiany danych i rozstrzygania konfliktów.

Czy można użyć zwykłego zdalnego pulpitu?

Zdalny pulpit, czyli przesyłanie obrazu i sterowania z serwera do oddalonego komputera, może ograniczyć część problemów z bezpośrednim dostępem do bazy. Nie rozwiązuje jednak awarii serwera, błędnej konfiguracji użytkowników ani braku kopii zapasowej. Należy także sprawdzić bezpieczeństwo kont i sposób szyfrowania połączenia.

Jak sprawdzić, która cena jest prawidłowa?

Najpierw trzeba ustalić obowiązującą politykę cenową, czyli regułę wskazującą, która lista cen ma pierwszeństwo. Następnie porównuje się historię zmian, dokumenty oraz źródło danych. Ręczne poprawianie ceny bez sprawdzenia powiązanych dokumentów może usunąć objaw, ale pozostawić niespójność w historii sprzedaży.

Czy Sfera GT służy do synchronizacji oddziałów?

Sfera GT jest interfejsem programistycznym opartym na COM i OLE Automation. Interfejs programistyczny to zestaw mechanizmów pozwalających innemu programowi wykonywać określone operacje w Subiekcie, Gestorze, Rewizorze i Gratyfikancie. Sfera GT może wspierać automatyzację wymiany danych, ale wymaga poprawnego projektu, obsługi błędów i kontroli uprawnień.

Podsumowanie zasad bezpiecznej wymiany danych

Synchronizacja oddziałów w Subiekcie GT wymaga połączenia trzech elementów: stabilnej komunikacji, uporządkowanych kartotek i jednoznacznych reguł własności danych. LAN, WAN, zdalny SQL oraz praca pół-offline są różnymi wariantami organizacji środowiska, a nie gotowymi rozwiązaniami działającymi bez konfiguracji.

Przed zmianami wykonywana jest kopia bazy, następnie sprawdzane są połączenia, uprawnienia, numeracja i sposób rozstrzygania konfliktów. Takie podejście ogranicza ryzyko powielania danych i pozwala utrzymać zgodność towarów, cen, dokumentów oraz stanów magazynowych między oddziałami.