There's this thing about WRITE that requires something in writing. Just to explain, just to clarify. The WRITE statement is a trigger to an output type that makes it - one of it's kind. Want to know why and how ? Read on.
Business Application Programming in it's original form had to support some sort of reporting. It's the very first sign of life of the ABAP programming language. "Hello world", often used for new programmers in the first program (in any language) is a very suitable bit of output for the WRITE statement. The Dynpro or Dynamic Program was added as well, which was more about screen processing - but this article is about WRITE.
How does the one statement make such a big difference ? The first write starts a "list output" sequence. Add as many WRITE's you like, utilize the suite of output options and in the end the report is output. Actual output is produced as one whole, after the system detected the last WRITE has completed. There are a few other statements that have a very similar effect on list control, being SKIP or ULINE. There are also quite a few events surrounding list processing (report writing) such as TOP-OF-PAGE and END-OF-PAGE or AT LINE-SELECTION. The REPORT statement itself also has control parameters for list processing, LINE-COUNT and LINE-SIZE define the size of a report page and even the number of lines that are to be reserved for the header and footer of the report can be defined. A lot of this suggests printable output, which is of course something a lot of attention went into writing reports.
With the ALV report alternative - should WRITE reports still be used ?
The potential for ALV reporting is great and should be utilized. When users are expected use the report with some frequency (more than once or twice a week) you should give him an ALV report. The output of ALV's can be customized, is commonly used, widely understood and has great export options. So are there any reasons not to use ALV ? Sure: for small reports it is harder to set up, when the required output should support different sets of fields per line to be output, ALV can't do it and if it is output from a background job, even ALV is transformed into classing report output.
Classic reports vs ALV
Further more, comparing ALV and classic reports, both support colors, double clicks, single clicks, icons, checkboxes, refreshing, printing and export (download). From a technical viewpoint there is only 1 reason I've come across why WRITE should no longer be used. Software like Jaws can present the content of a screen to the visualy impaired. Blind users can use the system, as Jaws describes in wording what is on the screen. This works and it works fantastically well - but not for reports that were written with the WRITE statement. So far I've only come across IBM as customer - that aim at getting their system Jaws compliant (CI162).
The WRITE statement is going out of fashion a bit - but it's also still a useful option to the system. It has earned it's stripes and it can still answer requirements today.
Classic reporting into a field
And even if classic reports are used less and less often, the actual WRITE statement also supports a load of formatting options. Format your number (DECIMALS, EXPONENT) date DD/MM/YYYY or format USING EDIT MASK '__:__:__', use RIGHT-JUSTIFIED, LEFT-JUSTIFIED or CENTERED and by all means the options listed here are not the complete list. These are formatting options to compose you report, BUT they can also be used to format fields for something else entirely, when using the INTO option.
WRITE: my_date DD/MM/YYYY INTO my_formatted_date. WRITE: sy-uzeit USING EDIT MASK '__:__:__' INTO my_formatted_time.