Too many transactions are made when Customer (Kamstrup) use material bounded operations

  • 13 October 2020
  • 1 reply



Kamstrup make operation report for every 3 pcs.(PCB’s) with 500 components on a shop order with lot size 3.000 = 3.000/3*500 =500.000 backflush transactions on one PCB order.

PCB production line: On daily basis 3 lines runs with a speed of 140 pcs per hour = 140*3/3*500 = 70.000 per hour, 24 hours per day = 1.680.000 backflush transactions

First day we had 1.7 mill.

When we run full scale (PCB/EL, Water and Heat/Cooling) approx. 25 lines will be up running.


Three tables that involves:


MPCCOM_ACCOUNTING_TAB (here you will have the transactions times 4 due to nonstandard cost)

INVENTORY_TRANSACTION_COST(here you will have the transactions times 2)


Q1: First of all we need to find out if there are any other IFS customers running production with that many backflush transactions and if that’s a problem other than it takes out some space on the server and the processing of daily finance transactions will take hours.


Q2: How can we fix that ?

Suggested solution (Modification):

When a backflush operation happens and an existing identical inventory transaction exists and if it has not been transferred to finance (Status code != 3) it should just add the transaction to the exiting record.

Example of identical transactions:




1 reply

Userlevel 3
Badge +5

I have so many questions regarding this solution but I will try to answer question 2.

Easiest way as I see it is to aggregate inventory transactions when creating vouchers, only for backflush transactions.

Then you do not need to change the logic with transactions. There are also more tables involved than you have specified. material_history_tab for example.


General thoughts:

  • What is the reason for report finished qty on Shop Order Operation every third PCB? Can that be changed? Is it a requirement to have the data in real time in IFS or is it an integration that does that? Can you wait and process several reports together? If you can do this you save a lot of transactions.
  • Preprare for archiving of transaction tables. Create a job to move old data to a separate archive database. You can make a separate job to archive only backflush transactions older than X days.