Simple Shop

Pregled CSV izvoza v pregledu računov in dodati manjklajoče stolpce (ZOI, EOR itd..).

V Pregledu zaloge pod Skladišče je želja uporabnikov da se doda sledeče filtre:

- Vsi
- Prikaži samo "pozivitvno" zalogo
- Prikaži samo "pozitivno" zalogo + 0
- Prikaži samo "negativno" zalogo
- Prikaži samo "negativno" zalogo + 0
- Ne prikaži zaloge (če je "Paket")
- Ne prikaži zaloge (brez prevzemnice)
- Ne prikaži zaloge (brez prevzemnice in inventure)

Glede na to, da je kar nekaj tega, bi bilo najbolje, da je to "dropdown" menu, izbor je med sabo izključojoč, torej ne moreta biti izbrana 2 filtra naenkrat.

V formah ZnD (blagajna, gostinec, itd...) da se doda nov tip plačila, ki bo identičen kot je tip plačila TRR z eno razliko, da je račun označen kot "PLAČANO".

Torej, tukaj bi se naredilo tako, da bosta prisotna 2 TRR gumba, razlika je, da bo pri enem oznaka "ŽE PLAČANO", obstoječi ostane nespremenjen.

Testni program deluje samo na COM port 1.

Tehtnica:
Trgovinske tehtnice G30

Povezava:
http://www.libela-elsi.si/trgovinske_05.htm

Opis:
Protokol TISA - Libela G30 - RS232

Torej, zadeva se naj podpre na suho, potem se bo stestiralo z beta verzijo pri stranki z vključenimi "debug" logi.

Vse stranke, ki se jih doda preko spletnega iskalnika so v program dodane oz. shranjene kot davčni zavezanec = 1, ne glede na to ali je ali ni davčni zavezanec.

Torej, če stranka ni davčni zavezanec, se preko registra pravilno shrani davčna številka:

Primer:
Iščemo davčno številko: 24688843
Ker je ni v med strankami kliknemo na iskalnik, stranko najdemo.
V samem registru ima stranka pravilno zapisane parametre (true, false).
Potrdimo in shranimo.

Nato vidimo, da ima stranka za davčno številko zapisano brez SI, kar je prav, vendar je podatek Zavezanec za DDV = 1.

Stranka ima pri uporabi vage in avtomatske teže vage problem pri uporabi artiklov, kateri imajo prav tako zapisano "BAR koda" ter "Koda". Enostavno jih ne zazna, artikle na vago in obenem težo pa lepo dela. Se pravi vsi drugi ki ne uporabljajo teže po BAR kodi (se pravi da ni izbran tip kot "kilogram") imajo probleme. Prav tako stranka trdi, da ima probleme z artikli z iskanjem po "Koda".

Ko narediš prevzem artiklov pusti spreminjat zalogo med "Produkti".

Prav tako po nekih čudnih okoliščinah manjka prevzemnica z ID = 1, prevzemnica ki se je naredila pa ima ID = 2 in oznako prevzemnice "2016/2".

V kolikor je omogočena funkcija Omogoči POS terminal (v priponki) naj se pri izpisu izpišejo tudi podrobnosti po karticah.

Zaključek
Informativni izračun (A4 izpis)

V kolikor blagajniški dnevnik nima podatkov o računih pride do napake pri tiskanju računov.

Vklopljena je bila nova možnost, da se tiska vsaka blagajna posamično. Testiralo se ni, če ni vklopljena vsaka posamična blagajna, možno da je napaka pri tiskanju v obeh primerih.

Naredi se naj identičen izpis, le podatki naj bodo z podatki = 0 ali dodatnim besedilom "Dokument nima podatkov".

Pri uvozu produktov je napaka od izvedbe NPoco (UWP), da se ko se izvede uvoz produktov, da so uvoženi produkti dejansko podvojeni.

Pregled zaloge za trenutni oz. na današnji datum deluje.

V kolikor pa se izbere poljuben datum, pa se ob kliku na "Prikaži" pojavi napaka, kot je razvidno v priponki.

Ko se kreira nova prevzemnica program nepravilno zabeleži izvorni dokument prevzemnice.

Ne glede na izbrani izvorni dokument (račun ali dobavnica) je vedno shranjen tip izvornega dokumenta kot "Dobavnica".

Stranke-dodati polje Naziv 2, ki bo omogočal vpis PE (poslovne enote).

V kolikor računalnika ne izklapljamo, ga dajemo v spanje in program SShop pustimo odprt, nam po ponovnem prebujanju in ustvarjenem računi le tega ne potrdi. Fizično moramo prebuditi povezavo s FURS tako da dvokliknemo na zapis FURS, skrajno desno spodaj v programskem oknu, kjer kaže povezavo s FURS, da nam obarva povezavo v zeleno, torej se poveže.

Moteče, potrebno pozornosti ob vsakem prebujanju. Stranki izdamo natisnjen davčno nepotrjen račun, ki nam ga sicer kasneje potrdi, a to je napačno in neprofesionalno.

Pri kreiranju ponudbe zraven naziva vnesemo opis postavke. Opis produkta tako ali tako ne moremo vnesti, ker pišemo v prazno. Ko kasneje kreiramo račun iz te ponudbe nam tega opisa postavke sploh ne sprinta. Če ga hočemo imeti na računu, spet jovo na novo vnašamo opis postavke. Dvojno delo in še na vse je treba paziti. Kot da bi pisali račun ročno, kot v starih časih.

Glede teh opisov postavke in opisov produktov pa je tako ali tako zmešnjava že od nekdaj in je ne znamo pošlihtati. Samo poglejmo malo za nazaj. Na hitro preverjeno smo o težavah pri opombah in opisih začeli govoriti pri ID#323 in to davnega 28.2.2017. Ni kaj smo ažurni, kot sem to že večkrat omenil. In ta neizpis opisa postavke izhaja ravno iz teh težav, ker se ne shranijo v našo bazo produktov.

Ker se velikokrat zgodi, da se določeni stranki dobavlja enake izdelke, bi bilo smiselno dodati, ravno tako kakor je že pri računih, ustvari dobavnico (kopiraj) iz že izdane dobavnice.

Stranka kupi artikel, kreiramo dobavnico, jo izpišemo in stranka si v tem primeru premisli:

- namesto enega komada bi imela naprimer 3 / pišemo novo dobavnico še za 2 kosa / delna rešitev, ker zdaj lahko izpišemo račun iz večih dobavnic, bi pa bilo verjetno enostavneje, da dobavnico ponovno odpremi in jo popravimo, dokler še ni izpisan račun?

- drug primer je težji, ko si stranka premisli in ne vzame tega artikla / kaj sedaj. Ne gre dobavnice stornirat, ne popraviti?

- vsak je zmotljiv, izberemo po pomoti napačen naslov, artikel, količino ali kaj podobnega, pa zopet dobavnica ni popravljiva, ne moremo je stornirati, skratka za inšpektorje je to takoj sumljiva zadeva, da hočemo nekaj prekriti, zaloga se podira, ni tako kot bi moralo biti.

Prav tako smo že omenjali tudi druge dokumente, ki jih prav tako me moremo popravljati niti takrat, ko jih še ne zaključimo.

To so napake, ki nas uporabnike ovirajo pri delu in tudi delno silijo v nepravilnosti ne po naši krivdi, saj ne moremo svoje znane napake zaradi programske napake izvesti na pravilen način. Tale BT SimpleShop je dobra zamisel, da lahko povemo svoje težave, le nekatere se predolgo zadržujejo na seznamu. Razumem, da vsako delo zahteva svoje znanje in čas, ampak saj veste, kot uporabniki bi tudi radi prihranili kaj časa in si olajšali delo, zato sporočamo te napake in pobude, da skupaj z vami naredimo dober program za vse.

ps.

o podobni zadevi glede stornacije je na BT bilo pisano že 13.1.2016, torej čakamo na popravek že skoraj leto dni. Se opravičujem, ampak prosim če nas lahko razumete, čeprav zadeva ne sodi v to rubriko.

Ni možnosti izbrisa dobavnice (ravno kreirane).

Pri "Pregled predračunov", "Pregled ponudb", "Pregled dobavnic" itd, bi lahko neposredno dodali predogled dokumenta, za hitrejšo uporabo.

Zasledil sem da nekateri programi upoštevajo rok plačila samo na delovni dan, torej če imamo za določeno stranko nastavljen 20 dnevni rok plačila in nam to pade na soboto, nedeljo ali praznik se datum prestavi na naslednji delovni dan oziroma nas morda na to vsaj opozori.

Če je to smiselno morda tudi za ostale uporabnike bi bilo priporočljivo.

Stranka ima željo, da se uredi, da se pošilja namesto trenutno .PDF lahko tudi .XML po shemi kot jo ima "Minimax".

Vse informacije na voljo:
Priprava datoteke XML za uvoz temeljnic izdanih računov in dnevnega iztržka
http://help.minimax.si/sl/priprava-datoteke-xml-za-uvoz-temeljnic-izdanih-racunov-dnevnega-iztrzka

Jaz bi pripravil še, da bi bila opcija pošiljanja ali .PDF, ali .XML ali oboje.