defective quantity on api API_QUALITYNOTIFICATION

[#1]

Hello, 

I need to add defective quantity via API_QUALITYNOTIFICATION on header part and not on item part, but i am not able to find any field related to this field.

For information, i also check Maintenance Notification API, no solution too...

If someone can help me related to this, please 🙂 ?

[AlexandrePassarelli]

You are right, there is no such field on the header. I checked on an S/4HANA 2023 system: the header entity of API_QUALITYNOTIFICATION has no quantity field at all, and the defective quantities exist only on the item.

What I measured

• The header entity QualityNotification is the CDS view A_QltyNotification, a projection on R_QltyNotificationTP. It has type, texts, codes, dates, supplier, customer, material, plant, purchasing data, inspection lot, batch and material document, and no quantity.
• The business object under it already knows two header quantities: its behavior maps NotificationComplaintQuantity to QMEL-RKMNG and NotificationExternalQty to QMEL-MGFRD (Defective Quantity (External)). The internal one, QMEL-MGEIG, is not even in that view. The API projection exposes none of them.
• A_QltyNotification is released only for remote use (C2). The extension contract (C0) is not released and the projection behavior is not marked extensible, so you cannot add the standard field to the API with developer extensibility.
• The header behavior only allows create, no update, so this API cannot change header fields of an existing notification anyway.
• The item entity QualityNotificationItem has ExternalDefectiveQuantity (QMFE-FMGFRD) and InternalDefectiveQuantity (QMFE-FMGEIG). DefectiveQuantityUnit is read only.

I also ran it: I created a Q2 notification through the API business object (EML on A_QltyNotification, no commit, rolled back) with one item with ExternalDefectiveQuantity 3 and InternalDefectiveQuantity 1. FAILED was empty, REPORTED returned no texts, and reading the item back gave 3 and 1. The unit came back empty: it is read only, and I did not test when it gets filled.

What you can do

• Inside this API, the item is the only place for a defective quantity.
• On premise or private cloud, if it must be the header: QMEL-MGFRD and QMEL-MGEIG are in the header structure RIQS5 of the RFC function module IQS4_CREATE_NOTIFICATION. I called it with I_POST = space, so nothing was saved. With the default I_CHECK_PARNR_COMP = 'X' it stopped with error IX 200 for partner functions KU (Coordinator) and LF (Supplier, VN on English screens), which are mandatory for Q2 in my system. With I_CHECK_PARNR_COMP = space the header came back with a temporary number, RKMNG 10, MGFRD 5 and MGEIG 2. In a real call, pass the partners in I_IHPA_T instead of switching the check off.
• This function module is not a released API, so it is for classic ABAP or RFC only. BAPI_QUALNOT_CREATE does not help here: its header (BAPI2078_NOTHDRI) has QUANT_COMPLAINT for the complaint quantity, and no defective quantity.
• The field documentation says external plus internal must not exceed the complaint quantity. In my run the function module did not check that before save: 8 and 5 against a complaint quantity of 10 came back with no error. If you go this way, check it on your side.
• If you are on the public cloud, open the $metadata of your service and look at the QualityNotification entity: if it has no quantity property, it is the same situation, and the item is the way.

What I did not test: saving the notification in either path, passing the partners in I_IHPA_T, calling the OData service over HTTP, the maintenance notification API you mentioned, and releases after 2023 or the public cloud. The API fields, the mapping and the runs above are measured.