idoc HLEVEL

[Rohan]

Hi Guys,

I have been creating a json to idoc mapping and it has all been going well.

However, today I noticed that the automatically created "HLEVEL" was starting one number too high.

I looked in the BOTS code and found the following in outmessage.py (458):

if self.ta_info['automaticcount']:

            noderecord.update({'MANDT':self.ta_info['MANDT'],'DOCNUM':self.ta_info['DOCNUM'],'SEGNUM':str(self.recordnumber),'PSGNUM':str(headerrecordnumber),'HLEVEL':str(len(structure_record[MPATH]))})

I found that if I simply subtracted one from the len() calculation it would give the correct result:

if self.ta_info['automaticcount']:

            noderecord.update({'MANDT':self.ta_info['MANDT'],'DOCNUM':self.ta_info['DOCNUM'],'SEGNUM':str(self.recordnumber),'PSGNUM':str(headerrecordnumber),'HLEVEL':str(len(structure_record[MPATH])-1)})

Perhaps this has to do with the fact that the "EDI_DC40" record is not the first level?

The following is the output before the code change:

EDI_DC40  3000000000000000013701 3012  MBGMCR03                                                    MGBMCR                                     MGBMCRGXS       LILFY55231                                                                                               SAPTS2    LS  TS2CLNT500                                                                                           20130624121419                                                                                                                                    

E2MBGMCR000                   300000000000000001300000100000102 

E2BP2017_GM_HEAD_01003        300000000000000001300000200000203201306242013062413                                                                                                                                                                                              

E2BP2017_GM_CODE000           30000000000000000130000030000030304

And the following is output after the code change:

EDI_DC40  3000000000000000018701 3012  MBGMCR03                                                    MGBMCR                                     MGBMCRGXS       LILFY55231                                                                                               SAPTS2    LS  TS2CLNT500                                                                                           20130624122702                                                                                                                                    

E2MBGMCR000                   300000000000000001800000100000101 

E2BP2017_GM_HEAD_01003        300000000000000001800000200000202201306242013062418                                                                                                                                                                                              

E2BP2017_GM_CODE000           30000000000000000180000030000030204

So my question is, am I doing something wrong that is causing the HLEVEL to start one step too high? Or is the change I have done the correct fix?

Thanks in advance,

Rohan.

[BikeMike]

Hi Rohan,
I do a lot of IDoc mapping and had never noticed this.

In my case when mapping to IDocs, SEGNUM, PSGNUM, HLEVEL are all left justified without leading zeros (due to my grammars defining these fields as AN). HLEVEL starts from "2 " as you mention. However it seems that SAP does not check these values or does not care!

The outgoing invoices I get from SAP have a count with leading zeros in SEGNUM, always "000000" in PSHNUM and always "0 " in HLEVEL

I guess your change is probably correct but makes no practical difference.

Kind Regards,
Mike

[henk-jan ebbers]

hi Rohan,

do you have examples of idoc where this is done 'right'?

as Mike said, seems not to be a critical thing, but of course it is better to do ths correct!

kind regards,
henk-jan

On 06/24/2013 04:56 AM, Rohan wrote:
> Hi Guys,
>
> I have been creating a json to idoc mapping and it has all been going well.
>
> However, today I noticed that the automatically created "HLEVEL" was starting one number too high.
>
> I looked in the BOTS code and found the following in outmessage.py (458):
>
> if self.ta_info['automaticcount']:

> noderecord.update({'MANDT':self.ta_info['MANDT'],'DOCNUM':self.ta_info['DOCNUM'],'SEGNUM':str(self.recordnumber),'PSGNUM':str(headerrecordnumber),'HLEVEL':*str(len(structure_record[MPATH])*)})

>
> I found that if I simply subtracted one from the len() calculation it would give the correct result:
>
> if self.ta_info['automaticcount']:

> noderecord.update({'MANDT':self.ta_info['MANDT'],'DOCNUM':self.ta_info['DOCNUM'],'SEGNUM':str(self.recordnumber),'PSGNUM':str(headerrecordnumber),'HLEVEL':*str(len(structure_record[MPATH])-1)*})

>
> Perhaps this has to do with the fact that the "EDI_DC40" record is not the first level?
>

> The following is the output *before *the code change:

>
> EDI_DC40 3000000000000000013701 3012 MBGMCR03 MGBMCR MGBMCRGXS LILFY55231 SAPTS2 LS TS2CLNT500 20130624121419

> E2MBGMCR000 3000000000000000013000001000001*02*
> E2BP2017_GM_HEAD_01003 3000000000000000013000002000002*03*201306242013062413
> E2BP2017_GM_CODE000 3000000000000000013000003000003*03*04
>
> And the following is output *after *the code change:

>
> EDI_DC40 3000000000000000018701 3012 MBGMCR03 MGBMCR MGBMCRGXS LILFY55231 SAPTS2 LS TS2CLNT500 20130624122702

> E2MBGMCR000 3000000000000000018000001000001*01*
> E2BP2017_GM_HEAD_01003 3000000000000000018000002000002*02*201306242013062418
> E2BP2017_GM_CODE000 3000000000000000018000003000003*02*04

>
> So my question is, am I doing something wrong that is causing the HLEVEL to start one step too high? Or is the change I have done the correct fix?
>
> Thanks in advance,
> Rohan.

> --
> You received this message because you are subscribed to the Google Groups "Bots Open Source EDI Translator" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to botsmail+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Rohan]

Hi Mike,

Yes, well the samples I was previously sending back were not rejected either.    The only reason I picked it up was because I was comparing bytes between the samples they gave me and the samples I created to send back.

Thanks for your feedback.

Quick question for you.... have you ever had to be forced to send back your idoc lines in the fixed length of 1063 characters regardless of the type of line it was?   My client is claiming SAP is rejecting the lines because they are not 1063 characters in length (excepting the EDI_DC40 lines of course which is 523).   I have never had to do this before!

Cheers,

Rohan.

[BikeMike]

Hi Rohan,
I have never come across any problem with varying length in IDoc records. But it should be easy to fix this in the grammar by adding a dummy field of the required length to each record.

    'E1EDK02':[
        ['BOTSID','C',10,'AN'],      # 000001-000010 Segment (external name)
        ['FILLER','C',20,'AN'],      # 000011-000030 Not used
        ['MANDT','C',3,'AN'],        # 000031-000033 Client
        ['DOCNUM','C',16,'AN'],      # 000034-000049 IDoc number
        ['SEGNUM','C',6,'AN'],       # 000050-000055 Segment Number
        ['PSGNUM','C',6,'AN'],       # 000056-000061 Number of superior parent segment
        ['HLEVEL','C',2,'AN'],       # 000062-000063 Hierarchy level of SAP segment
        ['QUALF','C',3,'AN'],        # 000064-000066 IDOC qualifier reference document
        ['BELNR','C',35,'AN'],       # 000067-000101 IDOC document number
        ['POSNR','C',6,'AN'],        # 000102-000107 Item number
        ['DATUM','C',8,'AN'],        # 000108-000115 IDOC: Date
        ['UZEIT','C',6,'AN'],        # 000116-000121 IDOC: Time
        ['FIXLEN','C',942,'AN'],     # 000122-001063 Make length fixed 1063
        ],

Kind Regards,
Mike