Als u de afschrijving moet uitvoeren door bedrijfscode wise, de T-code AFAB (programmanaam RAPOST2000) kan worden uitgevoerd. Het programma RAPOST2010 maakt selectie van verschillende bedrijfscodes mogelijk. De rapport selectie variabelen kunnen worden gehandhaafd in de tvarv tabel voor beide programma ‘ s en kunnen worden gepland met behulp van de scheduler Manager.
geplande Detachering
de geplande Detachering is de standaard periodieke detachering om geplande afschrijvingen te plaatsen. Dit moet worden gebruikt wanneer de laatste afschrijvingsrun succesvol was, en het is tijd om de afschrijvingsrun uit te voeren als onderdeel van het nieuwe periode-sluitingsproces. Het systeem controleert of de postperiode de periode is die volgt op de laatste met succes geplaatste periode; deze informatie wordt vervolgens geregistreerd in Tabel T093D, in de velden AFBLPE (periode) en AFBLCJ (jaar). Bovendien wordt de status van een afschrijvingsrun ook bijgewerkt in de tabel TABA. De veldnamen in TABA zijn ” Document geplaatst indicator-XBUKZ en periode waarin de laatste afschrijving werd geplaatst-AFBLPE. Houd er rekening mee dat TABA-vermelding als eerste wordt aangemaakt tijdens het postproces. De tabel T093D wordt bijgewerkt als een van de laatste stappen. Houd er echter rekening mee dat de tabel T093D niet zou worden bijgewerkt voor testruns. Bovendien slaat de tabel ANLP de waarde van de afschrijvingen van elke afschrijvingsrun op. Het veld NAFAZ heeft waarde te deponeren uit deze afschrijving run.
herstarten
de herstartprocedure wordt alleen gebruikt als de Afschrijvingsopstelling tijdens de verwerking is beëindigd vanwege een systeemstoring of een fout waardoor deze abnormaal is beëindigd. Als de posting run om technische redenen is beëindigd en er al wijzigingen zijn aangebracht in de database, moet het afschrijvingsrapport beginnen in de herstartmodus zijn.
bijvoorbeeld, wanneer een actief een gesloten WBS of een ongeldig kostencentrum heeft, maakt het systeem posten naar vaste activa sub-grootboek (door het bijwerken van de tabellen ANLC/ANLP), maar de taak niet om te posten naar G/L. met andere woorden, het programma niet de posten naar G/L, dus een inconsistentie gecreëerd op dit punt van de tijd tussen FI-AA en FI-GL, ten minste tot het opnieuw opstarten van de afschrijving wordt uitgevoerd. Als de WBS of het kostencentrum is vastgesteld in de asset master, zal de herstart de tabellen resetten en de geplande posting Uitvoeren, te beginnen op het punt dat het werd onderbroken. Dit zal elke database van mogelijke inconsistenties wissen. Het gebruik van de herstartmodus zorgt ervoor dat alle systeemactiviteiten die werden onderbroken door de beëindiging worden herhaald. De tabel TABA ingang moet bestaan op dit punt,maar de herstart uitvoeren maakt geen nieuwe Taba ingang. Als het veld TABA-XBUKZ een waarde heeft van “1”, Wat betekent dat de herstartmodus vereist is. Na het oplossen van de fout (en), zal het veld worden gewijzigd in “X” wat betekent dat het succesvol is gepost. Als TABA-XBUKZ een waarde van “N” heeft, moet het nog geplaatst worden.
Opmerking: Dit heeft alleen betrekking op de activa die niet succesvol zijn uitgevoerd in de vorige run.
Repeat
de repeat run wordt gebruikt om de posting run te herhalen binnen de periode die het laatst is geplaatst. Repeat zou worden gebruikt als wijzigingen zijn aangebracht nadat de periode afschrijvingsperiode is gepost.
bijvoorbeeld, laten we zeggen afschrijvingsvoorwaarden (bijv. een nuttige levensduur van een actief) worden gewijzigd in de stamgegevens van het actief of nieuwe transacties die worden geplaatst (voor bijvoorbeeld overdracht van activa). Daarom moeten de wijzigingen in de huidige periode worden afgeschreven. Het systeem herberekent de afschrijving voor de periode, trekt de afschrijving reeds geplaatst, en dan posten alleen het verschil. Dit kan worden beperkt tot specifieke activa die kunnen worden vermeld onder parameters voor Test Run of voor alle activa in het wetboek van vennootschappen. Daarnaast kan de Repeat posting run worden gebruikt als extra activa werden afgewikkeld nadat de geplande posting run was voltooid. Een voorbeeld zou zijn allocatie werd uitgevoerd waardoor extra activa worden gecreëerd. Een herhaling kan dan worden verwerkt voor alleen die specifieke activanummers of een enkel actief.
opmerking: tijdens een herhaling posting run, het systeem plaatst alleen de verschillen die resulteerden tussen de eerste posting run en de herhaling posting run met andere woorden geen dubbele posting of overschrijven van bestaande posting.
ongeplande posten Run
de ongeplande posten run maakt posten buiten de normale verwerkingscyclus mogelijk (bijvoorbeeld maandelijks). Deze optie is niet hetzelfde als ongeplande afschrijving. Meerdere periodes kunnen worden geplaatst in een enkele run met deze optie. Door deze indicator in te stellen, controleert het systeem niet op de verbinding met de vorige periode en maakt het overslaan van perioden mogelijk. Dit kan een nuttige optie zijn voor testdoeleinden voor het schatten of valideren van een afschrijvingsberekening, maar over het algemeen wordt deze optie niet aanbevolen.