Telefonszámunk: 1-472-0679

Virtuális profit kalkuláció több tényezővel, függvényekkel

Kezdőlap Fórumok Excel témák Virtuális profit kalkuláció több tényezővel, függvényekkel

3 bejegyzés megtekintése - 1-3 / 3
  • Szerző
    Bejegyzés
  • #7966
    antalmate
    Felhasználó

      Sziasztok!

      Segítséget szeretnék kérni az alábbi, talán hosszabb volumenű projektben. Röviden-tömören az X idő alatt bekövetkezett profitot kellene valamilyen automatizált módon kiszámítani, ugyanis manuálisan még ígyis órákat vesz igénybe.
      Részletesebben pedig előbb felvázolnám a szituációt.
      Adott egy automatizált, játékbeli virtuális tárgyakat cserélgető robot, amely API-n keresztül 6 óránként frissíti az előre betáplált tárgyak árait, és azokat eladásra vagy megvételre kínálja a játékosoknak.

      Ez a robot 4 féle currency-t azaz cseretárgyat fogad el alapvetően (a betáplált tárgyakon túl):
      Scrap Metal (0,11)
      Reclaimed Metal (0,33)
      Refined Metal (1,00)
      Key (60,00)
      Ezeknek fix értékeik vannak: 3x Scrap Metal = 1x Reclaimed Metal; 3x Reclaimed Metal = 1x Refined Metal; 60x Refined Metal = 1x Key. (A 0,01-et felfelé kell kerekíteni: 8xScrap=0,88, 9x=1,00)

      Maga a csere úgy néz ki, hogy adott egy tárgy, az egyszerűség kedvéért egy Toll. Ezt a Tollat a robot 5,66 Refinedért vásárolja meg egy játékostól, majd akár 1 perc múlva, de lehet 5 nap múlva tovább ad rajta, remélhetőleg 0,11 Refined haszonnal. Az is előfordulhat, hogy 5 nap múlva leesik az ára 5 Refinedre és valaki megveszi, akkor 0,66 Refined elúszott.

      A robot nem képes összesíteni azt, hogy a bevett tárgy mennyiért került hozzá, mennyiért adott túl rajta és hogy mennyi a különbség a kettő között, viszont képes listázni nekem, hogy mely tárgyak mozogtak és mennyiért.
      Ez egy konkrét példa a lekérdezésből:
      Játékos ID | Neve | Csere időpontja | A robottól elkerült tárgyak | A robothoz került tárgyak
      3978700 |xAtlasFBTue |Dec 01 2020 17:47:49 |6x Refined Metal, 1x Reclaimed Metal | Gift Wrap

      6,33 Refinedet adott a Robot a tárgyért.

      Játékos ID | Neve | Csere időpontja | A robottól elkerült tárgyak| A robothoz került tárgyak
      2347700 | engineer gaming |Dec 01 2020 18:53:08 | Gift Wrap |6x Refined Metal, 4x Scrap Metal

      Amelyet 6,44 Refinedért adott tovább rá 1 órával, tehát 0,11 Refined haszonnal.

      A listát vesszővel elválasztva tudom lekérni, jelen lekérdezés 14 nap intervallumát takarja, kerek 400 sikeres cserével, ami áltagolva azt jelentené, hogy minden második cserén van 0,11 haszon, így leegyszerűsítve 200 sikeres cserénél 22 Refined hasznot eredményez. Ez teljesen általánosítás, vannak tárgyak amelyeket sikerült akár 5,00 haszonnal is továbbcserélni, de az ellenkezője is előfordult ahogy néztem.
      A „probléma” itt az, hogy a tárgyak mozgása össze-vissza történik, van hogy napokig a robotnál van, miközben több tucat/száz csere lemegy. Így nagyon nehéz nyomonkövetni egy-egy tárgy nyomát, hogy mennyiért lett becserélve, majd kiadva és hogy ezen volt-e haszon vagy nem. Egy fajta tárgyból maximum 1 darabbal kereskedik csak (ha nincs a robotnál Toll, akkor vásárlási ajánlatot listáz, ha valaki becserél egy Tollat, akkor csak eladási ajánlatot listáz).

      Excel 2003-at használok! Amit eddig próbáltam:
      -Kiindulási pont a becserélés, onnan kellene nyomonkövetni egy-egy tárgy „életét”. Ehhez először megpróbáltam külön listázni, hogy külön a becserélés és külön a kiadási oldalon van-e és hogy mennyi db a 4 currency közül bármelyik (igen, egyik oldalon mindig van, a másikon meg a tárgy, a Toll). DARABTELI függvényt használtam, hogy megállapítsam egy-egy cserén belül hány db van a 4 különböző currency közül, ami így néz ki:

      Key Refined Metal Reclaimed Metal Scrap Metal
      0 0 0 0 Gift Wrap (Robothoz került)
      0 6 1 0 Refined Metal Reclaimed Metal Refined Metal Refined Metal Refined Metal Refined Metal Refined Metal (Robottól elkerült).

      Ezt azért gondoltam, mert valahogy csatolni próbálnám ezt a 6+1 értéket ehhez az értékhez.
      Van-e a DARABTELI-nek valami értelme ebben az esetben, illetve összecsatolás féleség lehetséges-e?
      Másrészt pedig azt képzeltem, hogy összeadom a két oldal currency értékét külön-külön, és a bevételből kivonom a kiadást. Ez a dolog ott bukott meg igazán, hogy ezzel az éppen a robotnál lévő tárgyakat (Toll) is kiadásként kezeli a táblázat, hisz valóban, kiadta az ellenértéket. Ezért is lenne jó az, ha valamilyen úton módon egy-egy tárgyat kötni lehetne az értékéhez, és ha a robotnál marad a tárgy, akkor azt ne számolja kiadásként a táblázat.

      -Eddig még nem jeleztem, de a nehézséget az okozza, hogy a lista lekérdezés időrendi sorrendben történik, nem tudom/tudtam eddig külön osztani két csoportra csak bejövő vagy csak kimenő tárgyak szerinti sorolásra.
      Ennek érdekében igyekeztem VAGY függvénnyel IGAZ/HAMIS szerint beosztani őket, miszerint ha a bevételi oldalon (kép felső része) NINCS currency, akkor ott csak bejövő tárgy lehet. Ez viszont ott bukott meg, hogyha a robotnak vagy a játékosnak nincs „visszajárója” 0,11 pontossággal, akkor jóeséllyel beledob a cserébe pl 0,44 Refinedet, hogy ne veszítsen a cserén. Bolti példával élve: 10.000 Forinttal akarsz fizetni 2.100 Forintot. Értelemszerűen nem akarsz egy rakat aprót vissza, ezért adsz plusz egy 100-ast és mindenki boldog, és a visszajáród ugyanannyi marad, mintha nem adtál volna.

      Van-e bárkinek bármi ötlete, hogy hogyan tudnék valamiféle valós (ha nem is 0,11 pontosságú) profitot számolni?

      Tehát jelenleg itt tartok és örömmel fogadok bárminemű építő jellegű kritikát, tanácsot, kérdést! 🙂

      Előre is köszönöm!
      Üdv.:
      Máté

      UI: Hosszúra sikeredett, nem egy hétköznapi szituáció, de hátha valaki szereti a kihívásokat. Próbálkoztam Google kereséssel, Youtube-val függvények iránt, de sajnos az én megszokott 2003-as Excelem nem kedveli az angol nevű függvényeket…

      #7967
      antalmate
      Felhasználó

        Csak nem sikerült a képet odaraknia.

        Attachments:
        You must be logged in to view attached files.
        #8222
        verax
        Felhasználó

          Szia antalmate!

          Az eredmény, a bevétel és a kiadás különbsége. A nullánál nagyobb eredmény a nyereség, a nullánál kisebb eredmény a veszteség. A bevétel, a pénzkészlet növekedése, a kiadás a pénzkészlet csökkenése. De ezt te is tudod, mégis fontos tisztázni, mert ez segít a megfelelő számítási mód megtalálásában.
          Az árukészlet változása nem része az eredménynek. Tehát a tárgyakat nyugodtam kihagyhatod a számításaidból. Erre mondhatod, hogy „dehát azért vagyok veszteséges, mert vásároltam egy halom tárgyat, amelyek most eladásra várnak …” Igen ám, de amint te is írtad, nem tudható biztosan, hogy mennyi lesz azon tárgyak majdani eladási ára.

          Induló vagyonod:
          100 RF
          30 RC
          30 S

          1. Vásárolsz „A” tárgyat
          kiadás:
          4 RF
          1 RC
          Ez kiadás.
          Ha most számolnád ki az eredményt:
          Eredmény = Összes bevétel – Összes kiadás = 0 – 4RF1RC = – 4RF1RC (veszteség)
          (Igaz, van árukészleted. … De tudod-e, hogy mennyiért fogod eladni?)

          2. Eladsz „A” tárgyat
          bevétel:
          4 RF
          Ez bevétel.
          Ha most számolnád ki az eredményt:
          Eredmény = Összes bevétel – Összes kiadás = 4RF – 4RF1RC = – 1RC (veszteség)

          3. Vásárolsz „B” tárgyat
          kiadás:
          5 RF
          Ez kiadás.
          Ha most számolnád ki az eredményt:
          Eredmény = Összes bevétel – Összes kiadás = 4RF – 9RF1RC = – 5RF1RC (veszteség)

          4. Eladsz „B” tárgyat
          bevétel:
          6 RF
          Ez bevétel.
          Ha most számolnád ki az eredményt:
          Eredmény = Összes bevétel – Összes kiadás = 10RF – 9RF1RC = 2RC (nyereség)

          és így tovább…
          Tehát még egyszer: az árukészlet változása nem része az eredménynek. Az árukészlet változása közben realizált pénzmozgásokból számold az eredményt!

          üdvözlettel
          verax

        3 bejegyzés megtekintése - 1-3 / 3
        • Be kell jelentkezni a hozzászóláshoz.