Let me guess: there is a new legal requirement and you would need to have more characters to handle references for MM invoices in the XBLNR field.

And let me guess again: It’s a requirement from China, correct?

Maybe the second guess was incorrect, but the content here applies to many different scenarios as well.

And maybe the first guess was incorrect too. If you don’t have a legal requirement, but you’re just curious about the content, you may find something curious about SIM cards in this blog post.

If you really have that requirement, let me tell you that you are not alone.
As a Support Expert, I’ve been taking over many cases from customers that had the same question as yours in the last months. And I’m here to give you a brief explanation about the invoice reference field (and about SIM cards too).

For a short answer, you can check KBA 2580037 – MIRO/MIR7: Extended lengths for INVFO-XBLNR.

You can also stay in this post and discover a curious fact about SIM cards:

A curious fact about SIM cards

Did you know that many of them can handle only 16 characters for the contact names you store in them?

And that’s a good example to illustrate what’s happening here.

You may ask: “Well, I have lots of contacts with long names and never had to shorten their names when adding them as my contacts”. It is possible to do so, however you are probably storing your phone contacts on a cloud service, for example.

But now suppose that you are buying a new smartphone from a different brand. You’d like to transfer the contacts to the new phone, but your contacts are saved under the cloud service for brand A, which can’t be accessed by the cloud service for brand B. As a quick workaround, you decide to transfer the contacts to your SIM card, then transfer them to the other cloud service once the SIM card is inserted into the new phone. Simple, right?

Well, no. As your SIM card can only handle 16 characters for phone contacts, you’d have to shorten many contact names if you’d like to keep that approach to transfer contacts.

Okay, that workaround would actually take some minutes. Not a big problem. But let’s check XBLNR field again and discuss the impacts if the character limit were extended to 20 or 25 characters.

What if XBLNR field were simply extended?

Basically, lots of database tables, lots of programs and also lots of custom programs rely on the 16-character limit when they are reading invoice data. If XBLNR field were simply extended, it could break many functionalities in an unexpected way, causing potential system errors and database inconsistencies.

It would be a high-risk approach to perform that change, as many SAP systems around the globe could be affected.

This is why, from a software-design perspective, it is much better to keep the 16-character limit (as it has been defined since the beginning).

How to handle more characters?

Well, the requirement still persists. This is why, to handle it, SAP suggests that you use the Text field (SGTXT) to store more characters for your invoice reference.

To handle invoice control for that reference (e.g. suplicate invoice check) when using a different field, you can use BAdI MRM_HEADER_CHECK (you can find a brief explanation about it in SAP note 1156325) and implement your own logic to verify the invoice header.

Conclusion

Software design is not an easy process, and all elements (such as input fields) are conceived in such a way that many requirements can be fulfilled. However, those requirements may change throughout time and, many times, the system can be adapted for those new requirements. But, sometimes, even a simple adaptation like a character-limit increase is not feasible, and the safest path is to use a workaround.

If you have that specific requirement and you were stuck,
I hope that the information clarifies, goodbye and good luck.