" A ChatGPT az indulását követő egy öt nap után már 1 millió felhasználója volt. Összehasonlításképpen: a Facebooknak ehhez 10 hónap kellett, a Netflix-nek 41 hónap. Ez mutatja milyen radikálisan új dologról van szó. "
A polcon van 7 póló: 2 zöld és 5 piros. Találomra kiveszünk 4 pólót. Mennyi a valószínűsége, hogy a kivett 4 póló mind piros?
Ő:
Az összes lehetséges eset száma a 7 pólóból 4-et kivenni: 7! / (4! * (7-4)!) = 35
A piros pólók száma: 5! / (4! * (5-4)!) = 5
A zöld pólók száma: 2! / (2! * (2-2)!) = 1
Tehát a piros pólók és a zöld pólók számának szorzata a piros pólókkal kivont pólók valószínűsége: (5 * 4 * 3 * 2) / 35 = 0,3428
Tehát a valószínűség, hogy a kivett 4 póló mind piros, 0,3428 vagy 34,28%.
Én:
Nem értem a "pólók száma" soraidat. Minek a száma az 5 és az 1?
Ezenkívül az egyenlőséget tartalmazó sort sem értem. A behelyettesített számok nem tudom, honnan valók, de emellett a képlet eredménye 1-nél nagyobb szám, nem pedig 0,3428.
Ő:
Elnézést, félreértettem a feladatot. Az általad említett egyenlőség valóban nem helyes, és nem tudom, hogy honnan származnak az adatok. Kérlek, pontosítsd a feladatot vagy add meg részletesebben az információkat, hogy segíthessek a megoldásban.
Tény, ami tény: ha felvilágosítod, hogy butaságot beszél, azt elismeri. De ha nem tudod, hogy butaságot beszél, akkor tőle nem is fogod megtudni.
Érdekes élmény lehet őrá hagyatkozni; én nem tenném.
Ugyan tökéletesen földbuta a ChatGPT, és tökéletesen fogalmatlan, lövése sincs, hogy miről szövegel, de még így is überel téged, úgyhogy tényleg jól teszed, hogy a nálad okosabbakra hallgatsz.
Oké. Nyilvánvaló, hogy az egészet csak felidegelő trollkodásnak indítottad el, hiszen mindent meg lehet oldani, csak akarni kell, viszont ha makacs nemakarás van, akkor az a cég nyugodtan lehúzhatja a rolót.
Viszont a topiknyitót már sikeresen felhúztad, hiszen már a moderációnál panaszkodik.
De most azt kellene megoldani, hogy a termék neve ugyanahhoz az azonosítóhoz több nyelven is megadható legyen. És a több évre visszamenőleg felhalmozódott rekordok megfelelően konverálódjanak. Kell még egy tábla. Abban a kulcs egy sorszám legyen. Aztán a másik tábla kulcsának mefelelő mező. Nyelv azonosítója, mondjuk két betű (pl. HU), hogy ne kelljen még egy tábla a nyelvhez. Aztán valaki egyenként minden termék nevét megadja a szükséges nyelveken. Lesz redundancia elkerülhetetlenül. És végül az új táblában lévő megnevezést használni az eredeti táblában lévő helyett.
Egyébként a hosszú terméknév nem nagy gond, csak úgy ötszáz fajta termékről van szó.
Ez katasztrofális. Ha ez az azonosító, akkor ezt a kitudjahánykarakteres szöveget tartalmazza minden érintett tábla minden hivatkozása? Elmebeteg dolog, több helyet foglal, mint maga az adat, arról nem beszélve, hogy pl. átnevezésről ne is álmodjon senki, mert arra egy hétvége rámegy, hogy a rendszer mindenhol átírja - feltéve, hogy nem jön közbe egy apró zavar, mert akkor a tranzakciós fájl alapján (ha ugyan ismerik a fogalmat) visszajavítani az újabb két nap.
Ha nem akar ismétlődést, azt ember módjára megírt kóddal is ki lehet zárni.
(Arról nem beszélve, hogy tisztességes helyen az említett holmit "Csapágylehúzó, körmös, nikkelezett"-ként tartják nyilván, mint ahogy a fizetési jegyzék se hajszín szerint van sorbarakva (vagy ki tudja ...?), hanem ahogy halandók keresnének benne.)
Elvileg mindent lehet. Gyakorlatilag amikor nála fogyóban van, olyankor jön érdeklődni, hogy mennyi van kész, mert néhányat elvinne sürgősen. És odaadják neki. Évek óta így megy. Változó, hogy nála miből mennyi fogy.
Van még egy érdekesség.
A kísérő bizonylatot a külföldi tulajdonú cégek angolul kérik (kérték).
Ugyanaz a termék több nyelven is be van írva. Remek.
A termékek neve a kulcs, nehogy kétszer beírják ugyanazt.
Több telephely/projekt esetén pedig a cég nevéhez tartozó kapcsolattartó telefonszámát alkalmanként átírják, vagy nem. Tökéletesen működik a rendszer.
Időnként jönnek, hogy sok évvel ezelőtt vettek valamit, nem tudják a típust. Kellene egy ugyanolyan, mert elromlott. Megpróbáljuk megkeresni. Szóval máshol is pontosan tudják, hogy mikor kitől mit vettek.
4. A megrendelésbe vagy a szerződéskötésbe ki kell kötni, hogy a tételek átvételi lehetőségéről a gyártó értesíti a megrendelőt, és a gyártó csak akkor értesít, amikor megvan a megrendelt mennyiség.
Probléma megoldva.
Ha a megrendelő szívja a fogát, akkor le kell ülni vele és megbeszélni, hogy mondjuk heti rendszerességgel mennyit vehet át, és ekkor mennyit rendeljen meg hetente.
Természetesen. Mégis mi a fene másra számítottál ...? :o
De most tényleg. Arra gondoltál, hogy itt valaki (pl. Herr/Frau ChatGPT) leírja, hogy ott nálatok valakinek pontosan mit kell tennie? Mert az biztosan csak három konkrét tőmondat, csak ott momentán épp senkinek nem ötlik eszébe?
Ehh.
(Rizsamajsz kolléga meg majd biztosan jelentkezik, hog szétoffoltuk a topikját ...)
Ez már késő. Huszonsok évvel ezelőtt így csinálta meg egy profi cég. Azóta is sikeresen működik.
(Komoly helyre szállítanak. Remélem, hogy ott a megrendelő tudja szakmailag felügyelni a kivitelezőt. Persze oda mi is szállítunk, és a tapasztalat az, hogy nem igazán.)
hanem minden előforduló tranzakciót rögzíteni kell, és minden előfordulható tranzakciónak előre elképzelt helye kell hogy legyen a rendszerben
Aki elképzelte a rendszert, az emelőgép tervzéshez több köze van, mint a nyilvántartáshoz. Sorry.
Hogy úgy mondjam, ad hoc szakember. Mindig csak azzal a problémával foglalkozik, amelyik előjön.
Bizonyos dolgokat persze lehet így is csinálni, ehhez szokott hozzá.
Szóval: mondtat(t)ok amit akar(t)ok. Akár mehetné(n)k is rizsát majszolni. :o)
Nézd, azt ne várd itt senkitől hogy megoldják helyetted vagy a céged helyett a problémát. Szerintem a következő opcióid vannak:
1. vesztek egy ERP rendszert 100k nagyságrendű euróért, azzal fog érkezni egy csomó szakértő, akik megértik az üzleti folyamataitokat és ennek megfelelően testreszabják a rendszert. 2. megbíztok egy tanácsadó céget, az fog küldeni egy-két, a terlületet jól ismerő okos gyereket. Ezek a srácok szintén azzal kezdik, hogy felmérik a folyamatokat, majd segítenek kitalálni, hogy milyen adatmodellel lehet azokat a legjobban megtámogatni. Ez egy pár hetes történet lenne, tanácsadótól függően olyan 1000-2000 eurós napdíjat fognak elkérni érte. Az adatmodellt ill. az azt támogató szoftvert már a ti dolgotok lesz lefejleszteni. 3. Van még a hályogkovácsolós módszer, amikor te magad megpróbálod átvenni a fent említett tanácsadók szerepét. Szerintem vannak a kockázatai a megközeletíésnek, de azért lehet jól is csinálni. Éppen ezért javasoltam elindulásnak, hogy nézz bele egy kicsit az SAP BW-be (az alaptáblák struktúráját meg lehet találni a neten). Ez persze egy baromi bonyolult, nagy cégekre optimalizált, mindenféle kivételek kezelésére kitalált adatmodell, de ötletet adhat arra, hogy merre érdemes elindulnod a ti sokkal egyszerűbb folyamatotok esetén. De sem egyetlen fórumozó, se egy csevegő robot - hogy legalább egy kicsit ontopikok legyünk - nem tudja megspórolni neked azt az erősen iteratív munkát, hogy kifejlesszen egy adatmodellt ami pont a te cégedre van testreszabva.
Cégek szétválhatnak és csinálhatnak, amit akarnak; aki rendelt, az vigye.
Ha telephelyek külön rendelhetnek, akkor természetesen a cégazonosítóhoz legyen több megrendelő is kapcsolható.
Az, hogy ez "a legtöbb esetben felesleges komplikáció", mindössze azt jelenti, hogy nem csak a legtöbb esetre kell felkészülni. Ettől lenne szakma ez (ha lenne, aki belássa és ne amatőrökre bízná).
A cég neve éppen ezért ne legyen a kulcs. Az az öngyilkosságnak egy bár cizellált és szofisztikált, mindazonáltal az Emberjogi Chartába ütközően mocskos válfaja.
Gondolom, a dolgozók is név szerint vannak nyilvántartva, és fizetésnapokon a tizenhét Kovács János elmegy a kocsmába és ott egymás közt felosztja az amúgy ötletszerűen felmarkolt fizetését, mielőtt elissza.
Ha valamit követhetően akartok nyilvántartani, akkor - meg fogsz lepődni - követhetően kell nyilvántartani. Nem lehet elspórolni, ami "csak ritkán fordul elő", hanem minden előforduló tranzakciót rögzíteni kell, és minden előfordulható tranzakciónak előre elképzelt helye kell hogy legyen a rendszerben, hogy a redundanciákat és az ütközéseket el lehessen kerülni, és a lekérdezéseket ne kilencszáznyolcvan soros, harminchét feltételes elágazással felturbózott SQL-paraméterekkel kelljen működtetni.
"Ennyi okos ember hátha meg tudja oldani a lehetetlent."
Kicsoda helyett???
Mondhatunk mi itt akármit, ha erre nincs egy hozzáértő emberetek. Vagy nálatok minden probléma netes fórumokra van kiadva? Legközelebb az lesz a kérdés, hogy milyen ragasztó kell a cipőtalphoz, mert áll a termelés?
Nem vagyok semmilyen szak;rtője a témának, de SAP BW-t egyszer láttam közelről (gyógyszergyár), ott is az ellentétes oldalát a problémádnak, azaz hogyan kezelik a gyárba érkező anyagokat. Ott úgy volt megoldva, hogy volt egy tábla a rendeléseknek, meg egy másik a beérkezett anyagoknak, egy harmadik a minőségellenőrzési eredményeket tartalmazta, s.i.t.. Ezeket a táblákat különböző belső azonosítokkal össze lehet kötni, és pl. lehet válaszolni olyan kérdésekre, hogy mennyire fed át egy adott rendeléssel a ténylegesen beérkező cucc.
szerintem nyugodtan kérdezd meg az ai-t. leírod neki mi okozza a legnagyobb problémát a nyilvántartásban (bár azt senki nem fogja tudni neked megjósolni, hány részletben fogja megvenni a megrendelő). ha nem érti, pontosítasz (én mindig kikötöm hogy oop példát adjon, ne egy main függvénybe ömlesztett spagettit). általában szokott adni egy kezdeményt, ami valószínűleg kicsit sem lesz tökéletes, de adhat ötleteket és kiindulásként használhatod egy olyan mintakódhoz, amit tovább fejlesztgethetsz, próbálgathatsz amíg a kérdéses problémát meg nem oldja. azután csak valahogy adaptálnod kell a meglévő rendszerre (magyarán bele kell hákolni).
Ennyi okos ember hátha meg tudja oldani a lehetetlent. :o)
Komplikált megoldás több is elképzelhető. Például amikor elvisz 17 darabot, akkor az eredeti bejegyzés sztornó, és ketté kell bontani. Teljesített és még nem teljesített tételekre. Vagy egy külön excel táblában követni az egyetlen renitens vevőt. Addig nem is kellene beírni a fő nyilvántartásba. Vagy csak akkor adni neki oda, amikor mind elkészült. És nem adni oda a többlet darabokat. (Persze ha több a selejt, és nem tud annyit vinni, mint amennyit akar, az akkor is probléma.)
Mások is javasolták, hogy a számlázóprogramhoz meg kell venni ezeket a bővítményeket.
Bölcs Árnyék válaszára még kíváncsi lennék. Hátha megkérdezi a bölcs elmét...
Kinek a szándéka hiányzik? A cégvezetésé? Ismerős ez a stílus (a szegény, mindent elviselni - sőt, feltalálni - kénytelen beosztotté, úgy értem).
A te szándékod nem hiányzik, de nem is világos. Mit szeretnél? Programkódot?
Legyen egy lista a megrendelésekről (ez remélhetőleg már van ... ha mégse, akkor az nem cég), és megrendelésenként ne egy rekord a teljesítésekről, hanem azokról is egy (újabb elemmel bármikor bővíthető) lista: ahányszor a megrendelésre hivatkozva visznek valamit, az ott egy újabb tételen (dátummal meg ami kell) jegyezve legyen. Így bármikor (és bármely időpontra!) lekérdezhető, hogy áll a teljesítés. Ha a megrendelés eredeti db-számán felül is vihet darabot, akkor eldöntitek, hogy ez a rendelés (külön tételen, nem az eredeti felülírásával elvégzett, hanem új dátumon beállított) módosításával, vagy új rendeléssel legyen megoldható. Fontos, hogy minden tranzakció mellett legyen dátum, mert akkor rendelésenként bármely időpillanatra le lehet kérdezni, hogy akkor éppen mennyi volt hivatalosan a rendelt mennyiség, mennyi lett kiszállítva, mennyi lett kifizetve. A "bármely időpillanat" természetesen lehet a mai nap jelen pillanata is.
