There are many times in building workflows when you realize you need not just one or two attributes of a related business document, but potentially, many more. Rather than adding each field as an attribute – and having to keep your business objects in sync, why not create a sub-object as an attribute?
Case in point: You are developing workflow for Invoices, and the approvers need to see many details of the related Purchase Order. You *could* code separate attributes to the invoice which individually retrieve and populate from the purchase order. But why? Suppose later in life, you add more attributes to Purchase Order? Do you need to then replicate that in the Invoice? By creating an attribute with an object reference, you can always access *all* the attributes of Purchase Order from the Invoice. It’s easy as pie!
You will need to copy BUS2081 to zBUS2081, and remember to perform the system-wide delegation. Any enhancements you want to make to the Invoice will be made against ZBUS2081.
Create an attribute for PurchaseOrder with the attributes below.
When you push ‘Program’ the system will pop up and ask you if you want to generate a template. Push ‘Yes’.
You will be brought into the ABAP editor. Your screen will look something like this:
Add code that looks like this:
get_property purchaseorder changing container.
DATA: key LIKE swotobjid-objkey,
po-number LIKE ekko-ebeln.
DATA subrc LIKE sy-subrc.
DATA date LIKE sy-datum.
DATA: invoice LIKE rbkp-belnr,
year LIKE rbkp-gjahr.
s_headerdata LIKE bapi_incinv_detail_header,
s_addressdata LIKE bapi_incinv_detail_addressdata,
tab_itemdata LIKE bapi_incinv_detail_item OCCURS 0,
tab_accountingdata LIKE bapi_incinv_detail_account OCCURS 0,
tab_glaccountdata LIKE bapi_incinv_detail_gl_account OCCURS 0,
tab_materialdata LIKE bapi_incinv_detail_material OCCURS 0,
tab_taxdata LIKE bapi_incinv_detail_tax OCCURS 0,
tab_withtaxdata LIKE bapi_incinv_detail_withtax OCCURS 0,
tab_vendorsplitdata LIKE bapi_incinv_detail_vendorsplit OCCURS 0,
tab_return LIKE bapiret2 OCCURS 0.
*The following code will depend on your actual rules for how to match an invoice to a Purchase order…For me it was sufficient to match it to the first line of the invoice.
CALL FUNCTION ‘BAPI_INCOMINGINVOICE_GETDETAIL’
invoicedocnumber = object-key-invoicedocnumber
fiscalyear = object-key-fiscalyear
headerdata = s_headerdata
addressdata = s_addressdata
itemdata = tab_itemdata
accountingdata = tab_accountingdata
glaccountdata = tab_glaccountdata
materialdata = tab_materialdata
taxdata = tab_taxdata
withtaxdata = tab_withtaxdata
vendoritemsplitdata = tab_vendorsplitdata
return = tab_return
OTHERS = 01.
WHEN 0. ” OK
WHEN OTHERS. ” to be implemented
po-number = tab_itemdata-po_number.
swc_set_element container ‘PurchaseOrdert’
Now, check, etc. Remember to set your attribute to Implemented before you generate the object, and use the test-bed from SWo1 to help ensure it’s working before you try using the attributes of Purchase Order from an Invoice workflow.
When you instantiate the invoice, you will also see the Purchase Order object. When using Invoice in your workflow, you will have immediate access in workflow task descriptions, etc, to the attributes of the accompanying Purchase Order.