I would like to know if it is possible via tables to link finance and logistical transactions.

For example in profit and loss account a sale is recorded under sales trade ledger acount (in table tfgld106). I would like to know how this is linked to the distibution tables to identify the order number/s and also the integration transactions which make up the sales, cost of the sales (operational, material, Surcharge), discounts ie for a particular transaction I would linke to know sales cost of sales.

I can get a report for this using tfgld4410m000. But I would like to know what tables are interfaced to obtain this information.

I hope this is not too confusing.

Thankyou for any help.

Hi Nazeem

Have you looked at tdsls6102m000 this is where the invoice detail accounts are maintained ie the Cost of Sales account this is setup based on the Customer Group which is how the the Sales order picks up the correct ledger accounts to post to.

I hope this helps.

Regards

Kam

Hi Nazeem,

The integration setup is what baan uses to decide where in the ledger the transactions from logistics will be posted. I am not sure which version of Baan you are working on but in Baan IV all the integration accoun setups are in General Ledger\Transaction Processing\Miscell.

As Kam mentioned tdsls6102m000 is where you will find the Material Costs, Operation Costs and Turnover account for Sales.

Hi Nazeem,

Table tfgld410 (integration transactions) contains the data links or “audit trail” between logistic transactions and finance transactions. The table has limited but key logistic data (including order number & order line) that will let you look up details from the order tables. The combination of Transaction Origin and Financial Transaction for each integration line will determine which specific logistic tables to look in (i.e., Purchase Orders, Sales Orders, Warehouse Orders, etc.).

Depending on the version of Baan, some (but not all) of the integration transaction credit lines will be stored in tfgld417 (integration credit transactions). A complete audit analysis of the integrations between logistics and finance would have to include gld417. However, gld417 only stores basic finance detail (ledger account & dimensions) for the credit lines. So you will still need to use gld410 to look up logistic details.

As Kam and Maria have pointed out, to determine/audit why specific account/dimension combinations, transaction types, etc. were posted to transaction lines in gld410 and gld417, you will have to refer to the basic integration set up in Finance (GLD, ACP and ACR), parameter settings (links to Finance) in the various modules, and sessions such as tdsls6102m000, tdsls6101m000, tdinv8150m000, tipcs8150m000 from the logistics modules.

The logistic data in gld410 is posted as soon as the logistic transaction is completed. Integration parameters and your procedures determine whether the Finance data is posted to gld410/417 at the same time or later.

Scott

Hi Scott,
I have a question about setting integration parameter, what's function of "compression" in integration parameter.

Thanks in advance!

I do not have session tdsls6102m000. Is this because I am using Baan V ?

Hi,

This session does not exist in Baan V. The session maintain Integration Mapping Scheme holds the information now. There is now a new integration transaction Sales Invoice/Cost of Goods Sold.

Thanks, Maria! My response was for Baan IV. I should have made that clear.

Scott

Carol,

The “Compression” field in Maintain Integration Parameters (tfgld4150m000) controls how integration transactions in gld410/417 are compressed (or grouped) into general ledger transactions (Transaction Type + Document No. + Line No.) when they are created via Post Integration Transactions to Finance Transactions.

The standard definitions are:
No Compression
In the general ledger the transactions will not be processed in compressed manner. This means that all transactions will be entered in the ledger specified by financial event.

Compr. by Trans Origin
In the general ledger the transactions will be processed compressed by transaction origin, e.g. a total of all purchase orders, a total of all sales orders, etc.

Compression
When entered in the general ledger, the transactions will be compressed. Therefore, for each processing a total amount will be entered per ledger account.

Remember that integration transactions in gld410 are indexed by combination of Transaction Origin / Financial Transaction and that they are also first grouped by Transaction Type as assigned in Maintain Transaction Types by Transaction Origin when posted to finance.

The number of Transaction Types that you use, and the frequency with which Post Integration Transactions to Finance Transactions is run, will limit the amount of compression that is actually achieved in gld102/106.

See the following discussions for more info on compression: http://www.baanboard.com/baanboard/showthread.php?threadid=755&highlight=compression
http://www.baanboard.com/baanboard/showthread.php?threadid=484&highlight=compression

Scott

Hello Scott,
Thanks a lot for your reply!
I have seen your explanation and the others, but I am still not clear, how to find the difference to use compression or not. I had set the parameter "compression by trans origin", from tfgld102/106 or other tables, could I find the effect?

Carol,

You asked about a test scenario that would let you see the effect of the three Compression settings in Integration Parameters. I think that the following procedure will give a fairly simple overview of the effects of the Compression setting in Maintain Integration Parameters.

Basic setup:
In Maintain Transaction Types by Transaction Origin, map Purchase/Receipt, Purchase/Result and Warehouse Order/Inventory Adjustment to the same Transaction Type (e.g., I01).

In Maintain Inventory and WIP Transaction Accounts, enter the following posting scheme:
· Purchase/Receipt Debit account: INV; Credit account: GRINYA
· Purchase/Result: Debit account: GRINYA; Credit account: RESULT
· Warehouse Order/Inventory Adjustment: Debit account: INV; Credit account: RESULT
(Don’t bother to specify by warehouse, item group, etc unless the existing setup in your test company will take priority over these defaults. The important thing for testing with a limited number of transactions is that the inventory account and the result account for the various transactions are the same. Also, try to keep the tests simple by avoiding location control and lot pricing, if possible.)

Enter 3 purchase orders, each for a different supplier and each for a different purchased item. On each PO, enter 3 lines for the item; ensure that the line item price will produce a favorable purchase result.

Scenario #1:
In Maintain Integration Parameters, make sure that Real Time to Finance = No and set Compression = Compression
· Receive goods against the first line of each PO.
· Enter at least 2 inventory adjustments for each item (both gains)
· Run Post Integration Transactions to Finance Transactions. (Set the selection criteria so that only your test transactions will be posted.)
Review the resulting non-finalized finance transactions for your batch. You should see one finance transaction (I01-nnnnnnn1), with one line per ledger account. (There may be 2 lines for GRINYA, depending on whether the transaction type allows negative amounts.) This is “maximum” compression, minimum detail in the ledger.

Scenario #2:
In Maintain Integration Parameters, reset Compression = Compr. by Trans Origin
· Receive goods against the second line of each PO.
· Enter at least 2 inventory adjustments for each item (both gains)
· Run Post Integration Transactions to Finance Transactions. (Set the selection criteria so that only your test transactions will be posted.)
Review the resulting finance transactions for your batch. You should now see one finance transaction (I01-nnnnnnn2) for all the Purchase transactions and one transaction (I01-nnnnnnn3) for all the warehouse orders.

Scenario #3:
In Maintain Integration Parameters, reset Compression = No Compression
· Receive goods against the third line of each PO.
· Enter at least 2 inventory adjustments for each item (both gains)
· Run Post Integration Transactions to Finance Transactions. (Set the selection criteria so that only your test transactions will be posted.)
Review the resulting finance transactions for your batch. You should you should now see a separate finance transaction for each finance event (each receipt, each inventory adjustment). This is maximum detail in the ledger.

Additional Tests
In Maintain Transaction Types by Transaction Origin, map Warehouse Order/Inventory Adjustment to a different Transaction Type (e.g., I02) and repeat the three scenarios. You should see the same number of transactions under both “Compression” and “Compr. by Transaction Origin” because the transaction type forces separate GLD transactions by transaction origin. You should see the same number of transactions as before under the scenario “No Compression”.

Set a different transaction type (say I03) for Purchase/Result and repeat the three scenarios. Under each parameter setting, you should see more finance transactions than previously because you have defined more than one transaction type for transaction origin Purchase.

Experiment to see how easy or difficult it is to drill down to logistic detail from the ledger inquiries or to print detail from the reports. Remember that the effects (plus and minus) are magnified greatly when you have 100s or 1000s of transactions posting in a batch.

I hope this is what you were looking for. It is a bit long for a post, but I was concerned that if I just attached it as a Word file, it might not trigger as many other suggestions/corrections.

Scott Johnson

Hello Scott,
Thanks again!
I have tested these scenarios for the parameter "compression", and I can find the difference from the session "print non-finalized transactions", "No Compression" transaction line will separate multi-line for the same finance event. It's great!
and another field "handling of document numbers", I defined "document no by trans/date", then for "compression" and "compression by trans", I test the two options, their document no would all separate by transaction type, compression for each transaction. So the two options will no difference, right?

Carol,

The setting “handling of document numbers” provides one more tool to help you to group transactions. Obviously, it works in combination with “Transaction Types by Transaction Origin” and the parameters “Transaction Real Time to Finance” and “compression”, but it only impacts the assignment of document numbers.

Because the actual effect of the combined settings is partially data dependent, changing only the setting of “handling of document numbers” may or may not give similar results. On your limited volume of test data, you probably wouldn’t see a difference.

Any differences are more apt to show up with higher volumes of transactions, especially when the same Transaction Type is used for multiple transaction origins and when Post Integration Transactions to Finance Transactions is run at infrequent intervals.

Scott

Scott,

Thank you, that clears some things up.:)

Scott,

Thank you, that clears some things up.:)