Kamil Rad

Dzisiaj końcowe podsumowanie problemu i podanie jego najbardziej prawdopodobnej przyczyny. Zakładam, że wraz z wprowadzeniem pod koniec 2010 roku "tymczasowej" stawki VAT w wysokości 23% wprowadziłem do stawek Vat ( tabela "sl_StawkaVat") niezbędną pozycję o wartości 23% i nazwałem ją powiedzmy "Tymczasowa stawka VAT 23%". W maju 2011 zdałem sobie sprawę, że tymczasowość będzie trwała ( vide podatek Belki) i usunąłem tę pozycję, wpisując na jej miejsce nową stawkę w wysokości także 23% i nazwie "Podstawowy podatek VAT 23%". Wygląda na to, że zmieniłem także te stawki w większości dokumentów - ale nie we wszystkich. Z punktu widzenia bazy danych ( tabela "sl_StawkaVat") wpis nowej stawki nie odbył się "w miejsce" starej tylko dodano kolejną stawkę, a starą usunięto. W ten sposób na niepoprawionych dokumentach - tych znalezionych kwerendą "StawkiVatSQL-infants-dokumenty-numery" - istniało odwołanie do nieistniejącego wiersza w tabeli "sl_StawkaVat". Jak jednak mogło do tego dojść? Silnik bazy danych InsertaGT, czyli MS SQL Server, automatycznie nakłada na nowo tworzoną tabelę ( dzieje się to np. przy instalowaniu programu) klauzulę "ON DELETE" o wartości "NO ACTION". Oznacza to, że w przypadku usuwania wiersza z tabeli "sl_StawkaVat" SQL Server sprawdzi, czy jakaś inna tabela deklarująca odwoływanie się do jej wierszy ( np. "ob_Pozycja") nie odwołuje się do tego konkretnego wiersza i jeśli takie odwołanie będzie to nie pozwoli na usunięcie wiersza z tabeli "sl_StawkaVat". Moja przygoda z InsertGT trwa od wersji 1.06, która była dystrybuowana wraz z MS SQL Server 2000 i taka funkcjonalność ( tzn. "ON DELETE NO ACTION") już w nim była. Aby pozwolić MS SQL Server na usuwanie z tabeli "sl_VatId" wierszy używanych w innej tabeli należy: 1. Zmienić wartość klazuli "ON DELETE" z "NO ACTION" na np "SET NULL" i wtedy wartość pola "ob_VatId" w tabeli "ob_Pozycja" zostanie wyczyszczona lub 2. Nie zadeklarować w tabeli "ob_Pozycja" pola "ob_VatId" jako "FOREIGN KEY" przez co server nie będzie sprawdzał w tabeli "ob_Pozycja" odwołań do usuwanego wiersza tabeli "sl_StawkaVat". Oba te rozwiązania są jednak błędem programowym, bo prowadzą do utraty spójności danych w bazie skutkującym z kolei błędem walidacji matrycy VAT i w konsekwencji zamykają drogę do aktualizacji oprogramowania. Rynek motoryzacyjny przyzwyczaił nas do bezpłatnych akcji serwisowych w sytuacji gdy producent pojazdu coś sknoci i chce to naprawić. Czy zastąpienie takiego zachowania opcją płatnej usługi AutoKonsultanta lub odesłanie do płatnego serwisu zewnętrznego mogłoby się przyjąć na tamtym rynku? Pozdrawiam wszystkich serdecznie i dziękuję za uwagę, KR

Czy mogłem więc wtedy przypuszczać, że Firma zmieni swoje nastawienie do klientów? No skądże! Byli tacy słodcy. Dzisiaj jednakże muszę stracić kilkanaście minut aby w ogóle wysłać im powiadomienie o znalezieniu przesłanki do wzbudzenia poważnej wątpliwości co do ich jakości jako przedsiębiorcy. I to takiej twardej przesłanki - bazującej na historii rozwoju MS SQL Server, będącego fundamentem rozwoju firmy uznanej jako Microsft Certified for Windows 2000. W lutym 2001 roku program Analityk firmy InsERT S.A. został wyróżniony tytułem Certified for Windows 2000 Professional . Tytuł ten oznacza, że aplikacja spełnia rygorystyczne wymagania techniczne; potwierdza przede wszystkim dużą niezawodność, łatwość obsługi i niższe koszty zarządzania. InsERT S.A. jest pierwszą w Polsce firmą, której produkt uzyskał tytuł Certified for Windows 2000 Professional dla aplikacji typu Desktop. To pierwsze z brzegu uściski Inserta z Microsoftem. A tymczasem spotykam się z zarzutem - z otoczenia tejże firmy certyfikowanej przez Microsoft - że usunąłem w bazie danych rekord zawierający wielkość desygnowaną jako FOREIGN KEY, bądź taką, która powinna być desygnowana jako FOREIGN KEY. Ja już się śmieję, ale wielu nieświadomych, płacących swoje myto użytkowników zaśmieje się za chwilę.

Aby nie być gołosłownym - w 2006/2007 dostałem z Inserta wsparcie w postaci opisu bazy danych. Rozmówca nie tylko udzielił mi informacji n/t jej struktury ale pomógł w rozwiązaniu problemu. I to nie kierując mnie do TeleKonsultanta. W załączniku ówczesne pliki - może społeczność skorzysta. Dokumentacja_DB.xml Dokumentacja_DB.xsl

Muszę zgromadzić cała masę danych aby wysłać Insertowi zapytanie o jego ewentualną pomoc. Nie wystarczy mój login uwiarygodniony wcześniej licencją. To jest dwór - wpuszczają tylko szlachtę. Pamiętam Inserta z lat 2006-2008 gdy wyciągał do użytkownika pomocną dłoń i odbierał telefony przez cały dzień. Dziś wyciąga tylko kieszeń.

Na wszelki wypadek skorzystam z sugestii SN wskazującej, że administrator portalu może nie znać treści na nim zamieszczonych i trzeba mu wyraźnie zakomunikować co jest napisane na koszulce, którą nosi.

Dzień dobry Państwu! Dzięki pomocy Pana Kozłowskiego rozpoczynamy nowy etap w dochodzeniu przyczyn błędów w walidacji stawek matrycy VAT, które to błędy uniemożliwiały uaktualnienie oprogramowania i zgodnie z sugestią Pana Kozłowskiego kierowały osoby dotknięte tym problemem w stronę płatnej pomocy w formie TeleKonsultanta lub serwisanta. Ponieważ Pan Daniel Kozłowski jest Partnerem firmy Insert i jako zewnętrzny podmiot akceptuje i zaspokaja potrzeby na swoje usługi bez względu na przyczynę ich powstania, chciałbym zapytać przedstawiciela firmy Insert - a wiemy, że to forum obserwują tacy - czy także jego zdaniem skierowanie użytkownika Subiekta GT po płatną pomoc w sytuacji wystąpienia problemów takich jak u mnie jest właściwe?

Upgrade do 1_63_SP2 zakończył się powodzeniem - konwersja bazy danych odbyła się bez przeszkód. Wszystkie błędy wyglądały identycznie jak opisany powyżej: w oknie edycji dokumentu handlowego ( u mnie były to fry sprzedaży i zakupowe) w kolumnie "VAT %" nie było wpisanej stawki, choć zarówno tabela VAT dokumentu jak i jego wartość brutto były wyliczone poprawnie a zatem dokument wprowadzono poprawnie moim zdaniem. Zmiany powstały później - ale jak? Subiekta GT używam od 2006 roku na potrzeby jednoosobowej działalności gospodarczej. Żeby zamknąć temat z pełnym przekonaniem o znalezieniu faktycznej przyczyny muszę sprawdzić czy jest możliwe doprowadzenie do takich błędów działaniem użytkownika.

Witam - dzisiaj zrobiłem kwerendę, która doprowadziła mnie do pełnych numerów dokumentów handlowych ( sprzedaż i zakup), na których istnieją stawki VAT niezdefiniowane w słowniku stawek VAT. Jedną z faktur sprzedażowych już poprawiłem i okazało się, że nie miała wpisanej wartości procentowej w kolumnie "Vat %". Co ciekawsze, końcowa tabela VAT widniejąca w zakładce "VAT" na dole strony podczas wypisywania dokumentu była wypełniona poprawnie i wykazywała tę stawkę a faktura miała tylko jedną pozycję. Załączam jak zwykle tekst kwerendy i jej wynik w moim przypadku. Teraz zacznę poprawiać wylistowane dokumenty i spróbuję zrobić upgrade programu i bazy do wersji 1.63_SP2. Pozdrawiam, KR StawkiVatSQL-infants-dokumenty-numery.pdf

Pozdrawiam Pana Kozłowskiego, którego aktywność na forum przynosi wielu użytkownikom pomoc i rozwiązanie ich problemów. Dokończę jednak ten wątek, bo moim zdaniem zakończenie jest ciekawsze niż sam problem, a sam sposób dotarcia do tego rozwiązania może być cenną wskazówką na przyszłość dla wielu strapionych użytkowników Inserta. Mamy więc znalezione stawki VAT użyte w dokumentach handlowych, które to stawki nie są opisane w słowniku VAT. Pomijam w tej chwili bardzo ważne pytanie o to w jaki sposób te stawki VAT znalazły się w dokumentach, skoro nie ma ich w słowniku stawek. Nowa kwerenda wyszukuje identyfikatory dokumentów handlowych i magazynowych, których pozycje zawierają odwołania do nieistniejących w słowniku stawek VAT. Ponieważ jeden z czytelników forum zwrócił mi uwagę, że nie wie gdzie wpisywane są teksty kwerend to informuję, że należy wejść w moduł "Zestawienia", wybrać z rozwijanego menu pozycję "SQL" i wcisnąć klawisz Insert aby pojawiło się okno dodawania nowego zestawienia, zawierające dwie zakładki: - nazwę/opis nowego zestawienia ( wpisujemy co chcemy) - tekst kwerendy SQL ( tu właśnie wpisujemy tekst od słowa "select" do średnika włącznie) StawkiVatSQL-infants - dokumenty.pdf

No dobrze, musimy podsumować bo to bardzo ważny etap - w tabeli "dok_Pozycja" zawierającej opis pozycji z dokumentu sprzedażowego ( np. faktura) znaleźliśmy odwołanie do NIEISTNIEJĄCEGO rekordu w tabeli "sl_StawkaVat". To bardzo ważna konstatacja - kto ma wątpliwości niech prześledzi ścieżkę dowodową raz jeszcze.

A jednak jestem dzisiaj. Jestem leniwy, więc do roboty zaprzągłem Subiekta GT produkcji firmy Insert. Napisałem prostą kwerendę, pytającą które ze stawek wymienionych we wszystkich pozycjach wszystkich dokumentów sprzedażowych nie istnieją w słowniku stawek VAT zapisanym w bazie danych InsertGT prowadzonej przez MS SQL serwer. Wynik zapytania wraz z tekstem kwerendy jest w załączniku. StawkiVatSQL-infants.pdf

Jabłuszka malina. Wątek ma prawie 600 wyświetleń. Zachęcam do śledzenia, bo kroi się grubo w kontekście zwalczania arogancji.

Witam ponownie! Korzystając z sugestii Pana Kozłowskiego zapytałem tabelę "dok_Pozycja" o to, jakie identyfikatory stawek VAT są w niej zapisane. Wynik wraz z tekstem prostego zapytania SQL załączam poniżej w nadziei, że pomoże w samodzielnym dochodzeniu problemów z programami Insert. Teraz przed nami jest porównanie znalezionych identyfikatorów VAT_id z zawartością słownika stawek VAT. Ale to jutro, bo teraz muszę zebrać jabłka z drzewa gdyż przejrzały ( papierówki). Obroty_VatId.pdf

Witam i dziękuję za sugestię, zrobię kwerendę na unikatowe vat_id po wszystkich dokumentach i porównam z ujawnionymi stawkami. Pozdrawiam,