Usually for the item numbering the customizing setting in transaction VOFA is decisive - field "Increment of item number" - technical name: TVFK-INCPO:
Now in general this setting decides with which increments the item numbers are increased in the invoice itself. If a value of "10" is entered into the field, then the numbering would be 10, 20, 30 and so on. If "100" is chosen as increment, then likewise it would lead to items 100, 200 , 300... If the customizing field is left empty, then the smallest increment would be used, which is 1, 2, then 3 and so on.
However in case of creation of partial settlement within the enhanced rebate process, this is not the only setting that decides the item numbering.
With a rebate agreement which has two or more rebate condition records, the creation of a partial settlement with transaction RBT_ENH_VB7 can lead to a numbering of 1, 3, 5 and so on in the credit memo, when the increment is not defined in VOFA.
How is this possible?
For the creation of the partial settlement the customizing setting of the copy control has an influence. Here in this process no sales order type is created, but nevertheless the setting is taken into account from transaction VTFA:
In the SAP standard for the partial settlement the invoice type B3E and the sales order type B3E is used. There the setting on header level "Copy item number" (field TVCPFAK-POSVO) is important. If the flag in this field is set, then the numbering would be taken over from the previous document, and not determined according to the other setting in VOFA (TVFK-INCPO).
When in then rebate agreement two rebate condition records are present, with both having accruals set, the partial settlement is leading to a numbering with 1 and 3, because for the accruals a separate entry is created. The process starts with transaction RBT_ENH_VB7:
Then when the function module ENH_REBATE_MANUAL_PAYMENT is called, the bonus records consist of four entries, the number 1 and 3 are the rebate conditions itself, the number 2 and 4 represent the accruals:
This numbering is important, because in the processing with function module ENH_REBATE_CREDIT_NOTE_CREATE, the numbers filled for the previous item XKOMFKGN-VGPOS are taken from this sorting order:
Then in this case the numbering is 1 and 3, as the accrual lines are not taken over as items into the credit memo.
When the credit memo is going to be created with function module GN_INVOICE_CREATE, the numbering of XKOMFKGN-VGPOS is decisive, because in the copy control the flag for copying the item numbering is set:
This customizing of the copy control is taken into account here, and then the effect is as such, that the item numbering is unchanged taken over rom XKOMFKGN-VGPOS:
And as a result, you get the item numbering in the invoice with 1 and 3:
For a different behavior, you would have to change the copy control setting in VTFA and remove the flag for copying the item number.