Category Archives: EN

Vytvoření skupiny zakázek PM

Po implementaci modulu Pm vyvstal požadavek založení skupiny PM zakázek (transkace KOH1, KOH2) pro následný reporting nákladů v transakci S_ALR_87012998. Úkol se zdál poměrně snadným, ale …

Ve standardu sapu by bylo potřeba neustále zadávat nové a nové zakázky do skupiny takázek v dané hierarchii. Toto nebylo možné aplikovat, protože zakázky různých druhů mají společný interval a skupina zakázek se zakládá pomocí uvedení seznamu zakázek. Toto je uživatelsky neudržitelná věc. Navíc požadavek byl, aby se zakázky zakládaly ve vazbě na vybavení.

Continue reading

Sales order item costing

There was a task to cost SD order item based on releted purchase order item. No problem..set costing variant with the user exit. There You can search for related PO item via EKKN table. If found, use the value from PO item , recalculate to basic unit . Done.

But…

Purchase order is not created immediatelly in the same period. It may take week or two to have PO item created. I checked first what is the average percentage of material cost. the result was that is about 70% of planned revenue.  So item is costed then with this value , 70% of planned revenues. Then there is a zreport, which shows if Po item exists. If PO item exists, zreport recost the SD order item via batch input .

 

Positive result of the solution: quite small diferencies in planned costs before real PO is created and SD items costed correctly based on existing PO. It can not be costed from material master data, cause average price in material master data is almost zero. If customer “e” stock is in use, sysetm does not update the value of material average price. There is mostly customer “E” stock, and they are getting different discounts for different sales order from their vendor. That is why other type of valuation can not be used.

This solution tok about two months of experiments. If you want to be successful, You need to focus on transactions to be used and correct timing and respect the process.

 

K_BALANCE_GET

This function module is very useful, when you want to check current (or historical) ballance of costs and revenues of any cost object, not settled based on the settlement rule.

You need just determine OBJNR from tables AUFK (co orders), VBAP (SD orders) and PROJ(projects)  for particular co object.

I have used that in zreport which shows those ballances for SD orders or production orders after the closing operation are done on the end of the month. It should be in fact zero ballance, when overhead calculation, result analyse and the settlement is done.

'K_BALANCE_GET' "
  EXPORTING
    objnr =                     " onr00-objnr
*   wrttp = '04'                " cosp-wrttp
*   versn = '000'               " cosp-versn
*   bis_gjahr =                 " cosp-gjahr
*   bis_perio =                 " coep-perio
  IMPORTING
    saldo_k =                   " cosp-wkg001
    saldo_o =                   " cosp-wog001
    saldo_v_k =                 " cosp-wkg001
    saldo_v_o =                 " cosp-wog001
    .  "  K_BALANCE_GET

 

wrttp with value ’04’ means actual postings.

bis_gjahr and bis_perio are parameters used when You need to see that balance for different periods, even current ballance is zero .

 

Purchase orders confirmation

This application was a “Christmas gift” for members from purchase department. I have seen that edi connection via idocs  was not established with all of vendors and many of purchase orders/items  had to be confirmed manually. If you know how standard ME22N transaction works, You have to admit that this part of the activity is very time consuming. Users have to open particular Po item by item and confirm it in item detail. Imagine that there can be up to 100 or more items to be confirmed for one PO.

Because a large part of the confirmation is in fact a constant (reference, delievery date) and confirmed quantity mostly corresponds with required delievry time from PO already recorded in Po , i have created zreport for Po confirmations.

This report reads at first all items of particular PO and shows items on the screen (ALV layout) . Report also allows to specify constant data on the selection screen. Then user can easily udjust data on the screen and the Po is confirmed almost in one shot.

The big advantage is here when some Po is confirmed , and then confirmed later on  again with different data. The report can overwrite old confirmed items with new data .

Here I can see real benefit of zreport. Simply it saves a lot of time.