Life, SAP, Consulting, Programming, Coding, ASP.NET, Sharepoint, MVC, Javascript, PHP, WebDesign, CSS, HTML

Archive for the ‘SAP’ Category

DMEE Aggregation field

How to create a aggregation field in DME file?


Follow the settings like below (Sample template: LUX_VIR2000)


Setup Sort fields: Sum by Vendor level + Value date in DME file.




1 segment contains lower level (2) data for aggregation field


Technical Field with Reference ID (N_P_VLUE)



Target field mapping is Aggregation, setup to N_PVLUE node.


Result (to test alternative payee with one payment in DME file):


Finally we have DME result:



Yet another definition of SAP

Choosing between structured and unstructured mt940

Working with MT940, SAP (FF_5) support 3 option when uploading file.

  • G – MT940 automatic recognized
  • S – MT940 with filed 86 structured
  • I – MT940 with field 86 unstructured

So what is difference between structured and unstructured MT940?






MT 940 Customer Statement Message


N or F + 3 SWIFT standard code

N or F + 3 SWIFT standard code


Field code Alphanumeric 4 :86: Batch ID Alphanumeric 35 /PREF/

End-to-End reference Alphanumeric 35 /EREF/

Counterparty Name Alphanumeric 70 /BENM//NAME/

Creditor ID Alphanumeric 70 /CSID/

End-to-End reference Alphanumeric 35 /EREF/

Settlement Date Alphanumeric 10 /ISDT/

Mandate Reference Alphanumeric 35 /MARF/

Counterparty Name Alphanumeric 70 /ORDP//NAME/

Counterparty Identification Alphanumeric /ORDP//ID/

Format Description SWIFT MT940 21

Remittance Information Alphanumeric 140 /REMI/

In case of unstructured remittance information, which don’t contain any subfields and in particular no slashes.

Creditor Reference Type Code Alphanumeric 4 /REMI//CD/

Remittance information. All available transaction descriptions


Structured information in field 86

All in one


Less space

More space => Longer notes


Looking at these format as SAP perspective, I would prefer structured format. With more details, I am easier to deal with complicated requirement from customer. I can combine with Search string to look up specific information, update posting rule, or make necessary replacement of data.

Comparing to Multicash format, I don’t see the same benefit. If I use Unstructured format, then there is not much benefit comparing to multicash format.

SAP DME file missing record

If you are working with SAP DMEE, for some payment run some instruction records are missing any you don’t know why.

You have 2 items in payment proposal with same information, bank, and payment method.

But only one record is sent out to bank.


If you encounter the same issue. Firstly you need to check the sorting/key field setting DMEE file.

Here is setting in my system

FPAYH-HKTID ==> ID for Account Details

FPAYHX-WAERS ==> ISO currency code

FPAYH-KOINH ==> Account Holder Name

FPAYHX-UBKNT ==> Our Account Number at the Bank

FPAYH-ZBNKN ==> Bank Account Number of the Payee

So if you pay to the same vendor in one payment run, the key field will be duplicate so it would be one record remained.

The fix for this? I don’t have access to test, however, it may be okay if you add sequential number of each item:

FPAYH-LFDNR Sequential Payment Number

If you have tested it, please let me know if comment section :-). Pls!

How to display vendor name on the header of FBL1N

The standard report vendor/customer open items in SAP support to display additional information.

By default, you can switch between ALV list and Basic list. ALV is more excel oriented, which you can easily extract and work within Excel. Basic list give some additional information, this layout is convenient for print out. Sometimes, instead of what you need, you see basic list just give asterisk symbols.

No vendor name


The secret setting is to change the sort field and control break (Don’t forget this *):

Change sort order

You can add more field for sorting, but remember to keep “Company code” and “Account” at highest level.

After click “Copy” button, you’ll get what you need. Of course, the same step can be applied for customer line item report.

K_PCAR_REP Summary and line item reports

Thanks to the article on SCN, it saved my day!

This technique is to assign authorization for user at in Profit center accounting at company code level.

K_PCAR_REP Summary and line item reports


This authorization object lets you protect the following in Profit Center Accounting:

1. Company codes, profit centers and cost elements in the information system.
2. The functions for creating, changing and displaying profit centers
3. In actual postings, the functions for creating and displaying profit center documents and statistical key figures.

Defined Fields

The object contains the following fields:

  • Company code: Specifies which company codes the user can work with.
  • Profit center: Specifies which profit centers the user can work with. Here you enter the key for the profit center.
  • Cost element: Specifies which cost elements a user can work with. Here you enter the key for the cost element.
  • Activity: Specifies which functions the user is authorized to carry out.
  • Reporting summary records (activity = 27)
  • Reporting line items (activity = 28)
  • Display saved data (activity = 29)
  • Create document (activity = 76)
  • Display document (activity = 03)

In master data maintenance, only the fields “Profit center” and “Activity” (01 = Create, 02 = Change and 03 = Display) are checked.


User A has authorization to report on profit center 4711 in company code 0100, but only for monthly values, not line items. Authorizations:

  • Company code ‘0100’
  • Profit center ‘0000004711’
  • Cost element ‘*’
  • Activity ’27

User B has authorization to call up reports on all the profit centers for the cost elements in group 5 in company code 0400 (including line items):

  • Company code ‘0400’
  • Profit center ‘*’
  • Cost element ‘00005*’
  • Activity ‘27,28’

User C can report on all profit centers and cost elements in company code TEST:

  • Company code ‘TEST’
  • Profit center ‘*’
  • Cost element ‘*’
  • Activity ‘*’

User D has authorization to call up reports for all previously selected and saved data on profit centers and cost elements in company code 0500:

  • Company code ‘0500’
  • Profit center ‘0000004711’
  • Cost element ‘*’
  • Activity ’29’

Performance comparison between periodic reposting, assessment, and distribution

Overview allocation method

Check whether assessment can be used instead of periodic reposting, as this leads to considerably better system performance.

  • You can use assessment if the origin of the primary costs is not important. If required, you can use multiple assessment cost elements for differentiation.
  • Periodic reposting is recommended if the origin of primary costs is important, but the partner object does not need to be displayed directly. The partner information, however, is not lost. Proof of origin is always possible via the line item document.
  • If you do need to show the partner object directly in the report, you must use distribution. The data volume will grow significantly for the proof of the partner objects, particularly in large distributions.

Note that the data volume generated for past periods will grow with increased numbers of periods. Especially in reporting and for data backups, it is important to keep the data volume generated by allocation to a minimum. For this reason, assessment or periodic reposting are to be recommended.

For performance reasons, you should not use more than 50 segments in one cycle. If necessary, define multiple cycles. A larger number of segments per cycle is only necessary for extensive iterations.

Also: For performance reasons, never use more than 10,000 relationships in an allocation cycle. If you require more than that, you must plan a mass test of the allocations beforehand.


From a sender cost center with 100 sender cost elements, allocations are made with one segment to 500 receiver cost centers.

The following numbers of sender and receiver totals records result from the different allocations that must be written in the processed period:

Allocation                 Sender totals recds     Receiver totals recds


Assessment                 500                     500
Periodic reposting         100                     500 x 100
Distribution              500 x 100               500 x 100


This simple example already demonstrates that

  • far more sender totals records are written for distribution than for periodic reposting
  • far more receiver totals records are written for periodic reposting than for assessment

In practice, because of the far higher number of senders and receivers, the advantages of assessment and periodic posting are even more apparent.

Overview allocation method