Integration Transaction

A financial transaction that is generated through LN packages other than Financials. For each logistic transaction that must be reflected in Financials, LN generates an integration transaction, for example, Purchase/Receipt, Production/WIP Transfer, and Project/Costs of Goods Sold. LN posts the integration transaction to the ledger accounts and dimensions defined in the integration mapping scheme.

Inventory Transaction ID

The ID code generated for the current inventory transaction. Every transaction in LN will have an Inventory Transaction ID associated with it.

Search for the ‘Inventory Transaction ID’ in Financials -> General Ledger-> Integration Transactions-> Integration Transactions (tfgld4582m000) to get the “Integration Document Type” for the ‘Inventory Transaction ID’ under consideration.

For Example, In session “Inventory Receipt Transactions- whina1512m000” you can find the ‘Inventory Transaction ID’ generated during receipt of the Purchase Order. And then open “Inventory Integration Transactions- whina1524m000” to search for the “Integration Transaction” and “Integration Document Type” for the ‘Inventory Transaction ID’ under consideration.

Financials -> Integration Transactions-> Integration Document Type (tfgld4557m000)

It’s a combination of <origin> & <Transaction>.

Eg. 10014052 - Production Order/ Issue

Represents a type of Operations Management transaction for the purpose of mapping and posting the integration transactions to Financials and for financial reconciliation.

The integration document types supplied by LN each have the corresponding business object attached to them. For example, the integration document types for the various sales order transactions have Sales Order business Object linked to them. The business object represents the transaction origin of the integration document type.

Specific option -> Elements by Integration Document Type (tfgld4558m000) can be used to view the available mapping elements for an integration document type. The Debit Ledger Mapping Applicable and the Credit Ledger Mapping Applicable check boxes indicate whether the mapping element can be used for debit mapping or credit mapping. Element that determines which ledger account will be debited/credited.

Financials -> Integration Transactions-> Mapping Scheme (tfgld4573m000)

Use this session to view, enter and maintain the details of a mapping scheme version. Only one mapping scheme version can be Active at a time.

Integration Mapping Scheme, can be defined as a scheme that defines the ledger accounts and dimensions to which the integration transactions are posted.

Specific option -> Mapping by Element Group (tfgld4667m000)

Use this session to maintain ledger mappings and dimension mappings by element group. Depending on how you started the current session, this session's sole tab shows data from either of these sessions: Dimension Mapping (tfgld4571m000) or Ledger Mapping (tfgld4569m000)

You can define condition based on which LN will decide which Ledger Account should be debited or credited. E.g. Based on Warehouse in which Adjustment is done, debit/credit a different Ledger.

There are 4 sub-sessions to this session:

1.     Mapping Scheme Details- Detailed mapping of IDT to a ledger based on Element.

E.g. Based on Warehouse we can split the entries to different ledger on IDT say “Production Order/Issue”.

2.     Document Numbering/Compression- IDT to Transaction Type mapping is done here. Only Journal Voucher transaction types can be selected at this level. 1 Transaction type can be linked to all the IDTs. But if that is done then tracking the document number to IDT relation will become difficult.

3.     Default Accounts- Simple mapping between IDT to Ledger is specified here.  

4.     Errors and Warnings- Errors and warnings can be seen here. These are generated when we do “Check Mapping Scheme”.

Receipt Tolerance Quantity in Infor LN

Following set up can be done to allow user receive partially but to restrict user from receiving more than the Purchase Order Qty:

1.       In “Items-Purchase Defaults” do the following setup-

Qty. Tolerance (-) = 100%

Qty.Tolerance(+) = 0.00%

Hard Stop on Quantity = Block

2.       In “Items-Purchase Data” do the following set up-

Qty. Tolerance (-) = 100%

Qty.Tolerance(+) = 0.00%

Hard Stop on Quantity = Block

3.       For the Items whose Purchase Order is in progress, search for all the Inbound Lines and set ‘Hard Stop on Quantity’ field to “Blocked”

4.       For the Header of the Inbound Line set “Minimum Quantity Tolerance” to 100.00% and set “Maximum Quantity Tolerance” to 0.00%.

This change can be done till you didn't Confirm the Warehouse Receipt of the Purchase Order.

5.       For Items who don't have “Release to Warehouse” as one of the activities, we need not modify any data at the Warehousing level. Modifying at the “Items-Purchase Data” level is enough.

Extra Information:

- Similar fields are present to handle Over Delivery of a Sales Oder. Refer to “Item Sales Defaults”, “Items-Sales Data” and  “Outbound Lines” sessions that will handle this.

- For Sales Return where “Outbound Lines” is not created, system will consider “Inbound Lines “ fields but this time these fields will be controlled by ‘Items-Sales Data’.
- Item - General Defaults (tcibd0102s000)- If you define an item of this type and item group in the Items - General (tcibd0501m000) session, LN enters the default data in the fields of the Item - General (tcibd0101s000) details session. You can then use the default values or change the values as required.

Transaction handling in ERP LN/BAAN

Example 1:

Consider running the below 2 3GLs concurrently,

1.       otdsndtestdb

2.       otdsndtestdb2

Imagine db.update of both the 3GL is executed  and we kept  break point at the commit transaction statement of both.

Now we first execute the commit.transaction() statement of first 3GL.

And then when we execute the commit.transaction of 2^nd 3GL the cursor is taken to the db.retry.point() and then again the new values of record is read and is updated and then committed thereafter.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 Example 2:

  

Doing db.update on the same record twice for the same record selected with “for update” clause is ok.

But once you commit the changes inside the select for update on a record you cannot do db.update() on the same record. See the below example, where the system will fail in the second db.update statement. That's because the “for update” delayed lock mechanism will release the delayed lock on the current record inside selectdo once we do commit. Thus the next db.update will  fail.

Again, having multiple commits inside a selectdo is fine. Below code will work:-

Startup Session for a LN user

Suppose we want to open a particular session every time a user logs in....

We need to follow the below steps-

1. Create a session group in ttaad2107m000 (Session Group).

2. In session ttaad2106m000 (Startup Sessions) add the session that should start automatically.

3. Link the Session Group that you created in ttaad2105m000 (User Settings)