Hi,

generally it can be used to add information to a codes part. This information can be used in GL queries. You can for example use it to group your accounts or add information to be used in queries.
I used in or in case of other codeparts for to add a cost center responsible as an attribute to a cost center.
 

Kind regards

In short, can I use these parameters to only cover the reporting part and not impact the accounting process that I use on a daily basis?

As far as I can say I did not cover any daily processes using attributes.

If it comes to month end, you can use attributes also in periodical cost allocation.

Is there a special business scenario that you have in mind?

Finance needs to identify which region (location) c.costs belongs to in its interest and fines reports, for example.
In the past, when entries were not centralized in (Finance), when interest/fines were paid, the report pointed to the user who launched and this belonged to the region (site), now that entries are made by the Finance area, this information per user no longer works for analysis, hence the importance of identifying which region (site) the c.costs belong to.

If I understood you correctly you would like to have an information on the posting line in this case <region> when specific cost is posted to GL.

Quite often a codepart in IFS is used for Intercompany purposes (CustomerGroup, SupplierGroup) to add information on AP/AR accounts and postings, to support consolidation processes. 
Also Site is used regularly as a codepart to distiguish between the cost and revenuies per sites.

I am not aware of your codepart setup and how these cost will find its way to the GL but if you use one or the other as a codepart it should be possible to add or map the relevant information defined in the codepart.
If you use e.g. manual voucher entry you might also consider creating seperate VoucherTypes per region and use them region specific. In reports the information voucher type can be used to assign the correct region. It is not the smartest solution but might work.

Hi, 

I’ve used attributes - a good number of times.  Attributes can be used for grouping data, as described above, extending information about a code part value. 

A common example is when we need to utilize some third-party tool for consolidation.  The IFS account 1234 is mapped to a reporting consolidation account 1234000. The 1234000 is the attribute value. The attribute could be something like consol acct (for consolidation account). Believe it or not, once set up and the attribute values are connected you could then see balances in the IFS account number 1234, or the consolidation account 1234000, or both side by side. 

In your example - it can be used to assign a region value to a cost center. In your example assume 100 cost centers, you have 5 regions. Each cost center value is assigned to one of the 5 regions.    For reporting you can report by region, cost center or both at the same time.  

Not all reports support attributes.  Reports you derive from downloading balance analysis would support attributes. As well as any of your business reporter reports, those can support attributes. 

So… Attributes are commonly a grouping function, or an extension for additional data.  You can’t post directly to an attribute. Your posting would always be to the code part value. 

Attributes are very similar to structures and that concept however structures support multiple levels (like an organization chart) attributes generally are one level deep

Attributes are a good thing. 

Hope this helps.

Best regards,

Thomas. 

Thank you everyone for your help!

Thomas Peterson, you were able to map my situation, I appreciate your support!

Thank,
Thiago Morais