I have created tfgld0108m000(chart of accounts) account type:balance sheet dimensions type is = optional , now i proposed to change to mandatory. the system is not allowing .message displays " empty dimensions found for this ledger account"

Is it possible to change optional to mandatory on the same ledger account.

PLEASE ADVICE.

Hi
You cannot to that because it already to get transactions history to use the chart of account if you need to change may be to change in table but just to set the dimension on history to get the dimension number .
Or you just to change it on the change current year that time.
Regards,
Poo

Hi,
You can not change the status from optional to mandatory because possibly many transactions could be already recorded in the history without dimension. Though you can change the status in GTM, it has far reaching effect in the year closure, bank reconciliation and many other system entries where the system refers to the earlier transactions with blank dimensions and throw an error.

Cheers

Hello - we have a ledger account that is using one of the dimensions and is set to optional. Two questions - if the dimension if optional - when? where? do the dollars go directly to the account? Where can we find these dollars? We run the Trial balance just on the account and get a number and then run Trial Balance with Dimensions and understandably get a lesser number. We just want to see those dollars somewhere. I guess we are seeing them on the first Trial Balance but Finance wants to see where they came from that they aren't getting to one of the dimensions.

thanks - NikkiZ

Hi,
When the dimension is set to optional, you may or may not specify the dimensions while entering transactions (or in the dimension mapping). The dollors go to accounts directly where the transactions do not contain the dimension value. Else, the dollors will be recorded both in the ledger account and dimension specified.

Trial balance by dimension essentially means the dimension balances (which need not necessarily tie up with the whole ledger account balance). Hence nowhere in the dimension trial balance can you see this money which is not posted to a dimension. Overcome this issue, many companies make it a practice to make the dimension "Mandatory" and create a dummy dimension to use wherever dimension is not required. So, wherever you do not want a dimension-wise breakup of transactions, you can simply dump the money into that dummy dimension. This way, you can tie up your dimension trial balance with your ledger trial balance.

Cheers,
Manju

Thanks for your thorough reply. I've tracked down the transactions that are coming through and not getting a dimension on them and now I'm wondering what to do with them so they do get a dimension. It seems they are integration transactions so they are transactions that are automatically created, to the best of my knowledge.

I was looking at the session tipcs8150m000 Maintain Project Transaction Accounts. I'm wondering if this is where my automatic integration transactions are coming from. Reason being, the trans type on the finalized transactions is for Integrations - Projects.

The account in question is for Indirect Labor and there are a couple of cost components associated with that account that are listed in this session. One for Trans Origin:Production(SFC) Financial Trans: Operation Costs and another for Trans Origin: PCS Financial Trans: Operation Costs.

Can anyone help clear the waters here for me? We'd like these transactions to stop being unassigned to a dimension. Oh - something else - on the finalized transactions for this account, the transactions that aren't assigned a dimension are the debits - the credits are getting a dimension. What that's about?

I hope I've explained this well enough.

Thanks - NikkiZ

You have explained the problem fairly well, but still I can't really comment about the sourse of your integration transaction just by the transaction type description. Seeing your explanation, I presume you are running a version of BaaN iv. Integration transactions come from different sources, important of them being tipcs8150m000 as also tdinv8150m000. However that does not matter, in as much as your dimension mapping is concerned.

Before getting into this, let us be clear that we can not really correct the transactions already posted without dimension, except by way of a series of GTM correction (or a correction program) which is not recommended, and if at all, it should be done only with a good professional help.

As for the future transaction, you can definitely map the dimension required. You may follow the following simple steps:
1) First, ascertain that the concerned ledger has the dimension usage set to "Optional" (if it is "Mandatory" it is fine, but I dont think that is the case with you, since there is presumably no integration log to suggest missing dimensions)

2) See where this particular transaction type is used in Integration mapping. You can find this in the session "Maintain Transaction types by transaction origin", by querying for this transaction type. You will get the transaction combination (i.e., transaction origin + Financial transaction) for which this transaction type is used.

3) In the record so found, find the integration element attached to the debit side (since you are saying debits dont have dimensions)

4) Go to session "Maintain Options by Integration elements" and find the above integration element.

5) See what is the dimension mapping for that integration element. If there is no mapping, maintain the same.

6) To do the same, first determine which of the five dimensions you are looking to map. If that dimension type is not mapped, insert the record in this session, with appropriate priorities (i.e., 0, 1 or 2),

7) Select the logistical key field which you want to determine the dimension (like order series, cost component, warehouse etc based upon which you want to determine the dimension).

8) Select if you want to maintain dimention mapping for a range of options or by each element.

9) Click "relations" to go into the session, where you maintain dimension relation to the option you selected in the previous screen (for example, for warehose ABC, you may want to maintain dimension XYZ, warehouse DEF, dimension PQR, etc)

Please let me know if you find any issues.

Cheers
Manjunatha

Yes, we are running Baan IVc3 and the account in question is set as optional. Thank you again for your thorough response. I will give it all a try and see where it gets us.

Thanks,
NikkiZ

As an added note to Manju's excellent replies, you could set up a "dummy" dimension code (for example, 99999=Other). Then in "Maintain Options by Integration elements/Relations", ensure that in your last priority any transactions that don't map to a "legitimate" code are mapped to the dummy code.

It's not as failsafe as if the dimension type usage on the account had initially been set to mandatory, but if you can ensure that every transaction maps to some code, totals on future reports from the ledger history tables will agree with reports from ledger/dimension history and that totals from finalized transactions reports based on ledger agree with totals from finalized transaction reports based on Ledger/dimension.

Baan IV has a limit of 3 priorities (0,1,2) for mapping relations. That may be a problem if only a few Integration Elements have been defined in your system and if each is used for multiple combinations of Transaction Origin/Financial Transaction. You can create additional Integration Element codes and assign different codes to different combinations of Transaction Origin/Financial Transaction in the session "Maintain Transaction Types by Transaction Origin".

Scott

tipcs8150m000 and tdinv8150m000 will be used to map integration Ledger Accounts.

The key to not having unassigned dimensions on integration account however is in tfgld4121m000 Maintain Options by Integration Element Type. The key is to pick something to map the dimension that will always be present on each transaction (sometimes a challenge). You can do this with up to 3 different priorities (0,1,2) for the system to search. If necessary in the last priority you could do a default so at least something is posted. The actual mapping is done in a subsession called 'relations'

The mapping for the credit can be different then the debit - based on the Integration Element - see tfgld4126m000.

Absolutely! The trick is to be able to use the lowest priority (2) for a "catch-all" or default mapping. That's why you may need to add new Integration Elements and attach to the credit or debit side of the transaction in "Maintain Transaction Types by Transaction Origin" .

The final (lowest) priority should map some element such as Item, Item Group, Supplier or Warehouse that is always available to the combination of Transaction Origin / Financial Transaction to the dummy dimension. For example, in relations, map Warehouse " " to "ZZZ" or item "blank/null" to "ZZZZZZZZZZZZZZZZ" to the "dummy" dimension code.

Scott

may i know how to block chart of accounts?

To block a specific ledger account, regardless of dimension codes, run session Maintain Chart of Accounts (tfgld0108m000).

On Form 2, change the Blocking Status from "Free" to "Blocked for All Purposes" or (if you only wish to restrict postings to system-generated transactions) to "Blocked for Manual Input". You must enter a date range in the "Blocking Effective From" and "Blocking Effective To" fields. Save & Exit.