Dzięki za pierwszą konkretną odpowiedź, ale mam kilka uwag:
1) Raczej złym pomysłem jest przywracanie domyślnego układu klawiatury - jeśli chce się przeprogramować tyko 1-3 klawisze.
Pytanie jaką procedurą programuje się te dodatkowe przyciski [kod, spr. ceny, auto 1, klient itd...]. Zapewne mają swoje numerki. Mam przed sobą 12 stronę instrukcji użytkownika, gdzie narysowany jest układ klawiatury - tam ponumerowane są tylko bezpośrednie klawisze grup - ale nie ma numerków tych specjalnych. Jak wygląda procedura ustawienia tych specjalnych klawiszy - bo na pewno inaczej niż klawiszy bezpośredniego dostępu do grup, towarów.
Jakby jeszcze ktoś był tak miły i wyjaśnił mi dlaczego procedurą czytającą 2119 otrzymuje:
001 - G01
002 - G02
003 - G03
... (wszystkie po kolei)
a na 100% grupy te nie są w tej kolejności przypisane do przycisków. Po przypisaniu przeze mnie grupy do jednego bezpośredniego przycisku, ten konkretny przycisk ma już dobrze zaprogramowaną grupę, ale pozostałe źle - ale tylko na raporcie, sprzedaż idzie na odpowiednie grupy.
Dodatkowo strona 40 instrukcji użytkownika zawiera błąd - pomieszane są kolejności przycisku i nr grupy.
2) Nie widzę nic błędnego w stwierdzeniu że kasa ma "rozszerzoną pamięć na eany". Jak już pisałem jestem programistą (kiedyś programowałem również mikrokontrolery i takie pamięci) i wiem mniej więcej jak to wygląda.
Wiem że pamięć której nie zna się struktury (można nazwać to metadanymi) jest tylko przypadkowym zbiorem wartości które bez BARDZO dogłębnej analizy nic nie mówią.
Domyślam się że pamięci nadaje się strukturę - określone mianem pliku ean, towarów i grup towarowych itd. Zapewne samą strukturę niektórych plików można zmieniać - dodając lub odejmując poszczególne pola (tłumaczyłoby to brak w mojej kasie ilości magazynowych, i wartości sprzedaży dziennej lub okresowej - nie pamiętam dokładnie której ale stawiam na dzienną).
Domyślam się że programuję się położenie tych plików w pamięci fizycznej (początek i koniec pliku - co decyduje bezpośrednio o możliwej maksymalnej ilości eanów i towarów). Prawdopodobnie możliwe jest również stworzenie jednego logicznego pliku na dwóch fizycznych kościach pamięci (o ile w kasie jest tak że można kość dołożyć a nie wymienić na większą).
Tak więc moje stwierdzenie "rozszerzona pamięć na eany" było bardzo ogólne i mogło kryć:
- zmianę struktury rekordu pliku eanów, towarów lub obu na raz (samo usunięcie z metadanych poszczególnych pól daje już możliwość zwiększenia ilości maksymalnych rekordów),
- zmniejszenie wielkości pliku towarów na rzecz pliku eanów w ramach "podstawowej" kości pamięci,
- dołożenie, lub wymiana podstawowej kości na większą.
Każda kombinacja wpływa na maksymalną ilość rekordów w pliku. Tak więc pisząc "rozszerzona pamięć na eany" na pewno nie miałem na myśli kości na której jest napisane "pamięć na eany" - którą się wpina obok kości z napisem "pamięć na towary".
3) Czy wiesz może jak sprawdza się położenie poszczególnych plików w obszarze zagospodarowanym - tak by można było sprawdzić/obliczyć maksymalną ilość rekordów?
4) Mówiłem konkretnie o procedurze 1000(eany) ze strony 105 (uprzedzając pytanie - nie działa nawet po raporcie dobowym). Po wprowadzeniu 1000 [x] kasa od razu zaczyna bipać - nie mam możliwości wprowadzenia kodu kreskowego, ani nawet [gotówka].
Zaznaczam że procedury umieszczone wyżej w tabelce 1100 i 1200 ładnie działają i wyświetlają to co trzeba.
Przyznam że nie robiłem raportu 109 lub 209 czytającego - jedynie zerujący na koniec poprzedniego roku. Niestety z niewyjaśnionych przyczyn raport ten nie wyzerował mi wartości i ilości sprzedaży - sprawdzane programem komputerowym.
5) "Podczas rejestracji sprzedaży raczej nie są dostępne żadne procedury modyfikacji PLU/EAN... raczej"
Prawdopodobnie procedura 1000 [.] [x] (strona 61) nie rozróżnia dodania nowego eanu od jego modyfikacji i można ją wykonywać jedynie po raporcie dobowym. I wcale nie chodzi o to że nie można modyfikować pliku ean bo za chwilę napisane jest że przy odpowiednich ustawieniach można w trybie rejestracji sprzedaży z pominięciem pliku kodów tymczasowych wprowadzać eany bezpośrednio do pliku eanów. Dodatkowo sam pisałeś że program magazynowy nie ma takich problemów.
Wniosek - niedopracowana procedura 1000 która w trybie rejestracji sprzedaży powinna najpierw sprawdzić czy dany ean jest już w bazie. Jeśli jest to zgłasza błąd w przeciwnym razie użytkownik ma możliwość wprowadzenia parametrów dla tego eanu.
6) Niestety skasowałem już te eany, które miały literki na końcu i nie podam szczegółów.
7) Wiem że przyciski makro to przyciski auto, jakby nazwać je przyciskami wyzwalającymi to też wiadomo by było o jakie przyciski chodzi.
Piszesz że nie ma sensu by przyciski auto działały w trybach PGM - ja taki sens widzę. Ponieważ kasa ma ograniczoną ilość współpracujących urządzeń do maksymalnie dwóch (2 porty rs232, z czego drugi może współpracować z czytnikiem kodów kreskowych, zaś pierwszy z komputerem lub wagą, lub oboma na raz pod warunkiem że port drugi nie jest zdefiniowany

).
Śmieszne - znowu niedopracowanie. Oczywiście do kasy w moim przypadku na stałe podpięty jest i czytnik kodów kreskowych i waga. W związku z czym myślałem o pudełku do którego wchodzi kabel od wagi i komputera, wychodzi kabel do kasy, dodatkowo pudełko posiada przełącznik. Gdyby była możliwość wyzwalania auto w PGM2 to zdefiniowałbym 2 przyciski auto:
- jeden programujący port pierwszy rs232 do współpracy z wagą,
- drugi programujący port pierwszy rs232 do współpracy z komputerem.
Wtedy takie rozwiązanie mocno automatyzuje proces aktualizacji bazy towarowej z komputera, przy teoretycznie wykorzystanej do maksimum ilości współpracujących urządzeń:
- ustawiam kluczykiem tryb PGM2,
- naciśnięcie jednego przycisku na kasie sprawia że programuje rsa do współpracy z komputerem,
- ustawiam przycisk na pudełku (o którym przed chwilą pisałem) w pozycji do puszczania sygnału z komputera,
- włączam synchronizacje danych z programu (wiem że nie jest to pełna synchronizacja bo, niektóre operacje wymagają raportu dobowego),
- ustawiam przycisk na pudełku (o którym przed chwilą pisałem) w pozycji do puszczania sygnału z wagi,
- naciśnięcie jednego przycisku na kasie sprawia że programuje rsa do współpracy z wagą,
- ustawiam kluczykiem tryb Reg.
Tak więc jak widzisz w moim przypadku - ale myślę że nie tylko moim - wyzwalanie sekwencji przycisków w PGM2 byłoby uzasadnione.
Pozwalałoby niezbyt mocno zaawansowanemu użytkownikowi na szybkie, i z pewnymi zabezpieczeniami, podgrywanie bazy towarowej.
Tak więc już widzisz dlaczego uważam że ta kasa to złom patrząc na specyfikację i cenę chociażby kasy elzab z serii delta.
Od razu zaznaczam nigdy z taką kasą nie współpracowałem, i porównuję jedynie po przeczytaniu instrukcji użytkownika do obu tych kas. Zdaję sobie sprawę, że jak ze wszystkim, dopiero praktyka zweryfikuje użyteczność i bezawaryjność kasy.
Ale zastanawia mnie dlaczego Sharp (Torell) nie udoskonala tej kasy (nie mówię o terminalach POS) - w sumie niewiele trzeba, ale te niedoskonałości są mocno irytujące jeżeli się oczekuje czegoś więcej niż tylko wykorzystanie jednostanowiskowej kasy do wprowadzania sprzedaży przez grupy towarowe.