FD32 tommer SAP: Veiledning for kredittkontrollområde

by: Mason Garcia Mason Garcia
Hours oppdatert

⚡ Smart oppsummering

Kredittkontroll i SAP begrenser eksponering for tap på fordringer ved å tildele hver kunde en kredittgrense innenfor et kredittkontrollområde, og transaksjon FD32 er det klassiske skjermbildet der denne grensen opprettholdes.

  • 🔘 Omfang: Ett kredittkontrollområde kan betjene alle selskapskodene, eller hver selskapskode kan ha sitt eget område.
  • ☑️ Transaksjon: FD32 åpner kundens kredittstamdata, hvor kunden, kredittkontrollområdet og dataseksjonene velges først.
  • ✅ Sentrale data: Totalbeløpet begrenser kreditten på tvers av alle områder, mens den individuelle grensen begrenser kreditten innenfor et enkelt område.
  • 🧪 Statusdata: Kredittgrensen, risikokategorien og gjennomgangsdatoene på statusskjermen styrer den automatiske kredittsjekken.
  • 🛠️ konfigurasjon: OB45, OB38, OVFL, OB01 og OVA8 oppretter kredittkontrollområdet og sjekkene som bruker det.
  • 📈 S/4HANA: FD32 er ikke tilgjengelig i SAP S/4HANA, der forretningspartnerrollen UKM000 erstatter den klassiske kredittmasteren.
Les mer

Opprettholde en kundekredittgrense med FD32 i SAP

Flere utestående fordringer eller tap på fordringer kan ha betydelig innvirkning på et selskaps resultater. Kredittkontroll reduserer denne risikoen ved å definere en kredittgrense for hver kunde og ved å sjekke hver nye ordre mot den.

Hva er et kredittkontrollområde i SAP?

In SAP, kreditt- og risikostyring foregår i kredittkontrollområdet. Hvis kredittstyringen er sentralisert, kan ett kredittkontrollområde defineres for alle selskapskoder. Hvis kredittpolicyen krever desentralisert styring, kan et kredittkontrollområde defineres for hver selskapskode eller for hver gruppe av selskapskoder.

Et kredittkontrollområde er derfor den organisatoriske enheten som definerer og kontrollerer kundenes kredittgrenser. Det har sin egen valuta, og alle kundefordringer som er postert i kundefordringer øker kreditteksponeringen som er registrert mot den.

Kredittkontrollområdet styrer spesielt tre ting.

  • Grense: Den maksimale kundefordringsverdien en kunde kan ha til enhver tid innenfor det området.
  • Eksponering: Den løpende summen av åpne varer, åpne ordrer, åpne leveranser og åpne fakturaer.
  • Reaksjon: Om en ordre som bryter grensen blir advart om, blokkert eller tillatt gjennom.

Stamdata for kredittkontrollområdet vedlikeholdes per kunde, og gjennomgangen nedenfor viser hvordan.

Slik opprettholder du kundenes kredittgrenser i FD32 (trinn for trinn)

Trinn 1) Skriv inn transaksjonskoden FD32 i SAP kommandofeltet.

Kommandofeltet sitter øverst til venstre SAP GUI skjermen, som vist nedenfor.

SAP kommandofelt med transaksjonskode FD32 angitt

Trinn 2) I neste skjermbilde skriver du inn følgende.

  1. Skriv inn kunde-ID-en til kunden hvis kredittgrenser skal opprettholdes.
  2. Gå inn i kredittkontrollområdet.
  3. Merk av for Sentrale data i datavalgblokken.

Inndataskjermen med alle tre inntastingene ser ut som skjermbildet nedenfor.

FD32 startskjerm med kunde, kredittkontrollområde og sentrale data valgt

Trinn 3) I neste skjermbilde vedlikeholder du kredittbehandlingsdataene for kunden.

Den sentrale dataskjermen viser totalbeløpet og den individuelle grensen, som skjermbildet viser.

FD32 sentral dataskjerm som viser totalbeløpet og individuelle grensefelt

Trinn 4) Trykk på Lagre-knappen på SAP standardverktøylinjen for å lagre endringene som er gjort i kredittgrensene.

Lagre-knappen er diskikonet til venstre på verktøylinjen, uthevet nedenfor.

Lagre-knappen på SAP standard verktøylinje

En melding i statuslinjen bekrefter at endringene er gjort. Den nye grensen gjelder fra neste kredittsjekk og utover, så en ordre som allerede er blokkert må frigis separat.

Konfigurasjon av kredittkontrollområde og relaterte SAP T-koder

FD32 vedlikeholder bare stamdata. Selve kredittkontrollområdet, og kontrollene som konsulterer det, er konfigurert i Tilpassing, så en grense som tilsynelatende ikke har noen effekt er vanligvis et konfigurasjonsgap snarere enn en stamdatafeil.

T-kode Formål
OB45 Definer kredittkontrollområdet, valutaen og oppdateringsgruppen
OB38 Tilordne en firmakode til et kredittkontrollområde
OVFL Tilordne et salgsområde til et kredittkontrollområde
OB01 Definer risikokategoriene som er tilgjengelige i et kredittkontrollområde
OVA8 Konfigurer automatisk kredittkontroll for et kredittkontrollområde, en risikokategori og en kredittgruppe
FD32 / FD33 Endre og vise stamdata for kundekreditt
F.31 / F.35 Kredittoversikt og rapportering av kredittstamdata
VKM1 / VKM4 Liste over og frigi salgsdokumenter som er blokkert av kredittsjekken

To forutsetninger er verdt å bekrefte før FD32 åpnes: kunden må allerede finnes i firmakoden, og firmakoden må være tilordnet kredittkontrollområdet som legges inn. Der eksponeringstallet ser feil ut i stedet for grensen, dekkes SD-siden av konfigurasjonen i SAP SD-kreditthåndtering guide.

RELATERTE ARTIKLER

Nøkkelfelt på FD32-kreditthåndteringsskjermbildene

FD32 er en transaksjon med flere skjermbilder, og datavalgblokken på inntastingsskjermen bestemmer hvilke skjermbilder som åpnes. Feltene som er viktigst er listet opp nedenfor.

Skjerm Felt Betydning
Sentrale data Totale mengden Total kreditt som kunden kan motta på tvers av alle kredittkontrollområder
Sentrale data Individuell grense Maksimal kreditt kunden kan motta innenfor et enkelt kredittkontrollområde
Sentrale data valuta Valutaen som de sentrale grensene holdes i
status Kredittgrense Grense gitt i kredittkontrollområdet som ble angitt på det første skjermbildet
status Risikokategori Nøkkel som avgjør hvilken automatisk kredittsjekk fra OVA8 som gjelder
status Kredittrepresentantgruppe Gruppe av ansatte som er ansvarlige for å overvåke kontoen
status Siste og neste interne gjennomgang Datoer da grensen sist ble gjennomgått og neste gang den skal gjennomgås
Betalingshistorikk Betalingsdata Avregnede poster, gjennomsnittlig antall dager i restans og det største utestående beløpet

Totalbeløpet og den individuelle grensen fungerer sammen: den individuelle grensen setter et tak på et hvilket som helst område, mens totalbeløpet setter et tak på summen av alle områder. Å sette en individuell grense over totalbeløpet er akseptert, men har ingen praktisk effekt. RevVise datoer mater arbeidslisten for kredittvurdering, så hvis du lar dem stå tomme, fjernes kontoen i det stille fra listen.

Kreditthåndtering i SAP S/4HANA: Hva erstatter FD32

Klassisk SD-kreditthåndtering er ikke tilgjengelig i SAP S/4HANA. Den er erstattet av SAP Kreditthåndtering, en del av Financial Supply Chain Management, og transaksjonskodene endres deretter.

  • Stamdata: Kredittdata flyttes til forretningspartneren i rollen UKM000, vedlikeholdt med transaksjon BP eller UKM_BP i stedet for FD32.
  • segmenter: Kredittkontrollområdet erstattes av et kredittsegment, og grensene holdes per segment i stedet for per område.
  • Blokkerte dokumenter: Dokumenterte kredittbeslutninger i UKM_MY_DCDS erstatter de klassiske utgivelseslistene.
  • bord: De klassiske KNKA- og KNKK-kredittmastertabellene viker for UKMBP_CMS-tabellene, og eksponeringsstrukturene S066 og S067 erstattes også.
  • Konvertering: Eksisterende kredittstamdata migreres under en systemkonvertering, slik at grenser ikke trenger å tastes inn på nytt.

Noen som fortsatt løper SAP ERP Central Component beholder FD32 nøyaktig slik det er beskrevet ovenfor, og konseptene gjenspeiles tydelig: en grense, en risikokategori og et eksponeringstall finnes på begge sider. En utarbeidet beskrivelse av forretningspartnerrollen er publisert i denne SAP Fellesskapsartikkel om SAP KredittstyringNedstrøms balanserer den samme kunden drivkraften purring og clearingkorreksjonene som er dekket i tilbakestilling av slettede elementer.

Spørsmål og svar

Den automatiske kredittsjekken reagerer med en advarsel, en feil eller en leveringsblokkering, avhengig av innstillingen for den risikokategorien. Blokkerte salgsdokumenter forblir i en frigivelsesliste inntil en kredittrepresentant godkjenner eller avviser dem.

En statisk sjekk sammenligner grensen mot totalt antall åpne varer, ordrer, leveranser og fakturadokumenter. En dynamisk sjekk legger til en kreditthorisont, slik at ordrer planlagt utover denne horisonten ignoreres. Begge er konfigurert per risikokategori.

Eksponering holdes i sammendragsstrukturer som kan komme ut av takt etter en oppdateringsfeil. Omorganiseringsrapport RVKRED77 gjenoppbygger kredittverdiene for de berørte kundene og kredittkontrollområdene, hvoretter tallene samsvarer med de åpne postene igjen.

Klassiske kredittdata ligger i egne tabeller i stedet for i de generelle kundehovedvisningene: KNKA inneholder de sentrale dataene og KNKK har én post per kredittkontrollområde. Derfor vedlikeholdes dataene via FD32 og ikke via kundeopprettelsesskjermbildene.

Maskinlæringsmodeller vurderer betalingsatferd, antall dager i restans og eksterne vurderinger for å foreslå en grense eller en risikokategori, og de rangerer inkassoarbeidslister etter sannsynlighet for betaling. Forslaget trenger fortsatt menneskelig godkjenning før det når kredittmasteren.

Ja. Assistenter som GitHub Copilot utarbeide ABAP-, batch-input- eller skriptkoden bak en massekredittgrenseinnlasting og spørringene bak en eksponeringsrapport. Teste først hvert genererte program i en sandkasseklient.

Grensen holdes i valutaen til kredittkontrollområdet, som er fastsatt når området defineres. Dokumenter som er lagt ut i andre valutaer omregnes til den valutaen før eksponeringen sammenlignes med grensen.

Hver endring i kredittstamdataene logges, og endringsdokumentene kan listes opp for en kunde og et kredittkontrollområde. Loggen viser den gamle verdien, den nye verdien, brukeren og datoen, som er det en revisjon av kredittbeslutninger vanligvis ber om.

Oppsummer dette innlegget med: