Any difference between data pulling from a table Vs. by using a FM?

[former_member194142]

Hello,

This is for: Indicator: GR-Based Invoice Verification EKPO-WEBRE

In our one of existing custom report the previous ABAP developer used the FM of ME_READ_HISTORY (History per Purchasing Document) and with in this custom report he/she used the values like, MENGE Quantity, DMBTR Amount value, REEWR Entered Invoice value and other data like EBELN PO #, EBELP PO Item #, GJAHR Year, BELNR Material Doc #, well, but now I'm thinking just for the purpose of these 9 to10 fields data why do we need to use a FM because the function group associated with this FM has a handful other FMs hence a very big function group will be loaded into the runtime environment at the time of report execution!

Instead of using this function module I want to pull my required 9-10 fields data directly from the EKBE table, but as its a PO Item HISTORY data do you think its not a good idea to pull the data directly from the table, because I don't know which is the current/valid row in the table for a PO & PO item # in question that I need to pull from the table? If I leave the FM as is in the program then I guess, the FM will take care of all that stuff (what is the current / valid row in the table for a PO & PO item # in question, ROUNDING, local currency)

Pl. let us know is it safe to pull the values (quantity and amount) from EKBE (History per Purchasing Document) data directly from the table for a PO & PO item # in question?

If I pull the values directly from EKBE table then on what fields I need to do SORT so that I can get a valid / current row in the table, if so, is it a ASCENDING sort or DEESCENDING sort?

Thank you

[Jelena]

If you can do it correctly then yes, you can just read data from the table. In many cases it'd be more efficient too.

Not sure about the last question - all records in the table are "valid". Check with MM consultant what is needed exactly.

[Colleen]

Hey Jelena

I'm no developer so I thought I'd ask you - isn't it always encouraged to use the function modules or APIs in case SAP makes changes you have less risk of your customer code breaking? Also, security, etc might have the authority checks in the code?

Regards

Colleen

[Jelena]

Hi Colleen,

If this was a general question about "best practice" I'd stayed away from the discussion altogether.

In this particular case FM ME_READ_HISTORY is marked as 'Not released', so really it should not be used at all by the customers. There is a very real risk of custom code breaking from using an unreleased FM. But it's unlikely SAP changes the major standard table any time soon. Even in HANA redundant tables are converted to views, so the code will still work and just may need to be adjusted.

FM being part of a large function group would be the least of my worries, but OP's concern about redundant data was quite valid. After all, "don't read from the database what you don't need" has been our ABAP mantra all along.

Regarding security - it's a general ABAP guideline that a program has to have an appropriate authorization check. If this check does not occur within an FM or transaction then it needs to be done in the program itself. It's kind of an implied knowledge, so we don't point it out with every suggestion in the ABAP forum. But it's an important point nevertheless, thanks for bringing this up.

We do have a few custom reports where EKBE table is read directly. The requirements were written by an MM consultant, so we know exactly what records we need to read. (Jurgen noted correctly that there are many items stored in PO history, that's why I also recommended to reach to a consultant.) Our reports have authorization checks programmed that meet our security requirements.

So bottom line - if there was a good, well-performing FM/API then there probably wouldn't even be a question whether it should be used or not. But it's not the case here specifically.

[former_member210541]

yes it is valid,just be careful about cancellation documents.

[former_member194142]

Thank you.

How to figure it out of a CANCELLATION document because am not seeing any deletion / cancellation indicator field in EKBE table, pl. let us know?

[Jelena]

There is no cancellation indicator per se, but some transactions cancel each other out. For example, you could have a goods receipt (101 movement type) and then GR cancellation (102 movement type).

[Former Member]

Hi

Just to add to what others have already said.

You could use field SHKZG ( 'H'(Credit) / 'S'(Debit )  ) indicator to know if the stock is going out or coming in.

But I will also suggest to use Standard FM as much as we can. Don't be bothered about loading FMs of the Function group. There are other aspect in ABAP programming that we should be bothered about rather than this things.

R

[JL23]

"If I have no problems then I create them myself", is that your ideal approach?

I do not see much sense in reinventing the wheel. And honestly I never saw in 18 years that someone cared about how much is loaded into runtime environment when calling a standard SAP given function module.

But the PO history has to be understood, as it collects many different documents, in an ideal world you have 1 receipt and 1 invoice for a single item, but in real world there might be hundreds of partial receipts and cancellations and re-entering and then as well as much invoices and even more for additional costs like freight, customs etc.

And to add more complexity, history can be aggregated and then a direct EKBE access would certainly be insufficient.