Could some kindly provide an explanation to the below questions? Any available online documentation also is highly appreciated.
Is there is a way to create two different transaction types to differentiate between "scrap" and "split"? Currently, they are both "FAP0" transaction types (on the balance sheet side of the transaction)
How is a Process Code added to a transaction?
“ We seek a means to assign a different "Rollfwd" code part on the two different GL Vouchers. From reading IFS Online Documentation it was concluded that this could be done using Process Code in the GL Automatic Posting Rules. • Two process codes are added to Basic Data: SCRAP and SPLIT; • A GL Automatic Posting Rule which is configured with Process Code SPLIT and "Rollfwd" code OTH; • There is a similar GL Automatic Posting Rule which is configured with Process Code SCRAP and a different "Rollfwd" code. “
Page 1 / 1
Hi,
I get what you want to do, but I don’t think it can be done the way your trying to do it.
To answer the questions
The scrap and split are different transaction types. They may use the same posting type for the balance sheet (asset side) so that we can assure the account flow is controlled. The FAP0 side is / can be controlled by the object / object pre-posting. Typically we would not want FAP0 to be different based on based on a type of transaction. Typically we cant FAP0 to have a static posting string so when the asset value changes (sell, scrap, move or other) that sting is managed successfully and the sting clear out when the asset is no longer in house or the object has changed (for example a move).
Generally - from an IFS Finance perspective - The process code can be “manually” added to a given finance transaction. For example on an supplier invoice posting, a manual voucher, an instant invoice, etc. Unfortunately I don’t see the ability to add a process code on the fixed asset transactions (scrap or the object pre-posting) If we can’t get the process code added to the transaction (especially on the FAP0 side), the automatic posting rule that considers the process code would never be triggered. Per what your trying to do, the way your trying to do it, you need that process code on a given posting line (FAP0). I don’t see how that can be done.
Makes me wonder if we have a different way to do what you want done. You can always do manual vouchers and provide the “correct” code string. If your not using internal ledger, depending if you have other needs, that could be very helpful. The number of Splits and scraps of fixed assets are not typically large in numbers - we don’t typically scrap hundreds of assets per month. Manual adjustments may be acceptable. External voucher could also be used in the case a high number of splits and scraps occurred in a given month.
Best regards,
Thomas
Hi,
As another option, typically the disposal reason is used for that purpose - differentiating scrap and sale. However I don’t see a way to get disposal reason to affect the FAP0 side of the transaction. Typically that data is not part of the code string. Supplemental data would be used. (not all data is in the code string).
Thank you @Thomas Peterson, you are hitting on all the points/obstacles that we’ve run into and are trying to find a way around. We currently use a “flow code” for cash flow reporting, and our objective is to assign different codes to Scrap and Split transactions. We are currently doing this via manual voucher but we were hoping to automate this based on Reason Code or something similar. IFS assigned two unique “Reference Series” for Split and Scrap within FAP0, but we’ve been unable to leverage this field to adapt a posting rule. Is this something that’s possible to achieve?
Thank you.
Hi,
II checked earlier for the reference series (tried that earlier as well) it’s not part of the automatic posting rule - can’t drive a reposting based on reference series. Furthermore reference series is not available for a control type. It’s going to be challenging to get that data into the code string. My honest belief is not all data points can be / should be in the code string.
If we look at this another way, can we do other to fulfil the reporting needs? You can always create statistical accounts that can be used to represent adjustments needed to produce the correct results. Then represent the corrected values any way you need. You could do the adjustments monthly or quarterly (or as needed) via an external voucher. Then GL remains clean in terms of the FAP0.
Best regards,
Thomas
Thank you @Thomas Peterson. At this point we will just keep our current process, requiring a manual journal entry to reclass to the correct Flow Code. It’s not a complicated step, but any automation that eliminates the need for manual reclasses helps during the close process. Sounds like it’s really not possible to automate the way we would like. If we decide to change tactics, it will be down the road a bit.
Thanks for all the insight and support, greatly appreciated.
Hi,
I think creating separate voucher types (of group A) for Scrap and Split FXA actions may solve your issues - voucher type is a trigger to Automatic posting rules.
Thank you, Adam. “A” Vouchers are automatically created thru the Scrap/Split process. How would I go about changing the default voucher type created for a Split transaction?
Only one voucher type of single function group (A in our case) can be defaulted, but user doing scrap or split action can select correct voucher type from list of values.
Usually I have one voucher type (e.g. ADE) dedicated for depreciation, and it is connected to the book, but not defaulted to FA user group, and one voucher type for each FA action (Scrap, Sale, Split, Add Investment). The one for split can be defaulted, during scrap operation you need to select transaction reason manually, so it is easy to select voucher type as well.
If NONE of the voucher type is marked as default for user group, user will always have to select it from List of Values.
This is Great, Adam! I will test this out! Much appreciated!!
@Adam Bereda -
YOU, my friend, are a STEELY-EYED MISSILE MAN!!!
We’ve tested this approach and it looks like it will work perfectly for us. Can’t thank you enough!!