DATE_CONVERT_TO_FACTORYDATE — Convert Calendar Date to Factory Workday Sequence

DATE_CONVERT_TO_FACTORYDATE converts an ordinary calendar date into a factory date: a sequential workday index expressed against a specific factory calendar, the calendar object used across PP, PM, MM and QM to describe which days a plant, work center or planning object actually works on. The output is not a calendar date in the everyday sense; it is a running count of working days that lets other logic add or subtract whole numbers of workdays without stepping through weekends and holidays by hand. It sits in the general calendar function group underneath scheduling logic rather than being exposed as a supported application API. It is not formally released for customer use in the sense of a guaranteed stable interface; most usages found in customer code are the result of a developer tracing standard scheduling logic and reusing the same low-level call rather than a deliberate design choice.

The interface is short: one date in, one factory date out, plus the calendar key and a flag that decides how a non-working input date is handled. Only the input date field is safe to assume by name; the calendar key and correction indicator naming should be confirmed against the actual released interface before being hardcoded into new code.

Each exception here is a signal that either the calendar master data or the input is wrong, not that the function module is unreliable. Discarding any of them turns a hard, visible failure into a soft, invisible scheduling error that surfaces much later, usually as a wrong production, maintenance or delivery date.

Call it with every relevant exception listed explicitly rather than a blanket OTHERS, and check sy-subrc immediately afterward; do not use FACTORYDATE if sy-subrc is non-zero. Resolve the factory calendar ID from the actual master data of the object being scheduled, the plant, the work center or the assigned planning calendar, and never hardcode a calendar key, because a hardcoded key that happens to match the development system's default calendar will silently point at the wrong calendar, or none at all, once the program runs in a different client or company code. On failure, log the calendar ID and the input date together so calendar maintenance can be checked; the fix is almost always in the calendar's generated range or its assignment, not in the calling code.

The factory calendar mechanism itself has not been re-architected for S/4HANA, so this function module continues to work unchanged where existing code still calls it; there is no simplification-list retirement and no newer released successor. It is not a clean-core-friendly building block, being a basis utility rather than a public API, so new S/4HANA extensions should avoid calling it directly and instead rely on the scheduling logic already exposed by the relevant application, which resolves the correct calendar and performs the conversion internally. Where a direct call cannot be avoided, wrapping it in a local function isolates the risk if the low-level interface ever changes.

Most real incidents are master-data or misuse problems dressed up as function module bugs.

Correct behavior depends on two separate owners. Whoever maintains factory calendar customizing, the calendar definitions, holiday assignment and the generated year range, owns the master data; most exception tickets trace back to a calendar that was never extended into the current year or never assigned to the plant or work center in question. The ABAP developer who wrote the calling code owns correct exception handling and correct resolution of which calendar ID to pass. When this function module misbehaves in production, check calendar maintenance before assuming a code defect.

The factory calendar itself is maintained through factory calendar customizing and stored in the calendar definition table and its associated day-detail table, commonly referred to as TFACS and TFACD, though these names should be verified before being hardcoded into technical documentation. Application areas depending on factory-date arithmetic include production order and routing scheduling in PP, maintenance order scheduling in PM, and lead-time calculations in MM and QM. The reverse conversion, from a factory date back to a normal calendar date, is handled by a separate function module in the same function group and is needed anywhere a factory date has to be shown to a user.