The field you want is not on the record

The master record holds what every SAP system holds about a technical object: what it is called, where it is installed, which cost centre carries it. It has no field for a design pressure, a rated flow or a seal arrangement, because those are not facts about every object in every plant.

Those go on a class, as characteristics. Build the class, hang the characteristics on it, assign the object to the class, and the values are held against the object.

Where that is not done the attributes still get recorded, because the plant needs them: in the description line, in a long text, or in a spreadsheet somebody keeps. The description turns into a code nobody wrote down. The long text cannot be turned into a list. The spreadsheet is the second register.

A class belongs to one class type. Equipment is classified under class type 002, functional locations under 003, and a class built for one cannot be used on the other.

So place-or-thing is not decided when somebody enters a value. It is decided when the class is built, and once for every object that class will ever hold.

The test is the one that decides whether something is a functional location at all: would the value still be true after the machine standing there is carried out? The line size at a position outlives the pump. The pump's impeller diameter leaves with the pump.

That test reads like one attribute, one object. It is not. A position requires a duty. The machine installed in it has a rating. Those are two facts, on two objects, and the useful question is whether they still match.

Keep only the rating and you cannot say whether what is installed fits where it stands. Keep only the requirement and you cannot say what is actually there.

The same characteristic can be hung on both classes unless somebody has restricted it to one. Give them different names anyway. One number is what the position needs and the other is what the machine delivers, and one name over both is how the two get read as the same number.

A characteristic is typed. A numeric one can carry a unit of measure. A character one can carry a list of allowed values, and where it does not, it takes whatever is typed into it.

An untyped field looks finished. It has a name, it has values in it, and it counts as populated by anything that counts populated fields. But 10 bar and 10bar are two values, nothing sorts a text column by size, and a search for everything above a threshold cannot be written at all.

Whether an entry outside an allowed-value list is refused is a setting, not a property of the field. So a value list existing is not the same statement as only those values being in there. Worth checking on the characteristics you intend to report on.

Nothing makes anybody fill a characteristic in. Unless it was marked as required, the record saves with the field blank and the object is complete by every check that runs against it.

Which is why the gap is not found at go-live. Nobody searches a register by attribute on the day it is loaded. It is found the first time somebody needs a list — everything above a pressure, everything with that seal arrangement, everything in the same material as the one that just failed — and the answer comes back short rather than wrong. A short list reads as a small population, not as a column nobody filled in.

And blank carries two meanings that nothing tells apart: nobody entered it, and it does not apply to this object. Where that difference matters it has to be a value of its own, because there is nowhere else to put it.

A characteristic says what the object is now. Writing a new value over it leaves the current one and no series, so it cannot answer what the value was in March unless somebody logged the change.

Anything that moves is therefore not a characteristic. Running hours, a vibration level, a measured wall thickness: each is a reading, each is worth nothing without the date it was taken, and writing one into a characteristic overwrites the one before it.

A measuring point is where those belong. The point is assigned to the equipment or to the functional location; each measurement document carries a value and the date it was taken, so what you hold is a series and not a single number. A point that counts is also what a counter-based maintenance plan reads, which is the difference between a plan that follows the machine and one that follows the calendar.

• Which objects get classified at all. A class on an object is a promise that somebody will fill it in.
• Which class type each class is built under, which is place-or-thing under another name.
• Which characteristics are required. That is the only thing on this list that will make anybody fill one in.
• Which character characteristics have an allowed-value list, and whether anything outside it is accepted.
• The unit on every numeric one.
• Who may add a characteristic afterwards, and who fills it in for what is already loaded. A characteristic added later is blank on every object that was there before it, it does not populate itself, and nobody is looking at that column yet.