Break-points can also be hardcoded, as there is a statement BREAK-POINT in our abap vocabulary. Hardcoded break-points are client independent, which is a feature that makes them useful in systems where the development client and test client are separated. You can set the break-point in the coding you are editing, and the test run in the test client will invoke it.
The hard-coded break-point is not only client independant, it is also user independant. This makes it somewhat of a master break-point, which should be handled with care. Make your hardcoded break-point user specific by specifying the username: BREAK USR143. Always make sure your break points are removed from your coding once it is moved (transported). Search for "break" or simply check the code inspector (which is a good habbit anyway).
One thing to note on break-points, when a hardcoded break point gets transported to production system, all users will be halted at the break point. This should be prevented of course, but is also good to know that most users should not have debugging authorization, in which case the break-point is simply skipped.