Link between the records in the OIRADBT table (SSR)

[former_member253400]

Hello colleagues,

I need to link the records of meter reading and the payment card transaction record in OIRADBT table.

How can I solve this issue?

Thanks in advance!

KR,

Sergey

[former_member219399 · Accepted solution]

Hi,

In OIRADBT, you can find the entries DATATYPE = PC means Paymnet card transaction relevant data,

if MR means Meter reading relevant data. From here you can find the meter readings and PC relevant data.

You can use the field VKDAT for transaction date.

With regards,

Vamsi

[former_member253400]

It's clear, but I can have some records for the MR (for other meters) with equal date/time and some PC records with different date/time. In this case we don't have the definite link between each pair of records (MR and PC).

KR,

Sergey

[former_member219399]

Hi,

The meter readigns will be uploaded to system periodically, once in a day etc, and not transactionwise.

You mean to say how each payment card transaction relevant to each meter reading? could you please clarify?

if that is the case I dont think its possible to obtain such kind of relation.

Thanks and regards,

Vamsi

[former_member253400]

Yes, I need to find relevant payment card transaction to each meter reading.

Each pair of records (MR and PC) from Service Station will be uploaded to the system by way of one record and I need to have some key between records in OIRADBT table.

May be it will be SRCD_DATESRCD_TIMESEQNR ?

KR,

Sergey

Edited by: Sergey Rytkin on Jul 26, 2011 4:10 PM

[former_member219399]

Hi,

In this case may be you can use the MRdate, MRtime from OIRC_GMMH and VKDAT and VKTIM from corresponding PC header table. From these two you will get the link numbers based on which you can find OIRADBT entries.

With regards,

Vamsi

[former_member253400]

As mentioned earlier, we can have some records of meter readings with equal MRdate and MRtime (operations for different meters). In this case the combination of date/time is not enough.

KR,

Sergey

[former_member219399]

Hi,

Then may be here you have to use Material and Location combination as a differentiator. bcoz for Payment card transactions you dont have seqno.

With regards,

Vamsi

[former_member253400]

I think it not enough too, because the records of meter readings may have the same combination of date/time/location/material (one material will be assigned to the various meters on one location).

KR,

Sergey

[former_member219399]

Hi,

Could you please let me know the scenario you are trying to develop.

Thanks and regards,

Vamsi

[former_member253400]

1. We have two records of meter reading and payment card transaction for one event of selling petrol (in OIRADBT table).

2. While proccessing meter reading record we defined batch (CHARG) to fill in logistic document.

3. While processing PC record we need the value of the field CHARG to be automatically defined according to relevant record of meter reading. It is necessary because batch (valuation type of material) influences revenue account determination in billing document.

KR,

Sergey

[Former Member]

In our system, the link is done with these criteria:

1) Location

2) Date

3) Material

4) Service type (if used)

5) Sales price

For some countries (like France), there is a synchronisation between the day closure of the MR and the day closure for the PC. As a consequence :

1) The closure are done at same time

2) The day closure number is the same for MR and PC. So for France, this field is also used to do the link.

But I don't know if the equipment on stations for your client will allow this synchronization.

One last thing: how can you have MR with same date, same time, same location and same material. Won't they fall in error in O3RCMM04 with message "MR already exists with same date and time ?"

Hoping that it will help you

[former_member253400]

Hello Vincent,

We have MR with same date, time, location and material without error, because those records have different SEQNR.

It's a standard situation for service station.

KR,

Sergey