Question

Additional postings in inventory transaction history after site deactivation

  • 27 August 2021
  • 2 replies
  • 485 views
T
Rank
Userlevel 1
Badge +1

Hi,

We have an issue in finance after site is deactivated in 2020.

Steps followed to deactivate the site: 

  • The stock is issued out using “Issue Inventory” which creates NISS entry in finance .
  • Sales parts status is changed to inactive.
  • Inventory part status is changed to ‘Dead’ with no demands/supplies/on-hand allowed.
  • User access to the site is removed.
  • In our set up, distribution sites also exist as code part ‘Site’. The code part validity of the corresponding site is changed to 31.12.2020.

 

IFS is automatically creating additional postings in the FY 2021 in the MPCCOM under inventory transaction history even though there are no material movements in the deactivated site.  

→ These additional posting lines are added seperately to the original postings of an inventory transaction with new accounting id.

→ These additional posting lines contains the same transaction code of the original inventory transaction. 

→ These additional posting lines are created in the current period where as original transaction belongs to previous accounting periods for which financial reporting is completed and the period is already closed in the accounting calendar. 

We are not sure exactly which functionality triggers these additional posting lines in the inactive site.

Any views/hints/solutions for this issue would be a great help to us.

BR/Dinesh

This topic has been closed for comments

2 replies

P
Rank
Userlevel 3
Badge +6

Do you use your part cost calculation method as ‘Weighted Average’ 

Are the inventory parts purchased or manufactured?

What is the setting for Supplier Invoice Consideration?

 

I suspect that the reason for the additional postings are related to Cascade Update of Cost on Inventory Transactions and or Transaction Based Invoice Consideration - Weighted Average (WA)/Cost per Part
See detailed explanation of these topics via the IFS Documentation below.

http://ifs-help.avcweb.com.br:8088/IFSV9/documentation/en/MaintainInventory/AboutCascadeUpdateofInvTrans.htm?StandAlone=true

 

Kind regards,

Sheri

P
Rank
Userlevel 3
Badge +6

Information below is from IFS Online Documentation for Topic:

Cascade Update of Cost on Inventory Transactions in IFS Applications

(Note: Documentation is from IFS Apps 9, however, may still be relevant to your issue)

 

General Information

The general idea of cascade update of cost on inventory transactions is that the actual cost (invoiced / manufactured) should be considered in the inventory valuation. The cascade update can be triggered in two different ways.

The first way is when a part has the Supplier Invoice Consideration flag set to Transaction, based on inventory part and an invoice is matched for that part. Then the invoice price will be used to update the cost on the purchase order receipt transaction and the change of cost/WA will be cascaded to transactions made after that purchase order receipt. If several invoices are matched for one receipt the cost used to update transactions is a weighted average of the invoiced price on those invoices. Transaction based invoice consideration could be used in combination with either the inventory valuation method standard cost and cost level cost per serial, or inventory valuation method weighted average and any cost level. Note purchase order charges are not included as a part of cascade updates.

The second way is when a manufactured part has valuation method set to either Inventory Valuation method standard cost and cost level cost per serial, or Inventory Valuation method weighted average and any cost level and when a shop order is closed for that part. Then the total work in process on that shop order will be used to calculate the cost that will be used to update the shop order receipt transaction(s) for the part. The change of cost/WA will also be cascaded to transactions made after that shop order receipt.

Observe that if a shop order issue is amongst the transactions that are cascade-updated, the shop order for which the issue is done will be reopened if that shop order is closed. And as a part of the cascade update all reopened shop orders will be closed, and new cascade updates for the manufactured parts on the shop orders will then be created. So if there are shop order issues amongst transactions to be updated, the cascade update will be a multilevel update.

And if any of the transactions that is updated is a transaction that moves parts to another site within the same company (this could be either a via an inventory move or via an internal customer order), there might be a new cascade triggered on the receiving site from the receipt transaction and onwards. Whether a cascade should continue over to another site (within the same company) or not is dependent on whether the valuation method of the part on the receiving site allows cascade updating or not. If the part on the receiving site does not allow cascade updates,  the actions performed will be the same as when moving parts to a site on another company: the difference posted on the issue transactions will be added as revaluation postings on the receipt transaction at the receiving site as well so that the transit accounts for movement of parts is cleared out. If the valuation method on receiving site allows cascade updates, a new cascade will be triggered for the received part from the receipt transaction and onwards.

The use of cost per serial or weighted average is handled somewhat differently. This is described in the example below that gives some examples on how a part that is set to Transaction-based Invoice Consideration is handled. The scenario for a manufactured part that has weighted average is the same when it comes to cascade updating. The only difference being how the cost set on shop order receipt transactions is calculated. It should be noted that the cost calculation will use an estimated cost structure at shop order receipt which will be updated when the SO is closed. This estimated structure is used even if the shop order is closed together with the receipt.

For parts that are moved between sites within the same company, and for cascades that continue over to other sites, a similar cascade is performed.

In Transaction Revaluation Events application form, system lists information on the trigger for cascade update of transactions including the object which triggered the cascade revaluation, execution times, involved user, number of inventory transactions that are updated with the cascade revaluation event etc.

Additional Postings

The variance/additional postings described in the sections above will be added to the existing transactions. That means that the original posting will not be affected or changed. Additional postings could be added to the transaction, independent of the status of the original postings on the transaction. The original postings could be transferred to IFS Financials, or included in the inventory statistics update. 

The additional postings will be added with the system date as the date applied, and the status of the additional postings could differ from the original postings.

Terms & ConditionsCookie settings