In both the GL system and Cognos Finance accounts have a user defined attributed called “CashFlowCD” or “Cash_Flow_Code,” respectively, which is assigned when an accountant creates the account in the GL system. The value of the Cash_Flow_Code is received in CF during the normal update routine.
The purpose of the cash flow code is to mandate Accounting to assign the account to a particular line of the Statement of Cash Flows.
In CF, we are attempting to create system calculated accounts utilizing the @DFP and @IN functions for use in the Statement of Cash flows. However, we continuously get the error “Invalid ‘@IN’ construct” which the manual defines as @IN(component.attribute "attibute ID").
In these examples, both receive the “Invalid ‘@IN’ construct” error:
@DFP("CYEARN" * @IN(ACCOUNTS.CASH_FLOW_CODE "CF102010" ))
@DFP("CYEARN") * @IN(ACCOUNTS.CASH_FLOW_CODE "CF102010")
…where “CYEARN” is the current year earnings parent account, the component is ACCOUNTS, the user defined attribute is CASH_FLOW_CODE, and the attribute ID is “CF102010”. I lean toward the first being the correct syntax and the second was done just to try to prove it wrong but both fail.
Any insight on the potential cause(s) of the invalid @IN construct?
Thanks
The purpose of the cash flow code is to mandate Accounting to assign the account to a particular line of the Statement of Cash Flows.
In CF, we are attempting to create system calculated accounts utilizing the @DFP and @IN functions for use in the Statement of Cash flows. However, we continuously get the error “Invalid ‘@IN’ construct” which the manual defines as @IN(component.attribute "attibute ID").
In these examples, both receive the “Invalid ‘@IN’ construct” error:
@DFP("CYEARN" * @IN(ACCOUNTS.CASH_FLOW_CODE "CF102010" ))
@DFP("CYEARN") * @IN(ACCOUNTS.CASH_FLOW_CODE "CF102010")
…where “CYEARN” is the current year earnings parent account, the component is ACCOUNTS, the user defined attribute is CASH_FLOW_CODE, and the attribute ID is “CF102010”. I lean toward the first being the correct syntax and the second was done just to try to prove it wrong but both fail.
Any insight on the potential cause(s) of the invalid @IN construct?
Thanks