Sorun Cevaplayalım

İşinizle ilgili öngörüler edinin, gerçek zamanlı bilgilere göre karar alın.

SAP Eğitim ve Sertifika Dönemleri

Uzmanlığınızı ve deneyiminizi SAP çözümleri kullanarak tasdik edin.

Çözüm Ekibi Başvurusu

Kullanıcılara hızlı ve pratik çözümler üreterek görev almak isteyenler.

SAP BLOG Note to payee functionality in SAP – part 2

SAP Blog

Kayıtlı Üye
Katılım
22 Ara 2017
Mesajlar
1,046
Tepki puanı
6
Hello SAPers!

Here is second part of the post on note to payee functionality in SAP. The first part was published a bit earlier and covered customizing setup for note to payee as well as one of the approaches to generation of note to payee details namely custom development using functional module. This post covers customizing approach to generation of note to payee.

1.1. Introduction


As mentioned above, there are two approaches to create note to payee in SAP – via customizing or using custom FM. Some of the settings are the same regardless the approach e.g. you should define technical requisites of note to payee in t-code OBPM1, create definition of note to payee in OBPM2, assign it to payment method in FBZP, build DMEE-tree etc. Most of these basic settings are described in my previous post. This blog will cover two areas which differ – definition of note to payee and customizing of DMEE-tree.

1.2. Create note to payee


Launch t-code OBPM2 and create note to payee by indicating its name and description. Activate checkbox “Note to payee layout using customizing” as a controlling option.

05_note_to_payee_cust.jpg


Save the entry and navigate to “Default Note to Payee” tab to define the structure of note to payee information.

06_note_definition.jpg


Indicate note to payee type 1 and number of line item. The type of note to payee in OBPM2 should be the same as defined in technical attributes in t-code OBPM1. Indicate the reference to the variables which will be used to generate note to payee text. Note to payee can include:
– references to system variables (e.g. FPAYP-XBLNR);
– fixed text constants (e.g. “Invoice #:” etc.);
– controlling parameters (e.g. X, Z, R, S etc.) to impact the formatting of the values.
System variables include fields from the same structures FPAYP, FPAYH, FPAYHX that are used in DMEE as mapping options. To get an overview of all values, select the field “Note to payee text” and press F4 to retrieve search help:

07_search_help.jpg


As you can see, search help is divided into two parts – each of them is referencing the same structures, but the first one contains primarily business information (name of the vendor, invoice number etc.), whereas the second one contains fields of technical nature (sorting / grouping fields, sequential payment number etc.). Select the field you need (1) and press “Copy” (2) button to insert it into note to payee definition.
If note to payee is to be used for payments to vendors from several countries, you can define language-dependent note-to-payee. Technically speaking, configuration is the same, but you can translate fixed text elements into different languages (see example below).

08_language_dependent_note.jpg


Selection of note to payee depends on the language of payee (i.e. payment recipient). Note to payee maintained in language of payee has higher priority over default note to payee.
SAPscript formatting options can be used to format output of values for example:

&VARIABLE+4(X)& – Offset and take X number of characters (e.g. &FPAYH-DOC1R+4(10)&)
&VARIABLE(X)& – Display only X characters of variable value;
&VARIABLE(C)& – Condense variable value (i.e. remove empty spaces e.g);
&VARIABLE(Z)& – Remove leading zeros (e.g. &FPAYP-ZBLNR(Z)&);
&VARIABLE(.2)& – Indicate number of decimal places to be displayed;
&VARIABLE(I)& – Do not display initial value;
&VARIABLE(R)& – Right-justified display;
&VARIABLE(S)& – Remove leading sign.

1.3. Configure DMEE tree


Configuration of DMEE tree for note to payee involves creation of quite many technical nodes. To begin with create a composite node to group together 10 technical nodes which will store 10 references to vendor invoice number. The length of each node should 16 characters i.e. the same as for field BKPF-XBLNR, which stores vendor invoice number in accounting document.
These technical nodes will not be displayed in payment file but will be used as a source of data by other fields in DMEE tree. Each node contains reference ID (INV_X) which will be used by other nodes.

09_DMEE_composite_node.jpg


Each technical node uses structure field DMEE_PAYD-TEXT as a mapping option. Key field 1 in the settings of source field indicates type of note to payee. 10 consecutive references to the structure DMEE_PAYD ensure that the system will retrieve first 10 values from table DFPAYHT.

10_DMEE_source.jpg


Note to payee is split into four parts i.e. segments due to layout requirements from the bank. The length of each segment is 35 characters. Thus, each segment can contain 2 maximal 3 references to vendor invoice number. Each segment uses own mapping as a mapping procedure which basically concatenates the values of all child atoms into value without spaces.
First segment contains atom “note_beginning” that contains constant value “Inv.:” that will be displayed once at the beginning of note to payee.

11_DMEE_oveview.jpg


Each atom with name “line_x” will contain a reference to vendor invoice number. Mapping option “Reference to tree node” will be used to get values from technical nodes at the beginning of DMEE-tree (i.e. atom line_x will use Reference Node ID INV_X).

12_DMEE_line_item.jpg


Each “delimiter” atom has a constant value “,”. To make sure that comma is not displayed unnecessary condition is set up for each delimiter. The condition checks whether a next line with vendor invoice number is not empty. Delimiter will be displayed only if next line is not empty.

13_DMEE_delimiter_condition.jpg


That’s basically all you need to configure to generate note to payee in necessary format. The only advantage of this approach (at least for this requirement) is that you can do without any development efforts at all. Disadvantages are obvious: you’re limited to display of X invoice numbers only and you must do a lot of technical setup, which is not straightforward and might be difficult to support. Development approach i.e. via custom FM would be much more efficient and easier at least in my humble opinion.

Hope this post was useful and you found something of value. Please comment and let me know if you have any questions or suggestions. Please also check out other posts on this and related topics.



Regards,

Bohdan Petrushchak

Okumaya devam et...
 
Moderatörün son düzenlenenleri:
Üst