Tag Archives: SAP Query: taululiitos

Binders

SAP Query: sudenkuoppia

Aikaisemmissa esityksissä on opeteltu tekemään kyselyitä SAP QuickView:llä ja SAP Queryllä. Esimerkkinä käytettiin myynnin laskutusraporttia. Miksi SD eikä FI kysely?  Myynti on taloudelle hyvin kiinnostava alue, mutta SAP:ssa ei ole lainkaan valmiita myyntiraportteja talouden näkökulmasta. Myyntireskontran raportit katsovat asiaa avointen laskujen ja maksamisen kannalta.

Vuosien varrella olen tehnyt lukuisia kyselyitä taloudelle ja tilintarkastajille. Esimerkkeinä vaikka hyvityslaskut, vientilaskutus maittain ja valuutoittain, EU kolmikantakaupat, asiakaslaskutus tuloyksiköittäin.

SD kyselyn avulla on helppo esitellä kyselyn perustoiminnot kuten taululiitokset. FI-tauluja ei voi liittää toisiinsa, joten tämän alueen kyselyt pitää tehdä loogisista tietokannoista.

Vaikka SAP Queryn teko näyttää helpolta, onnistunut lopputulos vaatii käytetyn datan ymmärtämistä. Pitää tuntea, paitsi käytettävät taulut ja miten data on siellä talletettuna, myös sovellusalueen logiikkaa.

Varsinkin kyselyt SAP:n myyntitositteista voivat olla varsin haastavia. Joskus kysely ei tuota mitään ja joskus tulos on pelkkää roskaa. Kyselyn yksityiskohdat  kannattaa suunnitella huolellisesti ja tulokset tarkistaa moneen kertaan. Jopa ohjelmoijat, jotka tekevät SD raportteja voivat helposti mennä metsään.

Ongelmia tuottavat esimerkiksi:

  • Organisaatiorakenteet

Organisaatiorakenteet SD:ssä ja FI:ssä ovat erilaiset. Esimerkkikysely oli tehty talouden näkökulmasta ja siksi siinä käytetty organisaatioyksikkö oli yritys.

Yritys ei kuitenkaan ole myynnin organisaatiokäsite. Myynnin käyttäjät eivät tee kirjauksia yrityksille. He käyttävät myyntialueita, jonka osat ovat myyntiorganisaatio, jakelutie ja sektori.

Konfiguroinnissa myyntiorganisaatio kohdistetaan yritykseen.


  • Perustietojen kohdistukset ja hierarkiat

Sekä asiakkaat että nimikkeet ylläpidetään myyntialuetasolla.

Asiakas esiintyy SD:ssä myös monessa roolissa, tilausasiakas, toimitusasiakas, maksaja-asiakas jne.

SQ_query_customer_partner_roles

Perustietoihin liittyvät myös hierarkiat. Asiakkaat kuuluvat asiakashierarkiaan ja nimikkeet tuotehierarkiaan. Näiden käsittely queryillä on hankalaa.

Koska kysely ei summaa rivejä vaan näyttää kaikki osumat, siihen tulee helposti kerrannaisia rivejä. Esimerkiksi, jos kysely tehdään myyntiorganisaatiotasolla, kuvan asiakas 1000 tulee siihen kahteen kertaan. Kun kyselyyn lisätään jakelutie, nähdään syy. Asiakkaalla on myyntiä kahdella jakelutiellä (1000-10 ja 1000-12).

Kerrannaisia rivejä tulee myös, kun taululiitoksissa data otetaan väärältä tasolta. Aikaisemmissa esimerkeissä tästä nähtiin taululiitos laskuotsikko- ja laskurivitaulujen välillä, jossa nettomyynti otettiin otsikkotasolta. Lopputuloksena raportti, jossa sama asiakkaan lasku esiintyi neljä kertaa.

SQ_query_sales_rep_netvalue_VBRK

Kun kyselyyn lisätään nettoarvo rivitiedoista. alkaa ongelman syy selvitä. Ensimmäisessä nettoarvosarakkeessa toistuu laskun loppusumma, joka syntyy laskurivikohtaisista summista. Voi olla, että tavoitteena on ollut raportti, jossa on asiakaskohtainen laskun loppusumma ja sen alla rivierittely. Näin sitä ei kuitenkaan voi tehdä.

SQ_query_sales_rep_netvalue_VBRK

Vältä sudenkuoppia

  • Etumerkit

Esimerkkikyselyissämme olemme törmänneet arvokenttien etumerkkiongelmaan. Arvokentät tallennetaan tietokantaan absoluuttisina lukuina ilman etumerkkiä. Edellisissä esityksissä on esitetty erilaisia ratkaisuja tähän ongelmaan.

  • Valuutat

Myynti tallennetaan vain tositevaluutassa, jonka lisäksi on tallennettu valuutan muuntokerroin. Jos summat halutaan myös kotivaluutassa, pitää käyttää ne laskea kertoimien avulla. Sitä varten täytyy tietää miten SAP käsittelee valuuttakursseja. Se vaihtelee valuutoittain. Kurssi voi olla suora tai käänteinen. Valuutoissa voi olla kertoimia tai osassa ei ole lainkaan desimaaleja (esim.  Japanin jeni).

  • Valuuttamääräiset lisäveloitukset ja -hyvitykset

Veloituksia ja hyvityksiä on erilaisia. Osassa arvo, määrä ja omakustannus muuttuvat. Osassa taas hyvitys tai veloitus on vain rahallinen, eivätkä muut suureet muutu.

  • Taululiitokset: perustiedot

QuickView kyselyssä myynnin tauluihin liitettiin asiakastaulu KNA1, jotta saatiin kyselyyn asiakkaan nimi. Tätä tarvetta ei ole SAP Queryssä, koska suurimmalle osalle ominaisuuksista tekstikenttä on liitetty ja valittavissa.

Ei ole hyvä idea liittää perustietotauluja myynnin tauluihin. Perustiedot ovat voineet muuttua myyntitapahtuman jälkeen. Alkuperäiset arvot on tallennettu myyntitositteisiin. Siksi kyselyissä pitäisi käyttää näitä arvoja.

Tämän esityksen lopussa on kuitenkin esitys, jossa näytetään miten taululiitoksen muutos tehdään SAP Queryllä. Esityksessä lisätään VAT-numero asiakastaulusta kyselyyn.


Changing SAP Billing Query: Joins and join conditions


COPA-raportointi?

Ei kannata yrittää mitään  kovin monimutkaista SAP Queryllä. Vaativampaan myyntiraportointiin esimerkiksi COPA on parempi valinta. Erityisen hyvin se sopii kateraportointiin. COPA raportit päivittyvät automaattisesti laskutuksen yhteydessä. Valuutat ja etumerkit menevät oikein. Raportointi on mahdollista myös asiakas- ja tuotehierarkian tasoilta.

Kateraportointia varten voit helposti luoda uusia arvokenttiä ja laskentamalleja. COPA:n käyttöönotto vaatii konfigurointia, mutta kun se on pystyssä, raporttien teko on helppoa. COPA raportit ovat porautumisraportteja ja niiden tekeminen samanlaista kuin Report Painter raporttien.

Yhteenveto

Jos olet tutustunut aikaisempiin esityksiini ja mahdollisesti harjoitellut omien kyselyiden teko, olet jo pitkällä. Älä anna vastoinkäymisten lannistaa. Sitkeydellä ja aina vaan uudelleen yrittämällä sinusta tulee yrityksen Query-mestari, jonka uskotaan tietävän “kaiken sapista”.