Webshop témát néztem, és találtam például ezt a godaddy oldalt. A "nagy" webshop-ra írja, hogy havi üzemeltetési költség 11-22 font. Egy kicsit pislogok. Sajnos nem találtam arról adatot, hogy egy "nagy"-nak nevezett webshop esetében havi hány látogatót feltételeznek?
[ Szerkesztve ]
Kérdés Google "office" programozásról valamilyen pdf vagy nyomtatott könyv létezik? Tudom van sugó és egész jó de ruhellem hogy olyan doksi nincs amit feltudok ütni ha kell 
Már úgy érted excel függvények? Szerintem jellemzően kompatibilis.
Igen. A legnagyobb bajom, hogy ott a sugó de sokszor bele futok abba hogy elöfizetés kell hozzá erröl pld allig van infó melyik fugvény müködik minden esetben melyik full elofizú esetén.
Hmm, libre office-nál vélhetően minden free. Muszáj google-t használnod? Ha terheled a szervert, az bizony lehet, hogy pénzbe fáj.
Documentation-First Development
A dátum szerint kb 1 éves blog. Vajon milyen sebességgel fog sikerülni a mai világban újrafeltalálni a spanyolviaszt?
De pl az önkiszolgáló kasszák esetén sem értem, hogy miért nem jutott senkinek az eszébe az, hogy legkésőbb a nyugta nyomtatása előtt árucikkenként összesítenék a darabszámot. Csak ezzel mennyi papírt meg lehetne takarítani országosan? Hozzáteszem, hogy ezt nem csak az önkiszolgáló kasszákra, hanem a hagyományos pénztárakra is lehetne alkalmazni. Összefutottam olyan pénztárossal is, aki 14 darab táblás csokit egyesével csippantott le(úgy, hogy én 2 x 7 - es sorba készítettem elő neki). Na, aaz ilyeneket is kiszűrhetné a program. Azért nem mind1, hogy 14 sorba nyomtatja ki a gép, vagy max. 2 sorban.
Ennek nagyon egyszerű oka van: pénztárgép és taxaméter rendelet.
Ez kellően szőrszálhasogató módon specifikálja egy pénztárgép minden műszaki, funkcionális aspektusát, nyugta, számla tartalmát, kinézetét.
Alapvetés: ami egyszer bekerül az adóügyi egység memóriájába, az utólag már nem módosítható, maximum stornózni tudod, de az új tétel, ellentétes árral
Alapvetés2: nyomtatót, vevőkijelzőt az adóügyi egység vezérli, nem kötheted direktben a számítógépre, pláne nem vezérelheted a saját fejed szerint.
Nem tudom most milyen adóügyi egységet használnak az áruházak, mivel utoljára 15 éve foglalkoztam ezzel.
Mi anno a BBOX Pocok4 aztán Pocok8 modulját illesztettük az éttermi szoftverünkhöz. (Auchan akkoriban még az eJournal nélküli, 2 példányos mátrixnyomtatós Pocok2-t használta)
Ez nagyon leegyszerűsítve úgy működött, hogy soros porton etetted parancsokkal:
- nyugta nyitás: új nyugta generálása, ekkor kinyomtatta a nyugta fejlécet a kötelező elemekkel (bolt neve, telephely címe, cégnév, cég székhelye, dátum, nyugta szám...)
- új tétel: megadtad a tétel nevét, darabszámát, mennyiségi egységét, egységárát, ÁFA kulcsát (A-E) ekkor letárolta a zárolt memóriába és kinyomtatott egy sort.
- ha rontottad, akkor tétel stornót kellett küldeni negatív árral, ez új tételként jelent meg a memóriában, és ismét kinyomtatott egy sort.
- ha végeztél, akkor nyugta zárás parancs, itt megadtad a fizetésmódot (KP, bankkártya, utalvány... Milyen címlet), ekkor összeszámolta az ÁFA kulcsonkénti részösszegeket, végösszeget, visszajárót és a nyugta lábléccel együtt kinyomtatta, valamint lezárta a memóriában a nyitott nyugta rekordot.
De ez még az online pénztárgép című őrület 2012-es bevezetése előtt volt, de gondolom a mostani műszaki követelmények is hasonló működési módot írnak le, csak a sallangok változtak. (Pl. nem kell éves zárást nyomtatni, és papíron vagy az éves eJournalt pénztárgép szervizzel CDre kiíratva leadni a NAVnak, hanem az online cucc úgyis lejelenti nyugtánként, legkésőbb a napi zárásnál az integrált mobilneret használva
Vagy 2005-ben még csak 5000 napnyi/műszaknyi nyugtát kellett tudnia eltárolnia egy adóügyi egységnek, 2009 körül ezt 10000-re duplázták, mostani online verzió már 20000 napnyi memóriát követel, közben meg 3-5 évente kidobatják a hardvert új jogszabályi követelmények miatt 
Pl. 2006-ban levizsgázott Pocok4-es rendszerünk 2009-ben már nem kapott engedély hosszabbítást, mert "kevés volt a memóriája", cserélhettük mindent Pocok8-ra.
5 év alatt, ha napi 3x van műszak váltás a 24/7-ben működő bolt/benzinkút pénztáránál, az 5x365x3=5475 napzárás.
Átlag sarki boltban évente 300-365 napot zárnak, simán elketyegne 8-10 évig is egy 5000 napos adómemória, mielőtt cserélni kéne benne az epoxival kiöntött EPROMot, de akkor sem a komplett vezérlő egységet...)
Eredeti kérdésedre visszatérve:
Program valószínűleg azt csinálja, hogy vonalkód lehúzásnál automatikusan küldi a vonalkódhoz rendelt terméknevet, mennyiséget (1db), egységárat, ÁFAkulcsot új tételként az AEE-nek, aminek nincs mérlegelési lehetősége, új sorban nyomtatja.
Másik megoldás az lenne, hogy a pénztáros kiválasztja a terméket, megnyomja a mennyiség gombot, tapiképernyőn bepötyögi/mérleggel leméreti a mennyiséget, aztán enterrel zárja, és ekkor kerülne át a termék neve, ára, pontos mennyissége, egységára, ÁFA kulcsa az AEE-be.
(Pékárú vagy a gyümölcs így működik az önkiszolgáló kasszáknál, amikor rádobod a 3 almát a mérlegre, aztán kiválasztod, hogy jonatán.)
De sokkal gyorsabb 7 csokit egyesével áthúzni a vonalkódolvasón, mint a mennyiség gombbal babrálni az érintőképernyőn, meg nem kell a pénztárosnak ide-oda fordulnia közben.
Aldi/Lidl kaliberű cégeknél meg komolyan mérik a pénztárosok gyorsaságát, hány vásárlót szolgálnak ki óránként.
Így náluk fel sem merül, hogy ezzel nyugtánként 3-5-10 centi papírt pazarolnak, lényeg az, hogy hárommal több vásárlót préseljenek át a pénztáron óránként, annyival kevesebb pénztárost kell fizetni.
(Már rég nem néztem, mennyi most egy pénztárgépekbe való 80mmx80m-es hőpapír. 500Ft/guriga? az 500/80 = 6,25Ft/méter.
Nyugtánként 10 centi papír felesleg az 62,5 fillér.)
[ Szerkesztve ]
Mivel ez itt off topic, ezért itt reflektáltam rá.
batch/Powershell útján szeretnék kötegelten fájlokat áthelyezni könyvtárakba, amelyeknél a könyvtárnév egy része(pl. első 12 karaktere) megegyezik a fájl első 12 karakterével.
pl.
Ford Fiesta 2003 valami.pdf
Ford Fiesta 2003 masvalami.pdf
Ford Fiesta 2003 harmadik.pdf
Opel Astra 2008 valami.pdf
Opel Astra 2008 masvalami.pdf
az alábbi mappákba
- Ford Fiesta 2003
- Opel Asta 2008
Az elso pelda pont nem jo, mert a "Ford Fiesta 2003" 16 karakter hosszu, nem 12, de az "Opel Astra 2008" is 14...
[ Szerkesztve ]
Ehhez egy megfelelo regularis kifejezes kell, ami kiszedi a stringbol az elso karaktertol az elso numerikus karaktert megelozo whitespaceig tarto resz-stringet.
[ Szerkesztve ]
nem kell teljes egyezés, elég részleges, mert különböző hosszúak
pl. Ford Fiesta, Opel Astra 2 vagy Citroen Berl
csak példa volt a 12
Marky18: köszönöm, megoldottam
$FilesToMove = 'D:\autok'$TargetPath = 'D:\autok'$Files = Get-ChildItem -Path $FilesToMove -File
foreach ($File in $Files) { $PathToMove = Get-ChildItem -Path $TargetPath -Directory -Filter "$(($File.Basename).Substring(0,12))*" | Select-Object -First 1 Write-Output "Moving File $File to $PathToMove" Move-Item -Path $File.FullName -Destination "$($PathToMove.Fullname)\$($File.Name)"}
[ Szerkesztve ]
sikerült egy olyan problémába belefutni, hogy ha az alap útvonalként szerelő mappa nevében "é" betű van, akkor megborul a script
Az ékezetes betűt "Ă©"-nek értelmezi és hibát dob.
hogyan lehetne ezt javítani benne?
Be kéne állítani, hogy a Win kódlapnak megfelelően kezelje az ékezetes stringeket UTF akármi helyett.
Ha jól értelmezem a leírtakat, akkor 'ansi' a Windows mindenkori területi beállításainak megfelelő kódlap. (magyar -> win1250?)
Biztos nem 1252? Valahol mintha belefutottam volna.
1252 a nyugat európai kódlap, amiben nincs ő/ű.
1251 a cirill betűs (orosz, szerb, stb.)
1250 a kelet európai.
(DOS alatt a 850 volt a nyugat, 852 a kelet európai.)
Ha notepadban ANSI kódolással mentem magyar Win alatt a futtatandó SQL szkriptjeimet, akkor az ó/ű helyesen megy be a Win1250-re állított Oracle DBbe.
Ha default UTF8-on felejtem, akkor pont úgy néznek ki az ékezetek, ahogy a példádban.
[ Szerkesztve ]
javaslod egyéb Windows szintjén átváltani UTF8-ra vagy maradjon 1250?
agy csak a Powershell scriptek mentésekor használjak ANSIt?
Miért akarnád a Windows beállításokat piszkálni?
Egyszerűbb a notepadban mentés máskéntet nyomni, aztán alul Kódolás legördülőben kiválasztani az ANSIt.
Akkor egy bájton menti a magyar ékezetes karaktereket, nem kettőn, mint az UTF8-nál, így minden nem UTF8-at használó rendszerben ugyanúgy fog működni, nem fog szétesni a string.
De nem szeretem, ha figyelmetlen kollégák szkriptjei által elrontott DB kommenteket, meg ügyfélszolgálatnak szánt figyelmeztetéseket kell utólag olvashatóvá tennem a DBben
mert eddig úgy tudtam UTF16-ot használ a Win10 alapból
A probléma azzal az lesz, hogy a kódlapok egy hátrahagyott koncepció, míg az utf a mindenhol feltételezett alap. Ahol és ami még nem utf, azt jobb lenne konvertálni. Különben ezerszer fog visszaköszönni ugyan az a probléma.
A windows-ban van egy kapcsoló utf támogatást adni. Be kellene kapcsolni azt is.
@Zola007:
Edit: A fat32 file rendszer utf16-ot használ, az ntfs nem biztos Viszont a hatásos kimenetet az az utf kapcsoló szabályozza a windows beállításaiban.
[ Szerkesztve ]
Esetleg:$OutputEncoding = [System.Text.Encoding]::UTF8[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
chcp 65001
[ Szerkesztve ]
