Program magazynowy współpracujący ze skanerem kodów kreskowych i drukarką fiskalną.

Odpowiedz Nowy wątek
2016-12-24 22:56
0

Cześć.
Od jakiegoś czasu chodzi mi po głowie usprawnienie i ułatwienie pracy mojej matuli prowadzącej sklep zielarsko-medyczny. Biedna ma w kasie fiskalnej tylko bazę z grupami produktów. W efekcie wszystko robi ręcznie, począwszy od wyliczania cen po dostawie, wprowadzania kodu grupy i ceny przy sprzedaży, a na remanencie skończywszy. Nie wspominam już nawet o braku statystyk, które byłyby wielce użyteczne w tego rodzaju działalności.
W związku z tym, planuję zbudować system składający się ze skanera kodów kreskowych, programu magazynowego na komputer i drukarki fiskalnej. I tu rodzi się pytanie: jakie wymogi urzędu skarbowego musi spełniać taki system? Wiem, że kasy fiskalne są certyfikowane, stąd wniosek, że i taki system pewnie musi być w jakiś sposób zweryfikowany. Orientuje się ktoś z Was w tym temacie? Btw. gdyby kogoś to interesowało, program zamierzam napisać w C#.

Pozostało 580 znaków

2017-01-02 21:55
1

O ile zgodzę się, że jeśli nie ma ciśnienia na to, że ma to teraz działać, fajnie napisać samemu, ale pisanie o 2 tabelach, to raczej kiepska podpowiedz... Warto pamiętać, że jak to ma się do czegokolwiek nadawać, to powinno generowac dokumenty, powinno dać się prześledzić, co się działo z danym towarem od przyjścia do sklepu do wyjścia. Więc już na dzień dobry mamy 3 tabele - towar, historię, dokumenty księgowe. A to dopiero początek. Teraz kwestia jaki sposób wartość towaru jest wyliczana, jeśli mamy towar z 2 dostaw powiedzmy A i B, mozemy trzymac historycznie 2 rózne ceny i zdejmować z magazynu najpierw te, które przyszły wcześniej, a później te, które przyszły później, albo stosować metodę uśredniania. Zanim zaplanuje się taki program proponuję usiąść najpierw z księgową, później z mamąi poznać sposób przepływu towarów i dokumentów, żeby nie wyszedł potworek, którego trudniej się obsługuje niż robiłoby się to ręcznie.


Ogólnie na prace domowe mam stawki zaporowe. Czasem coś o programowaniu znajdzie się na mojej stronie

Pozostało 580 znaków

2017-01-04 20:24
1

@Panczo fakt, nie można tak oceniać pochopnie ludzi. Jednak chcę pokazać naszemu koledze, że to nie takie hop siup. Nie mniej jednak jest tak jak piszesz. Przy odpowiedniej dozie zaangażowania można napisać coś sensownego.

@kaczus wiem, że 2 tabele to za mało. Ale przecież same stany magazynowe (wraz z historią przychodów rozchodów) robi się za pomocą 2 tabel oraz 3 słownika towarów. Po co tabela historia? Przecież to i tak de facto tylko kopia pozycji faktur :) Co do ceń średnioważonych to generalnie teraz mało kto z tego korzysta (chyba tylko na skupach złomu gdzie cena będzie codziennie inna). I na początek z tego bym w ogóle zrezygnował. Wszyscy moi klienci mają FIFO, ewentualnie ręczny rozchód z danej dostawy (jak w przypadku np. leków). Nie mniej jednak dobra księgowa jest tu potrzebna.

Pozostało 580 znaków

2017-01-05 17:42
1

Dziwne, bo w systemie, w którym pisałem, takie rozwiązanie było najlepsze, no chyba, że bedziesz pamietał, że kupę rzeczy kupiłeś w tej cenie, kilka w tej, a dodatkowo szybkie zakupy spowodowało, że kupowałeś coś w wyższej... Podwójne odwzorowywanie rzeczy powiązanych z księgowością to podstawa, chyba, że chcesz mieć ciepło, jak coś przypadkowo zostanie uszkodzone i dochodź wtedy co i jak i dlaczego sie zepsuło. Historia nie zawsze jest w 100% powiązana z fakturą, dokumentów jest trochę więcej niż same faktury, choćby z tego powodu, że fakture możesz dostać w innym momencie niż towar, stąd masz dokumenty przyjęcia na magazyn i zdjęcia z magazynu.


Ogólnie na prace domowe mam stawki zaporowe. Czasem coś o programowaniu znajdzie się na mojej stronie

Pozostało 580 znaków

2017-01-07 18:26
1

@kaczus tak, ale ja pisałem o przypadku najprostszym gdzie faktura == WZ/PZ. Oczywiście to nie zawsze jest spełnione.

W moim systemie starczała 1 tabela (pozycji dokumentów) i to z niej wszystko się tak naprawdę wyciągało w bardzo prostu sposób. Widać stany w rozbiciu na cenę, datę przychodu, serię, datę ważności. Jak ktoś nie chce widzieć stanów w rozbiciu na te wartości to też widać.

Co do podwójnego odwzorowania to przecież nie chroni przed przypadkowym usunięciem pozycji faktury/dekretu. Po usunięciu dokumentu i tak bym usuwał przecież dane z powiązanej tabeli. Od przypadkowego usunięcia danych w księgowości istnieje takie pojęcie jak zaksięgowanie dokumentu. Takiego dokumentu nie da się już usunąć/zmienić oraz nie powinno się go dać odksięgowywać. Tak samo mamy zamknięcie miesiąca obrachunkowego. A jak ktoś zaksięgowuje dokumenty raz do roku przed zamknięciem roku to już jego sprawa i niech potem nie przychodzi do mnie z płaczem, że styczeń uzgodniony, ale nie jest zamknięty i w czerwcu coś się rozjechało...

Pozostało 580 znaków

2017-01-07 21:13
1

Chodziło raczej o błedy systemu... Te łatwiej wyłamać, jesli masz kilka postaci operacji i stanów. Ale pomińmy to, nawet w tak prostym przypadku jak opisujesz, już wydałeś się mieć 3 tabele - pozycji dokumentów, samych dokumentów oraz lista towarów... Rozsądnym byłoby trzymać same stany na czymś zbliżonym do kont księgowych, co ułatwi nam choćby chęć rozbicia w razie potrzeby na magazyn i sklep - jeśli firma nam sie ciut rozrośnie, albo na 2 sklepy, dodatkowo łatwiej obliczać wtedy bilanse roczne, jeśli w drzewie kont uwzględnisz rok. Poza fakturami pozostają jeszcze w sklepie inwentaryzacje, wykazywanie strat, uszkodzeń, reklamacji itd. Ja znam to raczej nie ze sklepu ale z firmy produkcyjnej, tam jest więcej rzeczy do wykazania, ale tak jak napisałem, zanim ktoś zdecyduje się na zrobienie postaci bazy, może niech porozmawia najpierw z księgowym i osobą pracującą w sklepie, jakie operacje są niezbędne, jakie dokumenty musi generować system, co będzie chcial sprawdzic audytor itd, inaczej powstanie potworek bardziej utrudniający prace niż ją ułatwiający.


Ogólnie na prace domowe mam stawki zaporowe. Czasem coś o programowaniu znajdzie się na mojej stronie
edytowany 1x, ostatnio: kaczus, 2017-01-07 21:15

Pozostało 580 znaków

2017-01-09 20:08
1

@kaczus faktycznie nie zrozumiałem o co chodzi. Tak, ja też u siebie mam takie nadmiarowe dane. Chociażby jak mamy fakturę, to na główce dokumentu trzymam wartość ewidencyjną, netto, vat oraz brutto. Dodatkowo mam kontrolę dokumentów. Analogicznie na tabeli towarów mam całkowitą ilość. Akurat nie poszedłem w rozbijanie tego na magazyny, ale to taka decyzja projektowa (mniej lub bardziej udana).

Co do 3 tabel to pisałem 2 tabele + tabele słownikowe. Kartoteka towarów/kontrahentów liczę jako słownikową. Czasem bardzo dużą, ale zawsze to słownik :)

Ja akurat też dobrze znam ten temat dość dobrze i zarówno ze sklepów jak i firm produkcyjnych. Nie mniej jednak zgadzam się z Tobą w 100%. Warto mieć dobrego księgowego. Ja byłem w o tyle dobrej sytuacji, że miałem dobrych wdrożeniowców oraz dobry system działający w DOS'ie. Moim zadaniem było przepisanie tego do postaci Windowsowej.

Ja ze swojej strony może jeszcze polecę pytającemu aby zobaczył jak działają programy dostępne komercyjnie. Zawsze można pobrać sobie demo paru aplikacji i zobaczyć jak się je obsługuje, czy jakie rzeczy można w nich robić.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0