# IFS Applications 10 PL/SQL API Call Generator for New__ and Modify__

> Source: https://netray.co/tools/ifs-applications-10-plsql-api-call-generator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Generate anonymous PL/SQL blocks that create or update IFS Applications 9/10 records through the logical unit API (New__, Modify__) with Client_SYS attribute strings, the supported way.

## Category

other-erp

## Erp

IFS Applications

## Audience

- IFS developer
- IFS technical consultant
- ERP administrator

## Tool

**Kind:** template

**Output:** code

**Language:** sql

**Fields:**

#### Logical unit API package

**Key:** api_name

**Type:** text

**Default:** Customer_Order_API

**Help:** The <LU>_API package, e.g. Customer_Order_API, Purchase_Order_API, Inventory_Part_API.

#### Base view

**Key:** view_name

**Type:** text

**Default:** CUSTOMER_ORDER

**Help:** The LU view that exposes OBJID and OBJVERSION, used to fetch the keys for Modify__.

#### Key condition (Modify__)

**Key:** key_where

**Type:** text

**Default:** order_no = 'C12345'

#### Attribute 1 name

**Key:** attr1_name

**Type:** text

**Default:** CONTRACT

#### Attribute 1 value

**Key:** attr1_value

**Type:** text

**Default:** 1

#### Attribute 2 name

**Key:** attr2_name

**Type:** text

**Default:** CUSTOMER_NO

#### Attribute 2 value

**Key:** attr2_value

**Type:** text

**Default:** CUST100

#### Date attribute name

**Key:** attr3_name

**Type:** text

**Default:** WANTED_DELIVERY_DATE

#### Date attribute value (YYYY-MM-DD)

**Key:** attr3_value

**Type:** text

**Default:** 2026-11-30

#### Action

**Key:** action

**Type:** select

**Options:**

- CHECK
- DO

**Default:** CHECK

**Help:** CHECK validates without saving, DO validates and writes. Start with CHECK.

**Blocks:**

#### 1. Show the default attributes (PREPARE)

**Body:** SET SERVEROUTPUT ON

DECLARE
   info_       VARCHAR2(32000);
   objid_      VARCHAR2(2000);
   objversion_ VARCHAR2(2000);
   attr_       VARCHAR2(32000);
BEGIN
   Client_SYS.Clear_Attr(attr_);
   {{api_name}}.New__(info_, objid_, objversion_, attr_, 'PREPARE');
   -- attr_ now holds the default values the client would show on a new record.
   -- CHR(31) separates name from value, CHR(30) ends each item.
   Dbms_Output.Put_Line(REPLACE(REPLACE(attr_, CHR(31), ' = '), CHR(30), CHR(10)));
END;
/

#### 2. Create a record with New__

**Body:** DECLARE
   info_       VARCHAR2(32000);
   objid_      VARCHAR2(2000);
   objversion_ VARCHAR2(2000);
   attr_       VARCHAR2(32000);
BEGIN
   -- Start from the defaults, then add your values (a later item in attr_ overrides an earlier one).
   Client_SYS.Clear_Attr(attr_);
   {{api_name}}.New__(info_, objid_, objversion_, attr_, 'PREPARE');

   Client_SYS.Add_To_Attr('{{attr1_name}}', '{{attr1_value}}', attr_);
   Client_SYS.Add_To_Attr('{{attr2_name}}', '{{attr2_value}}', attr_);
   Client_SYS.Add_To_Attr('{{attr3_name}}', TO_DATE('{{attr3_value}}', 'YYYY-MM-DD'), attr_);

   {{api_name}}.New__(info_, objid_, objversion_, attr_, '{{action}}');

   Dbms_Output.Put_Line('info: ' || info_);
   Dbms_Output.Put_Line('objid: ' || objid_ || '  objversion: ' || objversion_);
   -- Returned attr_ carries generated keys (for example ORDER_NO):
   Dbms_Output.Put_Line(REPLACE(REPLACE(attr_, CHR(31), ' = '), CHR(30), CHR(10)));
   -- COMMIT;
END;
/

#### 3. Update a record with Modify__

**Body:** DECLARE
   info_       VARCHAR2(32000);
   objid_      VARCHAR2(2000);
   objversion_ VARCHAR2(2000);
   attr_       VARCHAR2(32000);
BEGIN
   SELECT objid, objversion
     INTO objid_, objversion_
     FROM {{view_name}}
    WHERE {{key_where}};

   Client_SYS.Clear_Attr(attr_);
   Client_SYS.Add_To_Attr('{{attr3_name}}', TO_DATE('{{attr3_value}}', 'YYYY-MM-DD'), attr_);

   {{api_name}}.Modify__(info_, objid_, objversion_, attr_, '{{action}}');

   Dbms_Output.Put_Line('info: ' || info_);
   Dbms_Output.Put_Line('new objversion: ' || objversion_);
   -- COMMIT;
END;
/

**Notes:** Run as an IFS end user that has been granted the API through permission sets, not as the IFSAPP owner writing directly, and never INSERT or UPDATE the *_TAB tables. Attribute values for enumerations are client values unless you use the _DB attribute variant; check which one the LU expects. Mandatory attributes differ by LU and by configuration, so run block 1 first and debug a manual entry in the client to see the real attribute list. Test in a non-production instance and keep COMMIT commented until CHECK passes.

## Content

**Intro:** This generator writes anonymous PL/SQL blocks that call an IFS Applications 9 or 10 logical unit API (New__ and Modify__) with a Client_SYS attribute string, the same path the client uses. Paste the output into the SQL Query Tool, IFS Developer Studio, SQL Developer or a custom event action to test a create or update without touching the tables directly.

**Sections:**

#### How to use it

**Body:** Enter the API package (for example Customer_Order_API), its base view, and up to three attributes. Block 1 calls New__ with the action PREPARE, which returns the default values the client would show on a blank record, and prints them one per line. Block 2 starts from those defaults, appends your values with Client_SYS.Add_To_Attr and calls New__ with CHECK or DO. Block 3 fetches OBJID and OBJVERSION from the view for one record and calls Modify__. Keep the action on CHECK until the block runs clean: CHECK runs the validations without writing, DO validates and writes. COMMIT is commented out on purpose so you can roll back while testing.

**Bullets:**

- Run block 1 first to see which attributes the LU fills by default
- Use CHECK, read info_, then switch to DO
- Uncomment COMMIT only in a test instance you are allowed to change

#### The method: attr_ strings and the five-parameter signature

**Body:** In IFS Applications every logical unit exposes New__ (info_, objid_, objversion_, attr_, action_) and Modify__ (info_, objid_, objversion_, attr_, action_). The attr_ string is a list of name and value pairs: CHR(31) separates a name from its value and CHR(30) ends each pair. Client_SYS.Clear_Attr empties it and Client_SYS.Add_To_Attr appends a pair, with overloads for text, numbers and dates, so a DATE goes in without string conversion. On return attr_ carries values the server set, such as a generated ORDER_NO. Modify__ needs the row's OBJID and current OBJVERSION; if someone changed the record after you read it, the call fails with a 'modified by another user' error instead of overwriting their change.

#### Worked example: customer order header

**Body:** With the defaults, block 2 prepares a Customer_Order_API record, adds CONTRACT = 1, CUSTOMER_NO = CUST100 and WANTED_DELIVERY_DATE = 2026-11-30, and runs CHECK. If info_ comes back empty and no error is raised, the header would be valid. Switching to DO creates it and the printed attr_ shows the new ORDER_NO. Block 3 then moves the wanted delivery date on order C12345 by changing only that one attribute: Modify__ ignores attributes you do not send. Real order headers often need more, for example an order type or coordinator, depending on site defaults, which block 1 reveals.

#### Gotchas in Apps 9 and 10

**Body:** Do not write to CUSTOMER_ORDER_TAB or any *_TAB table: you would skip the business logic, history and events. Enumeration attributes accept client values, which can be translated; the _DB variants (for example a STATE_DB style attribute where the LU offers it) are language independent. When you cannot work out an attribute name, turn on debug in the client while saving the record manually and read the attr_ that the client sends. Custom fields on an LU travel in a separate CF$_ structure through the custom fields API, not in the base attr_. On Apps 10 with Aurena the server logic is the same, so these blocks still apply.

**Cta:** If your team wants to ask IFS Applications questions in plain English on your own servers, with any write going through these APIs only after a person approves it, we can set that up.

**Faq:**

#### What is IFS Applications 10?

**Answer:** IFS Applications 10 is the on-premises ERP release from IFS that preceded IFS Cloud. It runs on an Oracle database with PL/SQL business logic organised in logical units, each with an _API package, and offers the Enterprise Explorer client and, from later updates, the Aurena web client. Code built on New__ and Modify__ works the same way in Apps 9 and 10.

#### What does PREPARE do in an IFS New__ call?

**Answer:** PREPARE asks the logical unit to fill attr_ with the default values for a new record, the same defaults the client shows when you press New. It does not insert anything. Use it to discover which attributes the LU fills automatically, then add your own values and call New__ again with CHECK or DO.

#### Why does my New__ call fail with a mandatory field error?

**Answer:** The LU validates every mandatory attribute during CHECK and DO. If you built attr_ from scratch with Clear_Attr you may be missing values the client normally defaults. Start from PREPARE as block 2 does, read the error text in the raised message, and add the missing attribute. Site and company settings can change which fields are required.

#### Can I use these blocks in a custom event action?

**Answer:** Yes, the same API calls work in an event action of type Execute Online SQL, but be careful: the action runs inside the triggering transaction, so do not COMMIT there, and avoid modifying the same LU that fired the event or you can loop. Test with CHECK first and keep the logic small.

## Search terms

ifs applications 10, ifs apps 10 documentation, ifs applications 9, ifs new__ modify__ example, ifs client_sys add_to_attr, ifs customer_order_api new__, ifs pl/sql api call, ifs applications test

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json