Fórum pro uživatele kancelářského balíku OpenOffice | LibreOffice
 

#1 12. 2. 2018 13:00:38

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

ŠABLONA pro pokladní systémy - eShop

Podávám žádost o spolupráci na šabloně která je zde : Pokladní systémy - eshop.


      Je to první verze a tak není ani vše řádně doděláno - spíš naznačeno a dá se s tím už "něco" dělat. Původním iniciátorem je Pepa123 Porovnání dvou ceníků.


      Měl bych zájem o konstruktivní náměty nebo i kritiku. Na několika místech popisuji jak nadepsat první řádek odpovědi. Jde zejména o orientaci případných zájemců.


Předem děkuji za konstruktivní a pozitivní přístup:

Editoval neutr (15. 2. 2018 16:00:55)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#2 12. 2. 2018 19:21:24

Pepa123
Člen
Registrace: 1. 2. 2018
Příspěvků: 9

Re: ŠABLONA pro pokladní systémy - eShop

Pokladní systém pro - pro eshop - porovnání dvou ceníků

Nevím ještě přesně jak to má fungovat. Tak jsem to vyzkoušel intuitivně.

Ceník se importuje do CSV nové položky - mohly by se hned nahrát do Ceník pokladna a současně porovnat s Aktuální eshop
Jazyková sada pro správné zobrazení ěščř... je Východní evropa (Windows-1250/Latin2)
Řazení v Ceník pokladna, Aktuální eshop, CSV nové položky, Ceny CSV je správně,
Porovnání ceníků a další asi ještě nefunguje, tam se mi z importovaného souboru se 7 novými položkami zobrazí, jen 1 Nová položka a 4 Nové ceny bez názvu
V tuto chvíli použití souboru DBF of Trifidu je asi zbytečný, data které jdou při exportu do CSV nemají v žádném DBF pohromadě.

Editoval Pepa123 (15. 2. 2018 11:57:14)

Offline

#3 13. 2. 2018 00:20:55

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Re: ŠABLONA pro pokladní systémy - eShop

Pepa123 napsal(a)

A - Ceník se importuje do CSV nové položky - mohly by se hned nahrát do Ceník pokladna a současně porovnat s Aktuální eshop


B - Jazyková sada pro správné zobrazení ěščř... je Východní evropa (Windows-1250/Latin2), teď se zobrazuje 
- Poslední vzorový ceník jsem poslal špatný, od sloupce I je všechno posunutý. Řazení v Ceník pokladna, Aktuální eshop, CSV nové položky, Ceny CSV je správně,


C - Porovnání ceníků a další asi ještě nefunguje, tam se mi z importovaného souboru se 7 novými položkami zobrazí, jen 1 Nová položka a 4 Nové ceny bez názvu


D - V tuto chvíli použití souboru DBF of Trifidu je asi zbytečný, data které jdou při exportu do CSV nemají v žádném DBF pohromadě.

______________________________________________________________________

ad A : To by nebyl problém. Je celkem logické že stačí list pro Export (Aktuální eshop), (Ceník pokladna) pro import. Jenom by se asi na listu IMPORTU musí posunout začátek o 3 nebo více sloupců kvůli zápisům včetně přepočtu. Jinak je docela důležité aby bylo pořadí sloupců v obou listech stejné pro porovnávání. Při tom například exportní sloupec A bude odpovídat v posunutí sloupci F importu.
     Pro vlastní textový export - ten je rozdílný počtem a možná i pořadím sloupců. Stačí ale zadat relaci z listu "aktuální = Export" například takto jednoduše :
A = 1. pozice,
B = 2. pozice,
C = 3. pozice,
D = nic,
E = 4. pozice,
F = nic,
G = 6. pozice,
H = 5. pozice,
.........
     Já pak bez velkého laborování a studování přiřadím do CSV který jde na Prestu sloupce podle relací. Takže například snadno dešifruji, že A až C se překopírují tak jak jsou v Calcu, D sloupec vynechám, pokračuji sloupcem E. Na 5. pozici bude sloupec H a na 6 pozici G = přehozené pořadí.....


ad B : To je jedna z věcí kterou jsem celkem tušil od samého počátku. Já se stejně musím zabývat mnoha znakovými sadami. Tohle by nemělo být jen pro Česko.
- To posunutí mi dělalo potíže protože jsem tam měl jen prázdné sloupce. Tak jsem to udělal jako kopii. Byl jsem si vědom toho, že na to musíte přijít sám. Když bych to popisoval tak bychom se složitě domlouvali.


ad C : Tohle neumím posoudit. Musel bych to vidět. Dost to souvisí s tím jaké je uspořádání. Zde se porovnávají všechny číselné položky. Tedy i takové které reprezentují cenu bez DPH, položku samostatného DPH i cenu dohromady, počet jednotek v balení a obsah balení ... je jich celkem 7.
     Problém je ve změnách které Vám mohou snadno uniknout. Takové porovnání potřebují neplátci stejně jako plátci DPH. Výrobci zase často změní gramáž nebo počet kusů v balení. Tohle nemusíte kontrolovat - stačí dobře načíst čárový kód (QR kód). Když to bude bez kódu - zadávané ručně snadno se to přehlédne - to by byl malér.
     Jinak se to vyhodnotí jako rozdílnost. Představte si že změní objem na jiný - buď proděláte tím že prodáte laciněji nežli byla nákupka, nebo tím, že si to zákazníci nekoupí a půjde to na charitu nebo na skládku.
     Já jsem vycházel z pouhých několika položek a simuloval jsem tam obě varianty. Jak nové zboží (podle 2. sloupce) tak "novou cenu" kde bylo vše ostatní. Ale zapisovaly se změny na konkrétním místě - vždy sloupec 2 (tuším EAN) + pozice kde byla rozdílnost nalezena - mohlo jich být i více ve stejném řádku.
     Pokud by to bylo v tom návrhu podle bodu A, tak bych místa rozdílnosti které jsou méně podstatné vybarvil například do žluta a sloupec bych nechal viditelný. Sloupce bez chyb by se skryly kvůli přehlednosti. Také by bylo možné šířku sloupce minimalizovat (například na velikost 0,5 cm) aby byly vidět všechny ale barva by byla ihned.


ad D : Pokud jste si přečetl to co jsem zkopíroval z emailu od praconíka TRIFIDu, tak byste neměl přehlé=dnout, že záleží jen na Vás co si od nich vyžádáte za typ výstupu. Takže mohou poslat přímo CSV bez Excelu. Mně ta databáze byla podezřelá. Databáze totiž neumožňují vetšinou zakódovat češtinu s diakritikou (kvůli velikosti používají jen znaky bez diakritiky). To když se pošle do eshopu tak je to psané jak SMS a nebudí to důvěru.
     Tedy databáze jako taková umí určit znakovou sadu, ale nesmí to přežvýkat CSV. Problém je v Tom že Presta je po celém světě a má zabudovány snad všechny znakové sady (nevím - ještě jsem se tak daleko nedostal).
______________________________________________________________________

     Jinak jsem zatím neřešil jak připsat novou položku a zda třídit připravený list pro zpracování výstupu - a pokud ano tak podle čeho. S tím souvisí také mazání neexistujícího sortimentu. Nemůžete nabízet něco co už není k dispozici. Takže obsluha listů (export a import) není vůbec dořešena. Ale o to jde - nyní sice dělám podle Vašeho zadání, ale musím myslet v globálnějším rozsahu. Každý uživatel by si měl moci nakonfigurovat vstupy i výstupy podle své potřeby.
     To není až takový problém když by to byla jen samá Presta. Zatím dělám to co myslím že může být vhodné. Například QR kód (bar kód) do štítků. Vy byste ho měl mít díky pokladnímu systému. Ti kdož nemají standardní pokladní systém tak si mohou také poradit - přes Google. Vy byste měl mít nainstalovnou sadu písma pro čárový kód, nebo QR kód - čtečky ji potřebují proto užívání máte zaručeno a zaplaceno.
     Je toho poměrně dost. Chystal jsem automatickou úpravu hyperlinků. (Pozn : někdo vznesl téměř současně s Vámi právě takový požadavek. Ale vidím, že je to také Váš problém respektive potřeba. Další věcí je načítání obrázků - které jsou potřebné i se správným popisem. Je pravdou že tohle se dělá většinou z databáze a tohle musím řešit variantně. Je to běh na dlouho. Dělám ale to co potřebujete Vy aby se to dalo ihned ověřit. Nejspíš to bude horší až přijdou další zájemci. Já dělám podobných věcí víc takže musím dělit i svůj čas na více akcí.


     Takže nyní bych potřeboval abyste si promyslel dobře co byste potřeboval. Nyní dělám ty hyperlinky. Budou ale jen pro tenhle modul. Dá se to snadno zneužít. Vykrást cizí galerii, optimalizovat si návštěvnost (SEO) dík falešným klikačkám ap. Takže tohle bude vždy vázané jen na operace v určitém listě a sloupci + další opatření - ale je toho opravdu hodně.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#4 13. 2. 2018 17:36:11

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Re: ŠABLONA pro pokladní systémy - eShop

Tak jsem si načetl materiál z příspěvku #2 a docela jsem se divil. Sice je tam čeština, ale tečky kombinované s čárkami. Konkrétně poslední sloupec má čárky, ale ostatní mají tečky. Tohle se stává při té primární úpravě v Excelu, nebo přesněji po přeformátování nestandardním způsobem.


     Nechci zkoumat odkud to berete, nebo z jakého programu. Stačí když mi dáte konečnou verzi - tedy stejný import s exportem ve smyslu hlaviček, kolik mám představit řádků a udělám to na 2 listy jak požadujete.


     Problém je také v tom že nyní tam není půsodní EAN podle kterého jsem testoval novou položku. Nyní tam jsou dvě čísla vedle sebe a nevím podle kterého třídit.
A - cislo   
B - cislo_vyr   
C - nazev   
D - sazba_dph   
E - cena_p4_dph   
F - cena_p4   
G - k_cena_jedn   
H - kusu   
I - int_obchod_obrazek_soub   
J - int_obchod_kategorie   
K - poznamka   
L - jednotka
     Podle interpunkce je to z nějaké databáze. Nejspíš z Accessu protože u toho musí být Excel, jinde ne - alespoň vím jen o Accessu který tak byl vytvořen aby to bez Excelu nešlo. Avšak může to být i něco exotičtějšího. Ale ani to moc nevadí. Podobné problémy budou mít různé firmy zejména velkoobchody kde pobočky dostanou "shora" materiál a starejte se. Já MSO vůbec nemusím, ale tohle (jako přechod od MSO k LO) je činnost správná zejména z komerčních důvodů.


     Ovšem už bych chtěl podklady které opravdu mohu zpracovat "naostro". Existuje řešení i pro ty nečeské výrazy bez interpunkce. Neuvádějte že jde o správnou češtinu viz :
cena_p4    k_cena_jedn    kusu    int_obchod_obrazek_soub    int_obchod_kategorie
7.355    2.000    293    klasik_500ml.jpg    11,64
11.488    2.000    27    radegast_birel.jpg    11,64
8.843    2.000    749    kozel_svetly.jpg    11,64
14.05    2.000    8    kozel_cerny.jpg    11,64
15.95    2.000    16    kozel_premium.jpg    11,64
13.14    2.000    430    kozel_11.jpg    11,64
8.843    2.000    310    gambr_orig_10.jpg    11,64
     Kozel cerny, ani svetly česky není. Tečky také zřetelně ukazují že o češtinu opravdu nejde. Zdroj možná češtinu psal, ale ty převody nejméně 2x) nebyly abych tak řekl "košer".
Jde to řešit - například ty tečky nejsou žádný problém.


     Nečeská čeština je jiný oříšek. Pokud to nejde korektním filtrem musí se to rozsekat na jednotlivá slova (spřažená pomocí podtržítka), spustit opravu pravopisu (nejlépe ve formě automatických dokončování). a pak opravenou češtinu opět spojit podtržítkem.
     Takže bych rád obdržel finální podobu i se všemi možnými problémy. Nezapomeňte upřesnit jaké číslo (sloupec) bude vyhodnocovat "novou položku" a které jen "novou cenu". Já tam sice zabuduji volby ale rád bych se už dopracoval k tomu co opravdu potřebujete, nebo chcete. Hyperlinky už vidím nepotřebujete.


     Problém je v tom, že Vám udělám systém na míru. Ostatní dostanou jen demo, nebo se přihlásí jako Vy. Příští verze už bude limitovaná. Vám zůstane ta kterou upřesníte bez omezení, ale už se k tomu nebudu vracet. Takže popřemýšlejte o tom co budete chtít. Zatím každý materiál byl dost jiný nežli předchozí - takto to dělat určitě nemůžu.

     Omlouvám se, ale potřebuji konkrétní promyšlené zadání. Nejsnadnější řešení filtrem asi nebude, takže udělám opravu kterou budete muset nejdřív vytvořit - všechna slova,která se mohou vyskytnout dostaňte do automatických oprav a do automatických funkcí (dokončování).
     Můžete udělat i vlastní slovník při opravě pravopisu ale tam dejte jen výrazy které se nevejdou do automatických (tuším 1000 výrazů jde zařadit - víc ne). Já udělám rozřezání před opravami a pak spojení po opravách - ale vlastní kontrolu budete muset vždy prověřit ještě manuálně.

Editoval neutr (13. 2. 2018 17:44:54)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#5 14. 2. 2018 07:00:15

Pepa123
Člen
Registrace: 1. 2. 2018
Příspěvků: 9

Re: ŠABLONA pro pokladní systémy - eShop

Z aktualního  eshopu jsou pro import do CSV potřeba sloupce
A - pozice 1
B - pozice 2
C - pozice 3
D - pozice 4
E - pozice 5
F - nic
H - pozice 6
I - nic
J - pozice 7
K - pozice 8
L - nic
M - nic
N - pozice 9
O - potice 10
p - pozice 11


EAN - cislo_vyrobku je ve sloupci B, někdy to číslo nemusí být 13ti místné. Ale v ceníku se
neopakují.

Názvy obrázku nemají diakritiku, protože program Trifid neumí takový soubor načíst. Tečka v popisu např. kozel_cerny_1.5l  zase proto, že s desetinou čárkou Presta obrázek nenačte. Při importu si Presta názvy obrázku přepisuje a ukládá podle sebe.

V sloupci J - int_obch_kategorie, čárka mezi čísli být musí. Presta ho bere jako oddělovač.

V sloupcích E - cena P4_dph musí být místo čárky tečka, stejně tak sloupec  O cena_za_jednotku

Nová položka se bude porovnávat podle sloupce B - cislo_vyr a cena podle sloupce E - cena_p4_dph

Do Listu CSV ceny, se zapíše z Listu Aktuální eshop sloupec

B - cislo_vyr
E - cena_p4_dph
H - kusu
O - cena za jednotku

Offline

#6 14. 2. 2018 08:50:12

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 3,435

Re: ŠABLONA pro pokladní systémy - eShop

Ano výborně. Dostanu se k tomu asi až večer. Vytvořím podle tohoto popisu skutečnou kostru. Firma TRIFID mi poslala vzory svých výstupů které použiju pro obecný model.


P O Z N Á M K A :
     Pan Trnka včera odvedl kus dobré práce (zde je příspěvek) Import XML do Calcu když vytvořil filtr pro EET firmy DOTYKAČKA.
V jiném příspěvku konkrétně EET v Calcu - příspěvek #2 je uveden odkaz na firmu Dotykačka.
     To může pomoci novým, nebo stávajícím eshopům ačkoliv jde o obecnou nutnost každého obchodu mimo několika (nevím kolik ani jaké) vyjímek. Nutno si ale uvědomit, že eshopy mají takovou povinnost hlásit jako transakci a pokladní systémy toto mají zabudované. Takže jde o určitou paralelení kontrolu někdy i tří systémů (+ banka). Přes to nevím jestli toto umí Presta jako individuálně zabudovaný eshop. Mám dojem, že jsem někde zahlédl na stránkách MFCR Prestu upravenou pro tyto účely.
     Celkem nepochybuji, že webhostingy nabízející již zabudované aplikace Presty používají tuto verzi, nebo svou vlastní úpravu. Takže pozor na takovou maličkost. Můžete se snadno dostat do problémů. Proto dále uvádím :


     Pan Trnka vytvořil zřejmě funkční filtr pro adaptaci SW "REST API" pro e-tržby který je sice volně použitelný, ale vše jde přes cloud (zřejmě autorův) na MFCR. Autor na stránkách uvádí implementační kód a také za jakých podmínek ho můžete používat bezplatně, nebo jak si opatřit oficiální verzi.
     Takže jistě se najde i dost zájemců kteří si budou chtít ke svému kamennému obchodu, nebo stánku "přimontovat eshop". Také může jít o start podnikání z "nuly". Nebo přechod na registrovaný režim a podobně.
     Může se stát že na začátku takového počinu bude právě Presta namontovaná na web "vlastními prostředky" a bez pokladního systému. Potom by zřejmě takový uživatel vystačil pro začátek jen s jednoduchou licencí účtenkovky (tuším necelých 100 Kč / měsíc pokud by vystavil víc jak 2 učtenky za den), vlastní tiskárnou kde by klasicky tiskl do formátu štítku, nebo vizitek a nebo jen na předem "rozstříhané" formáty A5, A6.
     Potom by bylo zdánlivě nutno vyřešit jediný problém - čárový kód, respektive 2D kód známý jako QR. Ale i to je řešitelné. Přes to u eshopů takovou potřebu nepředpokládám. Ale ani takovou variantu nevylučuji.
     Jenomže účtenkovka to dělá zřejmě ještě pomocí reverzní odezvy v podobě PDF (nevím zatím jsem neřešil) takže stačí mít internet a jakoukoliv tiskárnu. Proto není implementace účtenkovky v podobě filtru pravděpodobně nutná, ale podívám se na detaily a poptám autora - dnes to asi nebude -:)


     Poznámka se týká příspěvků pana Trnky. Já tuto možnost sleduji už od samého počátku a tak vím jak na vlastní "účtenky" - vizuální forma i kód podléhají schválení od MFCR. MFCR zase nepřímo nabízí již hotové a schválené systémy. Ty je samozřejmě nutno zakoupit - nejsou zdarma, ale mohou být mnohem lacinější i když například dotykovka tak drahá zase není a to nevím co a za jakých podmínek nabízí ostatní firmy. To je ale většinou s HW četečkami, nebo registarčními pokladnami.
     Zase nevylučuji například možnost nahodilých obchodních transakcí které se do free verzí nevejdou - různé umělecké a zakázkové výroby. Potom by šlo vytvořit verzi která se obejde bez jakýchkoliv investic. Připadá mi že se takovou cestou chce pan Trnka vydat, ale uvidíme.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

Zápatí