F150 — F150 Dunning Run Transaction

F150 runs the automatic dunning program against customer (or vendor) open items, comparing due dates and arrears against the dunning procedure stored on the account master to decide which items get dunned and at which dunning level. The structural fact that causes most confusion: it is not a single print action. It works exactly like the payment program in shape - a parameter set identified by a dunning run date plus an identification code, then a background proposal run, then an edit step, then a separate print run. Nothing gets printed until the proposal has been created and reviewed. Rerunning the same run date and identification without first deleting the existing proposal fails outright, which reads to a first-time user as a bug rather than the intended safeguard against duplicate dunning letters.

Used in accounts receivable collections cycles, typically run weekly or monthly, to identify customers behind on payment and produce dunning letters at escalating severity levels. Also used, less commonly, for vendor dunning where credit memos or debit balances need chasing. A consultant reaches for F150 whenever the business process requires formal, documented dunning correspondence tied to dunning levels and dunning areas, rather than an informal collections call logged elsewhere. It sits downstream of normal invoice posting and payment application - it only ever touches items that are still open in BSID/BSAD at the time of the run. Credit management and collections management tools may supplement it for softer follow-up, but the formal letter-generation step for standard dunning procedures is still F150.

In SE16, check MHNK for the run date and identification in question to confirm the run actually completed all three steps rather than stalling at proposal. Check MHND filtered on the same run date and ID to see which accounts and documents were selected, and their exception or status code if excluded. Cross-check a specific customer's open items in BSID against KNB5 for that customer and dunning area to confirm a dunning procedure is assigned and no dunning block is set - a blank dunning procedure field is the single most common reason an account never appears in the proposal at all.

F150 is unchanged in its core logic and step structure on S/4HANA; it remains a classic batch transaction built on the same proposal-edit-print sequence and the same underlying tables. There are Fiori apps for monitoring dunning activities and reviewing dunning history that sit on top of the same data, useful for a collections team that does not need transaction-level access, but they do not replace F150 for actually configuring or triggering the run. No structural rework has moved this into a simplified data model equivalent the way some FI postings were.

Functional FI-AR territory: dunning procedure configuration, account master dunning fields, and form assignment are all functional decisions. Basis gets involved when the proposal or print step is scheduled as a background job with spool or output device failures. A clean handover includes the run date and identification, the proposal log with any exception codes, and the specific account/document combination affected rather than a general 'dunning is not working' report.

FS00, FD10N and FK10N give the account master and balance context needed to confirm whether an account should have been dunned at all. FBL1N is the fastest way to inspect individual line items for dunning blocks, dunning level, and last-dunned date once F150's log points to a specific document. F110 is worth comparing directly since it shares the same run-date-plus-identification, proposal-edit-print structure, and understanding one shortens the learning curve on the other. FBRA is relevant when a wrongly cleared or wrongly open item needs to be corrected before rerunning the dunning proposal.