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

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#.

Co do programu, to żadnych konkretnych wytycznych nie ma. Musi tylko obliczać prawidłowo podatek vat na pozycji jak i w podsumowaniu paragonu.
Co do drukowania, to drukować paragony z komputera można tylko na drukarce fiskalnej. Kasa fiskalna jest to niezależne od komputera urządzenie fiskalne, które może drukować tylko paragony ręcznie wprowadzone na tej kasie, bez pomocy komputera. Jedynie do czego może służyć komputer to odczyt sprzedaży z kasy fiskalnej lub zaprogramowanie bazy towarowej na kasie. Niektóre kasy pozwalają na zaprogramowanie kodów kresowych do artykułów, jak również podłączenia czytnika kodów kreskowych, co przyspiesza proces sprzedaży/wyszukiwania artykułu.
Jeżeli jednak chciałbyś uruchomić jakiś program do sprzedaży i wydruku paragonów to należy zakupić drukarkę fiskalną - koszt około 1500 pln netto w górę.

Ogólnie napisanie takiej aplikacji to nie jest jakiś wielki problem. Jednak dla niedoświadczonego programisty może narobić kłopotów. No i nie wiem czy sam byłbyś w stanie napisać coś lepszego niż jakiś półkowy program który kupisz za około 1000zł. Kolejną sprawą jest to, że nabijanie paragonu na kasie będzie o wiele szybsze niż klikanie go w komputerze (przynajmniej na początku). Natomiast program + drukarka ma po prostu większe możliwości. Chyba żeby pójść w kierunku postawienia w sklepie terminalu POS. Wtedy będzie to bardzo fajnie się obsługiwało, praktycznie tak samo jak kasę fiskalną. Do tego drugi komputer do obsługi inwentaryzacji oraz zestawień i mamy połączenie kasy z możliwościami systemu.

Po co wymyślać koło od nowa :)
Takich programów jest setka w sieci. Zaufaj firmie z długoletnim stażem, sprawdź ofertę firmy Syriusz z Rzeszowa [CIACH!]
Tani program, który na początek w zupełności wystarczy.
[CIACH!]

To na górze to pewnie reklama, ale mimo wszystko zgadzam się, że nie warto się bawić w robienie tego samego od zera, jeśli się nie robiło niczego podobnego.

Swoją drogą istnieją programy open source o tego rodzaju funkcjonalnościach (ERP - enterprise resource planning), np. Odoo: https://www.odoo.com/
Może bardziej opłacałoby się wziąć taki program i go dostosować pod siebie? Z tego co tu piszą to też ma coś ze skanowaniem kodów kreskowych: https://www.odoo.com/documentation/user/9.0/inventory/barcode/setup/hardware.html

Nie słuchaj doradców, którzy proponują kupienie gotowego rozwiązania. Zgadzam się z nimi, że to będzie prostsze, ale nigdy nie będziesz miał klienta bardziej wyrozumiałego niż mama, więc wykorzystaj to i naucz się sam jak rozwiązywać realne problemu, zyskasz zdecydowanie więcej niż pisząc jakiś pet soft.

Wracając do meritum, kasy/drukarki nie są certyfikowane, a fiskalizowane. Zawsze możesz podzwonić po producentach kas i popytać o API/biblioteki do komunikacji z drukarkami. Dużo się dowiesz i zobaczysz, ze oprogramowanie drukarki to nie jest racket since i da się to zrobić i to najmniejszy problem przy pisaniu/projektowaniu programu.

Czytniki kodów kreskowych, to w uproszczeniu klawiatura, która ułatwia życie skanującemu (zamiest przepisywać numerki, skanuje) pytanie czy potrzebujesz chodzić po sklepie i skanować, czy działać ze skanerem przy kasie. w pierwszym wypadku pewnie będziesz potrzebował jakiś kolektorów danych, w drugim wystarczy zwykły czytnik kodów kreskowych.

Reasumując, nie musisz niczego certyfikować, to mama składając papiery do US/ZUS potwierdza ich poprawnośc, nie program którego używa...

Jasne, jeśli chcesz się uczyć to spoko, pisz i za jakiś czas zaimportujesz dane do swojej aplikacji. Ale jeśli mama chce mieć gotowe rozwiązanie teraz, w dodatku sprawdzone to po co czekać.

Panczo napisał(a):

Nie słuchaj doradców, którzy proponują kupienie gotowego rozwiązania. Zgadzam się z nimi, że to będzie prostsze, ale nigdy nie będziesz miał klienta bardziej wyrozumiałego niż mama, więc wykorzystaj to i naucz się sam jak rozwiązywać realne problemu, zyskasz zdecydowanie więcej niż pisząc jakiś pet soft.

Tak, ale żeby nie mając żadnej wiedzy merytorycznej napisać dobrze soft będzie ciężko. Autor właśnie znajduje się w takiej sytuacji (wskazują na to pytania). Mama autora będzie wyrozumiała, ale czy na pewno będzie w stanie wyjaśnić pytającemu wszystkie zawiłości tematyki? Jeśli nikt nim nie pokieruje to niestety, ale sam będzie zmieniać parę razy koncepcję i bardziej się zniechęci niż napisze coś co będzie miało sensowną wartość.

Faktem jest, że podstawowy taki system to w zasadzie obsługa 2 tabel w bazie danych (dokumenty oraz pozycje) + tabele słownikowe. Nie mniej jednak od takiej postaci do narzędzia które będzie obsługiwać sklep daleka droga. Nie mniej jednak nie odradzam pisania takiego czegoś. Może tylko niech paru miesiącach pisania nie daje tego na produkcję.

@Mr.YaHooo: Przecież jak to mu się uda to mamy typowy układ win-win. Nie popadajmy w paranoje, jestem przekonany, że autor kilka razy wpadnie na minę, zmieni koncepcje, czy zacznie od zera. Wiem, też, ze to jest dobra motywacja: zadowolona mama używająca oprogramowania do prowadzenia sklepu. Skoro do tej pory wszystko robi "ręcznie" to znaczy, że nie czuła potrzeby gotowego rozwiązania, albo nie wydawało jej się celowe wydawanie pieniędzy na coś co ogarnia sama...

Pytanie autora było konkretne:

I tu rodzi się pytanie: jakie wymogi urzędu skarbowego musi spełniać taki system?

I na wszystkie posty w wątku tylko jeden był odpowiedzią... Dlatego doradzam nie słuchanie porad. W końcu, każdy kiedyś startował, więc nie "zabraniajmy" młodym adeptom zdobywać szlify programistyczne, najwyżej się nie uda. Ja wiem, że biznes dawno rozwiązał problemy autora, ale to nie jest powód, żeby z nich korzystać,

@Panczo to nie jest takie proste jakby się wydawało. W takich przypadkach jak program do wystawiania faktur/drukowana paragonów muszą być spełnione pewne specjalne warunki o których ani autor ani jego matka nie mają nawet pojęcia. Np. program musi zadbać o to aby wydrukowany paragon/faktura nie była już nigdy zmieniana. Dla początkującego nie jest to takie oczywiste. Tak samo po wystawieniu faktury, a zmianie danych kontrahenta w kartotece faktura musi dalej zawierać archiwalne dane. Takich kruczków jest więcej i zastanawiam się o ilu z nich ma pojęcie autor albo jego matka...

@Mr.YaHooo: To wszystko jest w zasięgu osoby chętnej do pracy i nauki. Nie wiem jakie ma doświadczenie OP, ani jakie ma jego mama, ale daleki jestem od oceniania jej wiedzy o prowadzeniu biznesu...
I powtarzam, obecnie ma kasę fiskalną i to na niej spoczywa obowiązek tworzenia kopii paragonów. Jak to się uda to boje będą wygrani. Nie jest to proste, ale też nie mówimy o wysłaniu ludzi na marsa, więc spokojnie przy odpowiedniej dozie zaangażowania można to ogarnąć...

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.

@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.

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.

@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...

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.

@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ć.