Systemy magazynowe mają zestawienia obejmujące przypadek typowy. Pytania, które naprawdę zadaje właściciel firmy, rzadko są typowe.
Własne zapytanie do bazy jest najkrótszą drogą do odpowiedzi, bo omija ograniczenia gotowych zestawień. Jest też najkrótszą drogą do liczby, która wygląda wiarygodnie i jest błędna. Poniżej rzeczy, które decydują o tym, po której stronie skończy raport.
Dostęp wyłącznie do odczytu
Raport nigdy nie powinien mieć uprawnień do zapisu. Osobne konto z prawem odczytu chroni przed sytuacją, w której literówka w zapytaniu zmienia dane zamiast je pokazać.
Takie konto zakłada się raz, dla wszystkich zestawień, i ogranicza do tabel, które są rzeczywiście potrzebne. Przy okazji rozwiązuje to drugi problem: kto widzi marże i dane kontrahentów. Zakres widoczności ustala się wtedy w jednym miejscu, a nie przy każdym nowym raporcie — szerzej opisuje to tekst o uprawnieniach do raportów.
Struktura bazy nie jest oczywista
To samo pojęcie bywa zapisane w kilku miejscach: cena na dokumencie, cena w kartotece, cena po rabacie. Raport zbudowany na złej kolumnie daje liczby wyglądające poprawnie i będące nieprawdą.
Weryfikacja polega na porównaniu wyniku z zestawieniem standardowym programu dla tego samego okresu. Rozbieżność zawsze oznacza, że jedno z nich liczy co innego — i trzeba zrozumieć, które.
Pomaga prosty nawyk: zanim powstanie zapytanie, wypisać definicje. Czy sprzedaż liczymy netto czy brutto, według daty dokumentu czy daty wydania, czy wchodzą do niej dokumenty magazynowe bez faktury. Te rozstrzygnięcia ważą na wyniku bardziej niż sposób napisania zapytania. Uporządkowaną kolejność pracy opisuje wdrożenie własnych raportów krok po kroku.
Dokumenty anulowane i korekty
Najczęstsze źródło zawyżonych wyników. Zapytanie sumujące sprzedaż bez wyłączenia dokumentów anulowanych i bez uwzględnienia korekt pokazuje obrót, którego nie było.
Podobnie działają dokumenty pozostawione w buforze, zamówienia potraktowane jak sprzedaż i faktury zaliczkowe policzone drugi raz przy rozliczeniu końcowym. Warto sprawdzić, jakie stany dokumentu w ogóle występują w bazie, i świadomie zdecydować, które wchodzą do zestawienia. To decyzja merytoryczna, nie techniczna.
Wydajność
Zapytanie przechodzące całą historię przy każdym otwarciu zestawienia obciąża serwer używany przez wszystkich. Przy dużych bazach lepsze jest wyliczanie cykliczne i odczyt gotowego wyniku.
Skutek odczuwa cała firma: wystawianie dokumentów zwalnia dokładnie wtedy, gdy ruch jest największy. Zawężenie domyślnego zakresu dat i przeniesienie ciężkich wyliczeń poza godziny pracy zwykle wystarcza. Trudniejsze przypadki omawia tekst o wydajności raportów na dużych bazach.
Zmiana wersji systemu
Aktualizacja potrafi zmienić strukturę tabel. Raporty własne trzeba sprawdzić po każdej — i to jest koszt stały, nie jednorazowy.
Dlatego warto trzymać zapytania w jednym miejscu wraz z krótkim opisem, co liczą i dla kogo powstały. Po roku nikt tego nie pamięta, a raport bez opisu zwykle kończy jako raport nieużywany.
Kiedy się to nie opłaca
Jeśli odpowiedź daje standardowe zestawienie programu albo zwykły eksport do arkusza, własne zapytanie jest pracą do wykonania i do utrzymania bez realnego zysku. Podobnie przy pytaniu zadawanym raz — prościej policzyć je ręcznie i zapomnieć. Zapytanie SQL ma sens wtedy, gdy pytanie wraca regularnie, dotyczy danych, których gotowe zestawienia nie zestawiają ze sobą, a odpowiedź ma prowadzić do decyzji.
