Nowy plik z cenami jest gotowy. Ktoś wybiera go w aplikacji, widzi komunikat „import zakończony” i wraca do swoich zadań. Godzinę później handlowiec pyta, dlaczego część klientów widzi cenę za sztukę podaną wcześniej za opakowanie. W pliku wszystko wyglądało porządnie. Problem polegał na tym, że kolumna z jednostką nie została uzgodniona przed zmianą.
Taki scenariusz nie wymaga błędu w obliczeniach. Wystarczy inna interpretacja pola albo pominięty wyjątek klienta. Dlatego import cennika warto zaprojektować jako drogę od rozpoznania pliku przez sprawdzenie różnic do świadomego zatwierdzenia. Komunikat o wczytaniu danych powinien znaczyć dokładnie to, co mówi: aplikacja odczytała plik. Nie musi jeszcze oznaczać, że zmieniła ceny.
Najpierw ustal, co ma zostać zmienione
Cennik może dotyczyć wszystkich klientów, wybranej grupy albo jednej umowy. Może zawierać ceny podstawowe, warunki dla określonej ilości, waluty i daty obowiązywania. Zanim wybierzecie format pliku, opiszcie jedną zmianę od początku do końca. Kto ją przygotowuje? Który system jest źródłem poprzedniej wersji? Kto zatwierdza wynik i gdzie klient zobaczy nową wartość?
Istotne jest też rozróżnienie pełnej listy od częściowej aktualizacji. Jeżeli w pliku nie ma produktu, system ma pozostawić jego cenę, oznaczyć ją do sprawdzenia czy zakończyć obowiązywanie? Żadna z tych odpowiedzi nie jest bezpieczną domyślną zasadą dla każdej firmy. Reguła powinna być znana przed importem i pokazana osobie zatwierdzającej.
Przy wielu kanałach sprzedaży trzeba ustalić kolejność przekazywania zmian. Portal klienta, system obsługi zamówień i narzędzie handlowca mogą odświeżać dane w różnym czasie. W artykule o źródłach danych w integracji systemów opisujemy, jak przypisać odpowiedzialność za wartości. Bez takiej decyzji nawet poprawny import może zostać później nadpisany przez starszy plik z innego miejsca.
Plik ma strukturę, ale potrzebuje znaczenia
Kolumna „cena” nie mówi jeszcze, za co klient płaci. Może dotyczyć sztuki, metra, godziny pracy lub opakowania zawierającego kilka elementów. Przy każdej wartości zapiszcie identyfikator produktu albo usługi, jednostkę, walutę oraz zakres, którego cena dotyczy. Jeśli w procesie występują różne rodzaje kwot, potrzebne są jednoznaczne nazwy zamiast kilku podobnych nagłówków.
Nie zakładajcie, że identyczny ciąg znaków jest zawsze tym samym produktem. Dostawca może używać własnego kodu, a firma wewnętrznego identyfikatora. Potrzebne jest uzgodnione mapowanie oraz sposób obsługi pozycji, której nie udało się dopasować. Podobne pytanie pojawia się przy projektowaniu portalu B2B dla handlu hurtowego: cena jest użyteczna dopiero wtedy, gdy wiadomo, do jakiego produktu, klienta i warunków się odnosi.
W plikach CSV dodatkową rolę odgrywają separator kolumn, kodowanie znaków i zapis liczb. Wartość „1,25” może zostać źle odczytana, jeżeli narzędzie spodziewa się innego formatu albo przecinek traktuje jako separator pól. Dokumentacja Microsoft Power Query pokazuje, że ustawienia regionalne wpływają na interpretację tekstu podczas konwersji liczb i dat. Własny importer również potrzebuje jawnie ustalonej reguły oraz testów na rzeczywistym formacie pliku.
Po uzgodnieniu ceny warto osobno sprawdzić zmiany opisu produktu przed publikacją. Wymiary, wariant i źródło cech mogą wymagać innego przeglądu niż kwota z cennika.
Wykryj błędy, zanim pojawi się przycisk zatwierdzenia
Pierwszy etap może sprawdzić, czy plik da się otworzyć, czy ma wymagane kolumny i czy wartości mieszczą się w uzgodnionych formatach. Drugi powinien sprawdzić sens danych w kontekście procesu: czy produkt istnieje, czy jednostka jest znana, czy okresy dla tej samej ceny nie kolidują oraz czy dana osoba może wprowadzać zmiany w tym zakresie.
Błąd powinien wskazywać wiersz i powód odrzucenia w sposób zrozumiały dla osoby przygotowującej cennik. „Nieprawidłowy identyfikator produktu w wierszu 18” daje punkt zaczepienia. Sam komunikat „validation failed” zostawia użytkownika z plikiem i poczuciem, że problem jest gdzieś pomiędzy monitorem a wszechświatem. Przy większej liczbie błędów przyda się lista, którą można poprawić za jednym razem.
Nie każda nietypowa wartość jest błędem. Cena zerowa może być pomyłką, ale może też oznaczać uzgodniony wariant testowy albo element rozliczany inaczej. Duża zmiana procentowa może wynikać ze zmiany jednostki, zakresu usługi lub nowej umowy. Dlatego ostrzeżenia powinny prowadzić do sprawdzenia kontekstu, a nie automatycznie poprawiać dane według zgadywanej zasady.
Osobno ustalcie, czy błąd jednego wiersza zatrzymuje całą paczkę. Częściowy import może oszczędzić pracy, ale może też pozostawić powiązane ceny w różnych wersjach. Jeżeli wybierzecie częściowe wykonanie, pokażcie dokładnie, które pozycje weszły w życie, które czekają i jak bezpiecznie ponowić pozostałe. W obsłudze błędów automatyzacji opisujemy, dlaczego sama lista nieudanych kroków nie wystarcza bez przypisania dalszego działania.
Porównaj nową i obowiązującą wersję
Przed zatwierdzeniem pokażcie różnice: obecna wartość, proponowana wartość, jednostka, waluta, data początku i zakres klientów. Osoba podejmująca decyzję powinna móc przejść od zbiorczego podsumowania do konkretnego wiersza. Przy dużym pliku pomocne będą filtry dla nowych pozycji, zmian przekraczających uzgodniony próg, brakujących dopasowań oraz wartości bez zmian.
Podgląd nie powinien ukrywać tego, co pozostaje poza importem. Jeżeli plik obejmuje tylko jedną grupę klientów albo nie zawiera pozycji wycofanych wcześniej, zaznaczcie ten zakres obok wyniku. Inaczej osoba zatwierdzająca może uznać, że widzi pełny cennik, choć porównanie dotyczy tylko jego części. Użyteczny komunikat pozwala też sprawdzić liczbę odczytanych i odrzuconych wierszy oraz datę źródła.
Zachowajcie wersję, do której porównujecie plik. Jeżeli ktoś w międzyczasie ręcznie zmieni cenę, podgląd może przestać odpowiadać aktualnemu stanowi. Wtedy aplikacja powinna wykryć zmianę i poprosić o ponowne porównanie albo zastosować wcześniej uzgodnioną regułę. O podobnym problemie piszemy przy konfliktach danych między systemami: nowszy zapis nie zawsze jest właściwą odpowiedzią na każde pytanie biznesowe.
Zaplanuj datę wejścia w życie i wyjątki
Nowa cena może obowiązywać od następnego dnia, od początku miesiąca albo od terminu zapisanego w uzgodnieniu z klientem. Ustalcie strefę czasu oraz moment, w którym system uznaje zmianę za aktywną. Pytanie nie kończy się na wyświetleniu daty: trzeba również wiedzieć, jaką cenę zachowa zamówienie rozpoczęte wcześniej i co zrobić z ofertą, która pozostaje ważna przez ustalony okres.
Wyjątek klienta może być zapisany jako osobny cennik, rabat albo warunek w innym systemie. Import ceny bazowej nie powinien po cichu usuwać takiego uzgodnienia. Przed wdrożeniem opiszcie kolejność stosowania reguł, właściciela wyjątku i sposób jego wygaszenia. Na podglądzie warto pokazać nie tylko zmianę pola w bazie, lecz także przykład końcowej ceny dla wybranego, bezpiecznego scenariusza testowego.
Nie musisz rozstrzygać wszystkich warunków handlowych w interfejsie importu. Aplikacja powinna natomiast jasno wskazywać, które decyzje przyjęto, a których jeszcze brakuje. Jeśli system nie potrafi ustalić, czy wyjątkowy warunek nadal obowiązuje, sprawa powinna trafić do osoby uprawnionej do jej wyjaśnienia. Niepewna cena nie staje się pewna tylko dlatego, że zmieściła się w tabeli.
Co zrobić z pozycją, której nie da się dopasować
Wyobraźmy sobie, że w nowym pliku pojawia się kod, którego aplikacja nie znajduje w katalogu. Powodem może być literówka, nowy produkt, zmiana identyfikatora u dostawcy albo pozycja przeznaczona dla innego oddziału. Importer nie powinien wybierać najbliższej nazwy i zapisywać ceny bez potwierdzenia. Podobne nazwy potrafią oznaczać różne warianty, opakowania albo zakresy usługi. Rozpoznawanie wariantów i ryzyko błędnego połączenia opisujemy też w artykule o porządkowaniu katalogu części z AI.
Osobie wyjaśniającej przydadzą się oryginalny wiersz, propozycja dopasowania oraz źródło informacji, na której została oparta. Jeśli zaakceptuje powiązanie, ustalcie, czy ma ono służyć tylko temu importowi, czy również następnym. Trwała reguła wymaga właściciela i możliwości jej zmiany. W przeciwnym razie jednorazowa korekta może po kilku miesiącach przypisywać cenę do niewłaściwego wariantu.
Sprawdźcie też, kto dowie się o pozycji oczekującej na decyzję. Jeżeli wynik pojawi się wyłącznie na ekranie osoby, która uruchomiła import, sprawa zniknie wraz z zamknięciem karty. Lista wyjątków z przypisanym kolejnym krokiem pozwala wrócić do niej później, a pozostałym pracownikom wyjaśnia, dlaczego proponowana cena jeszcze nie obowiązuje.
Oddziel zatwierdzenie od samego wczytania
Ktoś przygotowuje plik, ktoś go sprawdza, a ktoś inny może odpowiadać za publikację. Ten podział nie musi wyglądać identycznie w małej firmie i międzynarodowej organizacji. Ważne, żeby ustalić, kto ma dostęp do podglądu i kto może zatwierdzić zmianę. Przydatne są identyfikator wersji, czas działania, wynik kontroli i informacja o osobie zatwierdzającej.
Jeśli cena ma wejść w życie później, zatwierdzony plik potrzebuje czytelnego stanu: oczekuje, został opublikowany albo wymaga ponownej decyzji. W przypadku błędu integracji osoba odpowiedzialna powinna wiedzieć, czy żądanie dotarło i które systemy potwierdziły zmianę. Brak odpowiedzi nie zawsze oznacza brak skutku. Ten problem omawiamy szczegółowo przy bezpiecznym ponawianiu operacji w API.
Plan cofnięcia również wymaga decyzji. Przywrócenie wcześniejszych wartości nie powinno automatycznie zmieniać historii zamówień, które zostały już przyjęte na określonych warunkach. Zanim uruchomicie taką operację, ustalcie zakres, sposób poinformowania zespołu oraz kontrolę spraw rozpoczętych po zmianie. Podobną ostrożność stosuje się przy migracji danych i planowaniu powrotu, choć cykliczny import ma własny rytm i inne granice.
Przetestuj import na wyjątkach, nie tylko na wzorowym pliku
Przygotujcie próbkę z poprawną pozycją, nieznanym produktem, pustą jednostką, błędną datą i wartością zapisaną w innym formacie liczbowym. Dodajcie przypadek ceny klienta z wyjątkiem oraz sytuację, w której dane zmieniły się po wygenerowaniu podglądu. Ustalcie oczekiwany wynik każdego przypadku przed uruchomieniem testu.
Sprawdźcie także, co zobaczy klient przed wejściem ceny w życie i po nim, oraz czy istniejące zamówienie zachowuje uzgodniony stan. Przy częściowym imporcie porównajcie listę zatwierdzonych i odrzuconych pozycji ze stanem systemu źródłowego. W kryteriach odbioru aplikacji warto zapisać te scenariusze razem z osobą odpowiedzialną za decyzje handlowe.
Jeżeli aplikacja pozwala eksportować wyniki do CSV, potraktujcie dane tekstowe pochodzące z zewnątrz jako niezaufane. OWASP opisuje ryzyko, że program arkuszowy może potraktować część zawartości jako formułę. Sposób zabezpieczenia eksportu trzeba dobrać do odbiorcy i narzędzia, a następnie sprawdzić na przygotowanych przykładach. Samo poprawne parsowanie kolumn przy imporcie nie rozwiązuje tego problemu.
Co przekazać przed rozpoczęciem projektu
Przygotujcie przykładowy plik bez poufnych warunków klientów, opis jednostek oraz informację, skąd pochodzą identyfikatory. Zapiszcie, czy plik jest pełny, kto zatwierdza zmiany i jak dziś wykrywacie rozbieżności. Kilka prawdziwych kategorii wyjątków opisanych bez danych osobowych bywa cenniejsze niż duży arkusz bez wyjaśnienia procesu. Jeżeli ceny docierają do kilku kanałów, wskażcie również, kto potwierdza aktualizację każdego z nich i gdzie handlowiec sprawdza stan zmiany.
Jeśli chcecie uporządkować ten przepływ, zobaczcie nasze integracje systemów albo opiszcie sprawę przez formularz kontaktowy. Wystarczy wskazać źródło cennika, miejsce publikacji i decyzję, którą człowiek powinien podjąć przed zmianą. Zakres walidacji i sposób wdrożenia ustalimy dla konkretnego procesu.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
