Excel teljesítménybér számítása Excel VBA

Egy problémába futottam bele.
Van egy Excel adatbázisom, amiből adatokat kell kiszúrnom vba segítségével
Egyes feltételek meg is vannak, de van, egy feltétel mait nem tudom, hogy miként oldjam meg

A feltétel az lenne

Ha egy dolgozó egy nap egy műszakban több csoportban volt ott nem elég az adatok le szűrése, ha nem képletet kell alkalmaznom.

csatoltam egy "dupla adatok.xlsm" fájt ami tán látszik a elképzelésem

a lh_teszt.xlsm az amit idáig elértem

https://drive.google.com/drive/folders/1p_VpCtdBi3fdv1mTP3LifDjuyFj9TISj

Köszönöm a segítséget.

Hozzászólások

Ez vajon segít?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Excel" és "adatbázis" két szó kapcsolatától mindig a hideg ráz.

Az úgy tán túlzás, de ha a .dbf fájlok összességét hívhattuk adatbázisnak (sőt, amikor még dbf se volt, sima szóközfeltöltött ASCII fájlok nyerték el ezt a megtisztelő címet, ha volt eszköz a tartalmuk célirányos manipulálására), akkor az .xls is megérdemli. Arról az .xls nem tehet, hogy a COCOM-lista miatt a magyar terminológia késve alakult ki és egy olyan állapotot tükröz már, amelyben adatbázis az, amit adatbáziskezelőnek nevezett adatbáziskezelővel piszkálunk.

Az adatbázis valami előre definiált rendező elvet feltételez, az excel nem ilyen bármennyire is próbálják ráhúzni. Egy táblázat kezelő adata csak karakter láncok egy kétdimenziós tömbje. Egy rendes adatbázisba nem lehet csak úgy random adatot beokádni, egy excelbe simán beírhatsz bármit egy bérszámfejtő doksi bér cellájába.

Excelben rajzolni is lehet, mégsem arra van kitalálva (egyik kolléga mutatta nekem; sorok+oszlopok mm-es méretre állítva kész is a milliméterpapír. Ez Office XP-ben is már ment neki...) :D
Persze, papíron is meg excelben is lehet lehet kezelni sokmindent, de a papír sem kimondottan egy relációs adatbáziskezelő.
Kicsiben, pár adattal el lehet bohóckodni, de amikor kell a nagy tömegű, állandó, precíz eredmény, akkor azt a bugos MS termékékekre nem bíznám...
Egy egyszerű, üres cellákat kitöltő makró is több percig futott egy 200e soros munkalapon.

Excelben nem csak átírni, hanem törölni is lehet "észrevétlenül" sorokat,adatokat, aminek ugyancsak nem lenne jó következménye.

Ha mégis excel és makró az egyetlen lehetőség, akkor prog.hu -n micu szerintem biztosan kotörpöl valamit.

Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

Csak sokaknak az adatbázis = relációs adatbázis, nem pedig pár tábla az irodai programban. Nem mintha Excel-ben nem lehetne hivatkozni táblák/munkafüzetek között, de egy sérülékeny és lassú valami, aminek néhányan nagymesterei/voodoo varázslói tudnak lenni, de egy nagyobb irodai környezetben se nem elegáns, se nem biztonságos, a gyorsaságot meg már az elején kizártuk.
Bár amiket ki tudnak adni a kezükből nagy ERP gyártók, randa felülettel és csigalassúsággal, mikor majdnem DOS alatt szebbet tudtak alkotni, akkor azért valami ott se nagyon frankó.

Ezzel nem vagy egyedül:
https://stackoverflow.blog/2017/10/31/disliked-programming-languages/

Pedzem, hogy a kérdés lényegét (mármint ami annak sejthető) véletlenül sem érintő hozzászólások ebből a közös érzelemből is fakadnak.

"Az Excel legyen csak egy riport formátum a pénzügyeseknek."

LAMP-ot a Nevesincs Bt-nek a 300 tételes leltárjegyzékükhöz! Ha beledöglenek is!

Egy olyan tisztességes megoldást, amivel akkor se lesznek bajban, ha hirtelen meglódul a szekér és a 300-ból 3000 lesz. Valamint egyszer záródjon be rosszul az az excel mentéskor és mindjárt fuccs a pontos leltárnak, rossz esetben az egész jegyzéknek.

Valamint a topic indító nem simán csak tételeket rögzített, hanem már bérszámfejteni akart excel-lel.

Nem túl rövid és talán nem túl hiábavaló munkám során, amelyben az itt hivatkozott tényleg adatbáziskezelők egyikét-másikát ápolgattam, azt szűrtem le, hogy erőltetett tempójú (az a hírhedt 20%, ugye) szoftverkiadások és a "most má piszokul agilisak vagyunk, itt ül szemben az igénylő, írjuk be máris, hogy CREATE TABLE" felfogásból eredő miszkoncepciók messze nagyobb veszélyt jelentenek bármilyen adatb...halmaz integritására, mint árvíz, hwhiba, villámcsapás, földrengés, terroristák és Soros György együttvéve.

A fájdalmas, de járható megoldás, a mentésből visszaállás. Mint az excelnél is.

Egen, a bérszámfejtés mint feladat elég meredek. Legalábbis nekem most az volna, mivel 20 éve csak passzívan, a bérjegyzékem olvasásakor foglalkozom vele. Azért némi motiváció és idő után menne... mármint ha nem tartoznék én is a VBA-haterek táborába, és ez az első számú determináns, bár a tároló szoftver tényleg ott liheg a nyomában.

LAMP-ot a Nevesincs Bt-nek a 300 tételes leltárjegyzékükhöz! Ha beledöglenek is!

Egyébként ja :) Nálunk tök jól működik, hogy mindenen QR kódos címke van, egy beolvasással meg tudod nyitni a weboldalát és megnézni, hogy mikor/hol/kinél volt, kinek lett átadva, stb. Ez azért Excelben nem lett volna ilyen egyszerű...

Egy nagyságrenddel nagyobb, de 10-es szorzónál kisebb a tételszám a saját leltárrendszerünkben és annak kb. a 2/3-a a "hivatalos", központi ERP-ben levő. De most már 300-ra is nekiállnék és összedobnám.

(és igen, használ xlsx-t a rendszer, export és import formátum, mert arra tényleg jó, hogy gyorsan bevigyél vele sok adatot vagy random leszűrjél/kimutass)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én elhagynám az adatok leszűrését, és csak képletet használnék egy segédtáblával, amiben a dolgozók nevét és egyéni kódját tárolnám. Libre Office-ban a SZUMHATÖBB vagy az AB.SZUM függvényt alkalmaznám, gondolom van vmi exceles megfelelője. Ez táblázatkezelőben legalább két lépéses feladat.
(Adatbázisban egy kicsit könnyebb, mert "csak" egy lekérdezés..)