Krzysztof Jakubowicz

Część dalsza wywodu 6. Skoro tak to chętnie przeniósłbym zapis z dekretacji sprzedaży do wpłaty bankowej który teraz totalnie wyglądałby jak masło maślane 201-PodmiotCesyjny | 139 130 | 200-PodmiotCesyjny 7. skoro tak to z chęcią wielką opuściłbym zapis z kontem 201-PC ale na obrotach z Podmiotem Cesyjnym miałbym zero? moim zdaniem niedpuszczalne 8. i na koniec jeszcze jedno zagadnienie, klient kupił towar 30 grudnia Podmiot Cesyjny spłacił 5 stycznia roku następnego, pytanie brzmi na jakim koncie ma zostać zapis na koniec roku? na 139 pieniążki w drodze czy na Podmiocie Cesyjnym? może ktoś z wiedzą księgową lub z praktyką wdrożeniową naświetli temat? pozdrawiam Krzysiek

Witam wszystkich Przedstawiony sposób dekretacji jest zgodny z występującym w wersji testowej, zastanawia mnie jednak kilka zapisów 1. Schemat dekretacji FS w poz 3 powinien być po stronie Ma ale mniejsza o to 2. jako laika boli mnie zapis przy dekretacji WB (wpłata bankowa) który zawiera konto kasy Wn 139 Ma 101 3. logicznie rzecz biorąc skoro w dekretacji KP (nie widzę grafiki ale zakładam że ma taką postać) klient został spłacony dokumentem kasy Wn 101 Ma 200-.. to pytanie co się stało z tymi pieniążkami? bo w kasie ich nie ma, ano moim zdaniem są w drodze, i taki zapis widzę właśnie w dekrecie WB który z chęcią przeniósłbym do dekretacji dokumentu KP który miałby postać 100 | 201-Klienci 139 | 101 4. i tu zaczynają się schody bo w dekretacji sprzedaży widzę zapis 201-Klienci | 139 czyli pieniążki w drodze już nie są bo 139 się rozliczyło 5. na dodatek na koncie 139( pieniążki w drodze) po stronie Ma w przypadku standardowego przekazywania pieniążków z kasy do banku zapis jest tworzony przez dekretację WB (wpłaty bankowej)

Problem czasowo oddalony - shrink odchudził nieco bazę

Witam Ciekaw jestem opinii na temat ograniczeń Sql Express i sposobu rozwiązania. Przykładowy Windows serwer Foundation, SQL Express 2014 z bazą założoną w 2016 NEXO Pro po imporcie danych z innego systemu szybko przybiera na wadze. Według wyliczeń krytyczną wielkość 10GB osiągnie w marcu 2019. Można oczywiście kupić runtime sql na 5 wykorzystywanych stanowisk i zapomnieć o tym ograniczeniu, zastanawiam się jednak czy jest to zasadne skoro to jedyne ograniczenie?. Wydajność systemu, szybkość działania jest zadowalająca, wielkość bazy przybiera w związku z dużą ilością dokumentów handlowo/magazynowych (hurtownia). Rozwiązanie z pełną wersją sql budzi moje niezadowolenie między innymi w związku z archiwizacją/zabezpieczeniem systemu. Aktualnie archiwum po spakowaniu to 1,5GB i jeszcze jest do przyjęcia ale co dalej? Dlaczego mnie to martwi? kopia to nie tylko zabezpieczenie przed awarią również wypadkami losowymi, kradzież, zalanie, pożar.. miałem również w swojej historii ataki wirusów szyfrujących. Dlatego umieszczenie kopii w bezpiecznym miejscu poza firmą jest równie ważne, wystarczy spojrzeć na ofertę archiwum w chmurze by zobaczyć że przesłanie 3GB pliku nie wchodzi w grę nie tylko z względów finansowych ale często technicznych. Zacząłem się zastanawiać nad utworzeniem nowej bazy i wyeksportowaniem tam kartotek kontrahentów i towarów (nowy rok, inwentaryzacja..) rozrachunki księgowość mogła by sprawdzać w starej bazie, ok ale co z płacami? (Gratyfikant) co prawda pracowników kilkunastu i można wklepać podstawowe dane ale z pewnością o czymś się zapomni, nie weźmie pod uwagę i wystąpią problemy. Super by było gdyby można dokumenty dotyczące poprzednich okresów zarchiwizować i odchudzić bazę. Chętnie wysłucham pomysłów na zmniejszenie rozmiaru bazy (NEXO)