FD32 tommer SAP: Tutorial til kreditkontrolområde

Af: Murer Garcia Murer Garcia
Hours Opdateret

⚡ Smart opsummering

Kreditkontrol i SAP begrænser eksponering for dårlige debitorer ved at tildele hver kunde en kreditgrænse inden for et kreditkontrolområde, og transaktion FD32 er det klassiske skærmbillede, hvor denne grænse opretholdes.

  • 🔘 Anvendelsesområde: Ét kreditkontrolområde kan betjene alle virksomhedskode, eller hver virksomhedskode kan have sit eget område.
  • ☑️ Transaktion: FD32 åbner kundens kreditstamdata, hvor kunden, kreditkontrolområdet og dataafsnittene vælges først.
  • ✅ Centrale data: Det samlede beløb begrænser kreditten på tværs af alle områder, mens den individuelle grænse begrænser kreditten inden for et enkelt område.
  • 🧪 Statusdata: Kreditgrænsen, risikokategorien og gennemgangsdatoerne på statusskærmen styrer den automatiske kredittjek.
  • 🛠️ Konfiguration: OB45, OB38, OVFL, OB01 og OVA8 opretter kreditkontrolområdet og de checks, der bruger det.
  • 📈 S/4HANA: FD32 er ikke tilgængelig i SAP S/4HANA, hvor forretningspartnerrollen UKM000 erstatter den klassiske kreditmaster.
Læs mere

Opretholdelse af en kundekreditgrænse med FD32 i SAP

Flere udestående tilgodehavender eller tab på fordringer kan have en betydelig indflydelse på en virksomheds præstation. Kreditkontrol reducerer denne risiko ved at definere en kreditgrænse for hver kunde og ved at kontrollere hver ny ordre i forhold til den.

Hvad er et kreditkontrolområde i SAP?

In SAPKredit- og risikostyring finder sted i kreditkontrolområdet. Hvis kreditstyringen er centraliseret, kan der defineres ét kreditkontrolområde for alle virksomhedskoder. Hvis kreditpolitikken kræver decentraliseret styring, kan der defineres et kreditkontrolområde for hver virksomhedskode eller for hver gruppe af virksomhedskoder.

Et kreditkontrolområde er derfor den organisatoriske enhed, der definerer og kontrollerer kundernes kreditgrænser. Det har sin egen valuta, og alle tilgodehavender bogført i kundefordringer øger den krediteksponering, der er registreret imod den.

Kreditkontrolområdet styrer især tre ting.

  • Begrænse: Den maksimale tilgodehavende værdi, som en kunde må have på et hvilket som helst tidspunkt inden for det pågældende område.
  • Udsættelse: Den løbende total af åbne varer, åbne ordrer, åbne leverancer og åbne fakturaer.
  • Reaktion: Om en ordre, der overskrider grænsen, advares om, blokeres eller tillades igennem.

Stamdata for kreditkontrolområdet vedligeholdes pr. kunde, og gennemgangen nedenfor viser hvordan.

Sådan opretholder du kundernes kreditgrænser i FD32 (trin for trin)

Trin 1) Indtast transaktionskoden FD32 i SAP kommandofeltet.

Kommandofeltet sidder øverst til venstre SAP GUI skærmen, som vist nedenfor.

SAP kommandofelt med transaktionskode FD32 indtastet

Trin 2) Indtast følgende på det næste skærmbillede.

  1. Indtast kunde-ID'et på den kunde, hvis kreditgrænser skal opretholdes.
  2. Gå ind i kreditkontrolområdet.
  3. Markér afkrydsningsfeltet Centrale data i datavalgblokken.

Indtastningsskærmen med alle tre indtastninger ser ud som skærmbilledet nedenfor.

FD32 startskærm med kunde, kreditkontrolområde og centrale data valgt

Trin 3) På det næste skærmbillede skal du vedligeholde kreditstyringsdataene for kunden.

Den centrale dataskærm viser det samlede beløb og den individuelle grænse, som skærmbilledet viser.

FD32 central dataskærm, der viser det samlede beløb og individuelle grænsefelter

Trin 4) Tryk på knappen Gem på SAP standardværktøjslinjen for at gemme ændringerne af kreditgrænserne.

Knappen Gem er diskikonet til venstre for værktøjslinjen, fremhævet nedenfor.

Gem-knappen på SAP standardværktøjslinje

En meddelelse i statuslinjen bekræfter, at ændringerne er foretaget. Den nye grænse gælder fra og med den næste kredittjek, så en ordre, der allerede er blokeret, skal frigives separat.

Konfiguration af kreditkontrolområde og relaterede relaterede emner SAP T-koder

FD32 vedligeholder kun stamdata. Selve kreditkontrolområdet og de kontroller, der konsulterer det, er konfigureret i Customising, så en grænse, der tilsyneladende ikke har nogen effekt, er normalt et konfigurationsgab snarere end en stamdatafejl.

T-kode Formål
OB45 Definer kreditkontrolområdet, dets valuta og dets opdateringsgruppe
OB38 Tildel en virksomhedskode til et kreditkontrolområde
OVFL Tildel et salgsområde til et kreditkontrolområde
OB01 Definer de risikokategorier, der er tilgængelige i et kreditkontrolområde
OVA8 Konfigurér automatisk kreditkontrol for et kreditkontrolområde, en risikokategori og en kreditgruppe
FD32 / FD33 Ændre og vise stamdata for kundekredit
F.31 / F.35 Kreditoversigt og rapportering af kreditstamdata
VKM1 / VKM4 Liste og frigiv salgsdokumenter, der er blokeret af kredittjekket

To forudsætninger er værd at bekræfte, før FD32 åbnes: kunden skal allerede findes i virksomhedskoden, og virksomhedskoden skal være tildelt det kreditkontrolområde, der indtastes. Hvor eksponeringstallet ser forkert ud i stedet for grænsen, er SD-siden af ​​konfigurationen dækket i SAP SD-kreditstyring guide.

RELATEREDE ARTIKLER

Nøglefelter på FD32-kreditstyringsskærmene

FD32 er en transaktion med flere skærme, og datavalgblokken på indtastningsskærmen bestemmer, hvilke skærme der åbnes. De felter, der er vigtigst, er anført nedenfor.

Skærm Felt Betydning
Centrale data Total beløb Den samlede kredit, som kunden kan modtage på tværs af alle kreditkontrolområder
Centrale data Individuel grænse Maksimal kredit, som kunden kan modtage inden for et enkelt kreditkontrolområde
Centrale data Valuta Valuta, hvori de centrale grænser holdes
Status Kreditgrænse Grænse tildelt i det kreditkontrolområde, der blev indtastet på den første skærm
Status Risikokategori Nøgle der afgør hvilken automatisk kredittjek fra OVA8 der gælder
Status Kreditrepræsentantgruppe Gruppe af medarbejdere, der er ansvarlige for at overvåge kontoen
Status Sidste og næste interne gennemgang Datoer, hvor grænsen sidst blev gennemgået og næste gang skal gennemgås
Betalingshistorik Betalingsdata Afregnede poster, gennemsnitlige restancedage og det største udestående beløb

Det samlede beløb og den individuelle grænse fungerer sammen: den individuelle grænse begrænser et bestemt område, mens det samlede beløb begrænser summen af ​​alle områder. Det accepteres, at der fastsættes en individuel grænse over det samlede beløb, men det har ingen praktisk effekt. RevVise datoer bidrager til kreditvurderingsarbejdslisten, så hvis de ikke er fyldt, fjernes kontoen stille og roligt fra listen.

Kreditstyring i SAP S/4HANA: Hvad erstatter FD32

Klassisk SD-kreditstyring er ikke tilgængelig i SAP S/4HANA. Den erstattes af SAP Kreditstyring, en del af Financial Supply Chain Management, og transaktionskoderne ændres i overensstemmelse hermed.

  • Stamdata: Kreditdata flyttes til forretningspartneren i rollen UKM000 og vedligeholdes med transaktion BP eller UKM_BP i stedet for FD32.
  • segmenter: Kreditkontrolområdet erstattes af et kreditsegment, og grænserne fastsættes pr. segment i stedet for pr. område.
  • Blokerede dokumenter: Dokumenterede kreditbeslutninger i UKM_MY_DCDS erstatter de klassiske udgivelseslister.
  • Borde: De klassiske KNKA- og KNKK-kreditmastertabeller viger for UKMBP_CMS-tabellerne, og eksponeringsstrukturerne S066 og S067 erstattes også.
  • Konvertering: Eksisterende kreditstamdata migreres under en systemkonvertering, så limits ikke skal indtastes igen.

Er der nogen, der stadig løber SAP ERP Central Component bevarer FD32 præcis som beskrevet ovenfor, og koncepterne overføres tydeligt: ​​en grænse, en risikokategori og et eksponeringstal findes på begge sider. En bearbejdet beskrivelse af forretningspartnerrollen er offentliggjort i denne SAP Fællesskabsartikel om SAP KreditstyringNedstrøms afbalancerer den samme kunde drevet Dunning og de clearingkorrektioner, der er omfattet af nulstilling af ryddede elementer.

Ofte Stillede Spørgsmål

Den automatiske kredittjek reagerer med en advarsel, en fejl eller en leveringsblokering, afhængigt af indstillingen for den pågældende risikokategori. Blokerede salgsdokumenter forbliver på en frigivelsesliste, indtil en kreditrepræsentant godkender eller afviser dem.

En statisk kontrol sammenligner grænsen med det samlede antal åbne varer, ordrer, leverancer og fakturadokumenter. En dynamisk kontrol tilføjer en kredithorisont, så ordrer, der er planlagt ud over denne horisont, ignoreres. Begge er konfigureret pr. risikokategori.

Eksponering holdes i opsummeringsstrukturer, der kan komme ud af trit efter en opdateringsfejl. Reorganiseringsrapporten RVKRED77 genopbygger kreditværdierne for de berørte kunder og kreditkontrolområder, hvorefter tallene matcher de åbne poster igen.

Klassiske kreditdata findes i egne tabeller i stedet for i de generelle kundemastervisninger: KNKA indeholder de centrale data, og KNKK indeholder én post pr. kreditkontrolområde. Derfor vedligeholdes dataene via FD32 og ikke via kundeoprettelsesskærmbillederne.

Maskinlæringsmodeller scorer betalingsadfærd, restancedage og eksterne vurderinger for at foreslå en grænse eller en risikokategori, og de rangerer inkassoopgaver efter sandsynlighed for betaling. Forslaget kræver stadig menneskelig godkendelse, før det når kreditmasteren.

Ja. Assistenter som f.eks. GitHub Copilot udarbejde ABAP-, batch-input- eller scriptkoden bag en massekreditgrænseindlæsning og forespørgslerne bag en eksponeringsrapport. Test først hvert genererede program i en sandbox-klient.

Grænsen holdes i kreditkontrolområdets valuta, som fastsættes, når området defineres. Dokumenter bogført i andre valutaer omregnes til den pågældende valuta, før eksponeringen sammenlignes med grænsen.

Enhver ændring i kreditmasteren logges, og ændringsdokumenterne kan opføres for en kunde og et kreditkontrolområde. Loggen viser den gamle værdi, den nye værdi, brugeren og datoen, hvilket er det, der normalt bedes om i en revision af kreditbeslutninger.

Opsummer dette indlæg med: