Na wstępie, opis algorytmu powyżej wskazany jest zapewne dobry. Zauważyłbym jednak to, że jest bardzo pod konkretny przykład podany i raczej bym nie wstawiał go za wzór dla wszystkich użytkowników. Zapewne działa, ale...
w pliku SpecRozlSpecyfication.fsl  mamy bardziej ogólny algorytm. I wydaje mi się, że warto jednak ten stosować. Dlaczego?
P - tu nie mam się do czego przyczepić, tak tez opisaliśmy w biuletynie, że w tym miejscu należałoby wskazać swoje punkty umowy, dla których DEG1 może mieć zastosowanie
S- no i tu pierwsza uwaga, S podajemy listę usług, dla których to rozliczenie może być stosowane. Natomiast w zarządzeniu mamy odwrotnie. Mamy wskazanie, dla jakich usług DEG1 nie jest używany. Dla takiego rozwiązania jest parametr Q. I staraliśmy w opisanym pliku wymienić wszystkie te usługi, które w zarządzeniu są wskazanie jako te, dla których DEG1 się nie używa. Oczywiście, można przez zastosowanie reguły wypisujemy te, dla których można zamiast wskazywać te, dla których nie można, algorytm tak przygotowaliśmy, by mieć wybór, albo S, albo Q. Ja tylko wskazuję na to, jaka jest treść zarządzenia, a tam mamy usługi wykluczające.
D, X - jako daty, I ok, znów, można tak, ale... DEG1 może być przez trzy kolejne miesiące używane, przez kolejne nie, następnie znów i tak dalej.  Zastosowanie tutaj dat powoduje, że na każdy okres musimy przygotowywać osobne rozliczenie. I znów, można i tak, my natomiast proponujemy użyć zmiennych globalnych zleceń, czyli zapisu VAM=T. A wówczas to, dla których miesięcy DEG1 obowiązuje, a dla których nie, oznaczamy w opcjach. No i warto pamiętać, że takie rozwiązanie, ze zmiennymi zleceń daje radę nawet jak mamy w systemie kilka jednostek dla których DEG1 nie zawsze obowiązuje w tym samym czasie. Kolejna sprawa to brak kodów ICD10 wykluczających DEG1. I znów, zapewne dla tego przykładu kody nie są ważne, bo takich nie używamy. Nie mniej jednak w treści zarządzenia mamy konkretne kody ICD19 dla których DEG1 nie obowiązuje. Dlatego w pliku pojawił się zapis C=C*;D45;D46;D47.0-D47.7
Kolejna sprawa to wiek pacjenta. Zarządzenie mówi iż DEG1 dotyczy pacjentów powyżej 18 roku życia. I znów, zapewne ta sytuacja nie będzie w tym konkretnym przypadku występować chociaż mogę wyobrazić sobie pacjenta w weku lat 15 trafiającego do takiej poradni. Dlatego też w naszym przykładowym pliku mamy określony wiek: A=18-999
To już na pewno tutaj nie wystąpi, ale zarządzenie mówi o tym iż DEG1 nie stosujemy dla rozliczeń fakturami zakupowymi. Dlatego mamy w przykładzie V01=N. I na koniec już całkiem całkiem coś co chyba nie wystąpi, czyli V02=N - o szczegółach pisaliśmy w biuletynie.
Podsumowując, przykład jak powiedziałem, zapewne będzie działać OK, choć mamy tu kilka założeń na zasadzie, pewnie nie wystąpi. Dlatego w mojej ocenie, chyba lepszym rozwiązaniem byłoby przekopiowanie definicji DEG1 z pliku SpecRozlSpecyfication.fsl i uzupełnienie S o właściwe punktu umowy. A później w opcjach ustawienie dla jakich miesięcy DEG ma być liczony. I to wydaje mi się wszystko co zrobić trzeba. Niestety, nie oglądałem zbyt wielu umów więc posiłkowałem się tylko zarządzeniem, dlatego piszę, że mi się wydaje ;-)

Mogę jedynie zgadywać, że problemem jest pusta lista kodów zaopatrzenia? Jeśli tak, to aktualizacja PPSa.

przepraszam za zamieszanie - znalazłem - wszystko wpisuje we wniosku zmian do umowy

Ok, dzieki, zobacze, ale dlaczego znajoma normalnie ma bez hasła, bez wzgledu czy się loguje do normalnego uzytkowania czy robi aktualziacje...

Niech zgadnę, bo znajoma już to zrobiła, to znaczy zmieniła hasło masterkey na jakieś własne, wprowadziła je do systemu i od tego czasu nic się nie dzieje, bo system ma już nieco wyższy poziom bezpieczeństwa. Kilka miesięcy temu ktoś na tym forum nawet opisywał luki w systemach medycznych. Niektóre z systemów miały hasło do bazy zaszyte w kodzie (słowo klucz miały, żeby nikt nie pomyślał, że twierdze iż nadal tak jest). W przypadku systemów KS (chodziło o PPS, bo np SOMED ten temat rozwiązał kilka lat wcześniej) zastrzeżeniem było to, że niektórzy klienci nadal pracują na standardowym haśle do bazy danych, więc ktokolwiek mający jakiekolwiek pojęcie o FB włamuje się do takich bazy jak do swojej. Ponieważ jednak Klienci czasem nie tylko nie zdają sobie z tego sprawy ale wręcz pomijają takie błahostki jak bezpieczeństwo systemu z danymi medycznymi i osobowymi zastosowaliśmy kijek, bo marchewka już działać przestała. Stąd właśnie ta tabliczka mnożenia utrudniająca pracę, choć umożliwiająca.  Raczej nie spotkałem administratora, który nie ugiąłby się pod presją użytkowników testowanych z wcale nie podstawowej znajomości matematyki i nie ustalił własnego hasła do bazy danych.

Nie zmieniasz tam hasła do programu tylko do bazy danych więc je sobie dobrze zapisz bo będziesz je musiał podać przy aktualizacji.