Daniel Kozłowski

Aby wszystko działało dobrze polecam przenieść cały system operacyjny z całą zawartością, a nie tylko dane programów.

Proszę rozważyć skorzystanie z innego formatu.

Programy i cały świat nie są idealne, proszę wybrać możliwe najlepsze dla Pana rozwiązanie. Rozwiązanie jest znane, powtarzane niezliczoną liczbę razy - zlecić taką usługę serwisantowi, ale że to ogromne nakłady finansowe i czasowe to w praktyce należy odpowiedzieć sobie na pytanie: po co to wszystko ? Czy nie prościej i taniej będzie utrzymywać te podmioty archiwalne przez kolejne 5 lat ?

Proszę wybrać rozwiązanie, które jest dla Pan dopuszczalne, na przykład linię nexo. Kiedyś taki sytuacje zachodził dużo rzadziej, a w linii GT nie liczyłbym na tak duże zmiany, po to właśnie między innymi powstała linia nexo, aby odciąć się od ograniczeń linii GT.

Jak próbowałem wytłumaczyć był to zbędny wyjątek. Powinno być oczywistym, że nie wszystko co jest opisane w internecie jest prawdą. Kolejny raz się Pan myli, jest kompletny, wręcz nadmiarowy, ale ta nadmiarowość nie powoduje problemów, jak już więcej niż raz próbowałem wytłumaczyć, że portu dynamicznego NIE należy podawać w wyjątkach, gdyż jest dynamiczny, może ulec zmianie. Ja jestem jednym i drugim - znam teorię, wiem jak działa serwer SQL Microsoftu i wiedzę tę z powodzeniem stosuję z praktyce. Tak, dyskusja bez argumentów jest bez sensu, kto i w jaki sposób może Pana przekonać, że się Pan myli ? Już to próbowałem wytłumaczyć - będzie działać do czasu zmiany portu dynamicznego, więc ostrzegam wszystkich czytający ten wątek, aby NIE stosowali tego rozwiązania. Jest zasadnicza teoretyczna i praktyczna różnica między korzystaniem z programu, a jego wdrażaniem i serwisowaniem, jeśli po tylu latach Pan jej nie dostrzega, to najwyraźniej błędnie wybierał Pan dostawców programów i nawet nie wie co przez tyle lat tracił... W GT instrukcja konfiguracji zapór, krok po kroku, ze zrzutami ekranu znajduje się w pomocy do programu, konfiguracja jest taka sama dla GT, nexo i każdego innego programu łączącego się z serwerem SQL.

Ja bym wprowadził datę nabycia środka trwałego.

Proszę podzielić się tutaj rozwiązaniem problemu.

Jak już wytłumaczyłem zupełnie nie potrzebnie, taki wyjątek NIE jest wymagany. Jak wyżej, nie podałem takiej informacji, gdyż jest całkowicie zbędna. Jak już wytłumaczyłem port 1433 będzie funkcjonował jeśli zostanie skonfigurowany, podobnie jak każdy inny port. Skąd ten pomysł, to całkowicie zbędne, domyślnie zapory NIE blokują ruchu wychodzącego. Nie prawda, nie będzie działać stabilnie, może przestać działać - przecież jak sama nazwa wskazuje port dynamiczny oznacza, że może ulec zmianie. Zostało to już zrobione wiele razy, zrobił to również InsERT: https://www.insert.com.pl/dla_uzytkownikow/e-pomoc_techniczna/2521%2Cinsert-gt-dlaczego-program-nie-laczy-sie-z-serwerem-na-koncowce-polaczenie-stanowiska-bez-serwera-sql-do-stanowiska-ktore-pelni-role-serwera.html Delikatnie mówiąc nie rozumiem tego wyboru. I co otrzymuje Pan w zamian ? Proszę rozwinąć wypowiedź, gdyż nie zrozumiałem.

Nie. Tak jak uruchamiany jest program pierwszy raz lub główne menu->Operacje->Uruchom inny program nexo.

O to również, lecz najwyraźniej nie zastosował się na mojej sugestii i nie zapoznał się z możliwościami programu - nie wystawi Pan paragonu w walucie CZK, gdyż program nie posiada takiej funkcjonalności, skoro program tego nie potrafi, to zewnętrzny program jak Sello też tego nie zmieni. Należy zacząć od początku, określić swoje oczekiwania (jaki dokumenty chce Pan tworzyć), poznać możliwości Subiekta (wspomniałem o ograniczeniach paragonów), poznać możliwości Sello (tych nie znam, odsyłam do forum Sello) i w oparciu o te informacje skonfigurować Sello i opcjonalnie Subiekta (przy sprzedaży SK raczej nie ma takiej potrzeby, no chyba, że dodanie czeskiego rachunku bankowego do płatności w CZK) do swoich potrzeb.

Nie do końca, instancja domyślna, ponieważ jest jedna, domyślna standardowo instaluje się ze stałym portem, instancje nazwane, ponieważ może być ich wiele, standardowo instalują się z portami dynamicznymi, ale zawsze port dynamiczny możemy przekonfigurować na stały. Ja preferuję wyjątek na port dla Browsera (UDP 1434) i na aplikację dla serwera SQL. Proszę rozważyć skorzystanie z pomocy wybranego dostawcy programu, dla takiej osoby to kilka minut lub krócej. Gdyby pokazał Pan co faktycznie ustawił, to byłaby szans, aby wskazać gdzie został popełniony błąd.

Edukacyjnie - proszę spróbować. No ogromna, należy się zarejestrować do OSS, prowadzić sprzedaż w stawkach VAT kraju konsumpcji... Polecam zapoznać się z przepisami, skonsultować z księgowością.

Próbował Pan wystawić oczekiwany dokument ręcznie, z poziomu Subiekta ? Jaką sprzedaż Pan prowadzi do Czech (zakładam, że dla osób fizycznych) - krajową poniżej limitu (SK), czy powyżej limitu (OSS) ?

Dane kontaktowe udostępniam w profilu forum na zakładce "O mnie".

Jak objawia się problem ? Skąd mamy wiedzieć jak wystawia Pan dokumenty dla transakcji krajowych ?

Przecież napisałem co dokładnie można zrobić: -- Ale którą dokładnie ? Cały czas proponuję spróbować naprawić oryginalną bazę danych, skoro dało się skopiować tabele to może nie jest z nią tak źle. Jeśli chodzi o tę bazę do której zostały skopiowane same tabele to nie ma czego analizować, wiadomo co zostało źle zrobione, wiadomo co należy zrobić, ale póki się nie spróbuje to nie będzie wiadomo czy się uda, czy po nałożeniu kluczy obcych nie okaże się, że dane są niekompletne, nie są spójne. Piszę z doświadczenia z napraw i przywracania takich baz zdanych do użytku lub do podglądu. Proszę przemyśleć dobrze sugestie kolegów, a jeśli mimo wszystko będzie Pan zainteresowany to proszę jutro o kontakt, jeśli nie będę odbierał to proszę o SMS.

To była propozycja rozwiązania na podstawie opisu problemu oraz znajomości rozszerzania programów InsERT, nie znam gotowego rozwiązania, należałoby je zamówić, technicznie na dzień dzisiejszy mogłaby to być kolejna pozycja / operacja w menu programu.

Aby nie było nieporozumień, proszę doprecyzować na jaką pomoc Pan liczy. Oczywistość, że to NIE wystarczy, baza SQL jak Microsoft SQL Server danych to nie są same tabele, są to również indeksy, klucze obce, triggery na tabelach, są to funkcje i procedury składowane - należy odtworzyć całą strukturę bazy danych, należało spróbować naprawić bazę danych lub przekopiować dane do nowej bazy danych programów InsERT GT, co przez dodatkowe obiekty bazy danych nie jest takie proste i oczywiste. To w większości efekt braku pozostałych obiektów bazy danych jak triggery i procedury składowane.

Swój pomysł przecież opisałem: Proszę w takim razie dostosować się do dostawcy i przyjmować towary dokumentami, na których będzie znajdował się tylko jeden towar. Powinien Pan tylko widzieć, że takie sugestie funkcjonalności wykorzystywanych przez bardzo małą liczbę użytkowników, które można usprawnić (wspomnianą) zmianą organizacji pracy (ze wspomaganiem ewentualnymi rozwiązaniami dodatkowymi, który na przykład rozbijałby PZ z wieloma pozycjami na wiele PZ z jedną pozycją), w praktyce mogą doczekać się realizacji po wielu, wielu latach. nie odniósł się Pan do niego, więc założyłem, że Pana nie interesuje, teraz jednak nie wiem, czy po prostu nie przeczytał Pan mojej odpowiedzi, czy jej nie zrozumiał, jeśli to drugie to proszę doprecyzować co mam spróbować wyjaśnić w inny sposób.

Nic takiego nie sugerowałem, nie da się stworzyć takiego rozwiązania, gdyż program nie przewiduje takiego układu danych (wielokrotnej realizacji dokumentu PZ). Nie rozumiem natomiast dlaczego tak upiera się Pan przy rozwiązaniu, którego nie można zrealizować, a nie korzysta z innego rozwiązania, które jest możliwe do wdrożenia, które da taki sam efekt, czyli znacząco ułatwi dokumentację transakcji z tym dostawcą.

Nie wyjaśnił Pan jak powstała ta nowa baza w tym jak został utworzony plan kont... Z dotychczasowych doświadczeń nie spotkałem się z przypadkiem takiego częściowego odłączenia kartoteki, spotykam się często z przypadkami nie podłączania się kartoteki, dzieje się tak zwykle przez powielone analityki kontrahentów. Nie niej każda operacja powinna zakończyć się w takiej sytuacji komunikatem błędu dla użytkownika, a użytkownik powinien jak najszybciej wyjaśnić przyczynę.

Nie jest Pan naszym klientem, więc na pewno nie mogę wziąć tej winy na siebie. Prawda jest niestety taka, że to klienta wybiera dostawcę programów, sposób ich poznawania i rozpoczynania pracy, nie robi tego producent oprogramowania czy jego dostawca. Nie opisał Pan jak to wyglądało w Pana przypadku. Ale jak niby miałbym pomóc, kiedy "mleko już się rozlało" ? Próbuję pomóc wskazując jak można rozwiązać problem dostępnymi metodami funkcjonalnościami - wystarczy stosować w nexo symbole o długości do 20 znaków - czy to nie jest pomoc według Pana ? Czego Pan oczekuje w tej sytuacji od mnie ? Niestety to nie tak, nie mówimy o jakimś drobiazgu tylko o jednym z podstawowych procesów w Pana firmie - pracy handlowców... Ograniczenia programów / różnice między liniami programów są bardzo dobrze znane osobom, które zajmują się wdrożeniami i serwisem programów, warto korzystać z takiego wsparcia, aby unikać niepotrzebnych nikomu problemów, gdyby tylko zadzwonił Pan do takiej firmy jak nasza, opisał skrótowo jak Pan pracuje, to dowiedziałby się Pan tego, co teraz w tym wątku, że nexo nie posiada funkcjonalności komunikacji centrala<->oddział. Nie mam nic przeciwko dyskusji na forum, staram się tylko przedstawić jak to wygląda z innej strony, nie producenta, a dostawcy programów. Najwyraźniej Pan nie zrozumiał, nie pisałem o pracy zdalnej tylko o dedykowanym rozwiązaniu mobilnym, a rozwiązania takie pracują offline ze względu na ograniczenia, które Pan wskazał.

Niestety to czy moje sugestie coś wniosą NIE zależy ode mnie - nie mam wpływu na to, czy będzie Pan chciał uprawnić sobie "mega czasochłonne" operacje w programie za pomocą dostępnych możliwości czy też nie. Poza tym jak sam Pan zauważyłem, nie jest Pan pierwszym i zapewne ostatnim użytkownikiem z takim problemem, może ktoś inny skorzysta i usprawni sobie pracę, nikt przede mną nie zaproponował żadnego usprawnienia w zgłaszanym obszarze.

Ciężko się tłumaczy oczywiste kwestie, ale spróbuję... Najzwyczajniej w świecie ktoś to fizycznie musi zrobić, na to potrzeba czas, a jest mnóstwo innych rzeczy do zrobienia z dużo większym priorytetem... Poza tym to tylko "łatanie dziury w asfalcie po zimie", gdzie za rok jak nie wcześniej będzie kolejna, większa... Dla nexo powinien powstać nowy format, który obsłuży wszystkie informacje dostępne w nexo, z którego w ograniczonym zakresie skorzysta GT, od dawna są już takie plany bo to jedyny słuszny kierunek, ale jak wyżej - do tego potrzeba czasu. Oczywiście, że nie, to może doprowadzić do błędów poważnych w konsekwencjach - napisanie / zamiana kartotek innymi kartotekami.

Rozumiem jeszcze mniej... Skoro chciała Pani wprowadzać ręcznie BO to założyłem, że jest pierwszy rok pracy z programami InsERT, a BZ pochodzi z innego programu... Rozumiem teraz, że to niestety nie jest pierwszy rok pracy tylko kolejny - który to rok pracy, drugi ? Czy w ogóle w poprzednimi roku było wprowadzone BO na tym rachunku, czy był wprowadzony magazyn walut, naliczane różnice kursowe ? Nic nie dzieje się automatycznie, to użytkownik musi wywołać operację przeniesienia BZ na BO... Skoro bilans przeniósł się to dlaczego chce go Pani wprowadzać ręcznie ? No chyba, że jednak się nie przeniósł, a jeśli tak to z jakiego powodu - pojawiły się jakieś błędy przy jego przenoszeniu ? Proszę rozwinąć co to znaczy "nie można wpisać". Proszę opisać problem dokładnie, od początku, co zostało wykonane w programie.