Service fee in the sales order

[Former Member]

Hello Experts ,

We have a scenario , where the sales order ( Ex: OR) will have a service fee line item in some of the orders. This is more like a design fee which will be added as one of the line items in the sales order . This item is not relevant for delivery .

The service fee item has been set up in the system with item category TAW . ( not delivery relevant ) The requirement from business is , they don't want this item ( design fee) to get invoiced until the whole order is invoiced. They can put a item level billing block , but again it's lot of manual intervention to place and remove the block .

Is there any smart way of handling this which will ensure that this item doesn't get billed in advance . Could anything be done at item category level or should it be a custom development . Please share your inputs on how this could be done with minimal system changes .

Note : This is not a service order, but rather a design fee added as part of normal sales order.

Thanks

Sri

[Jelena]

+1 to what Veselina said. Just adding my own experience as an ABAPer and pretending to be SD expert.

We have 2 systems and both have some kind of extra fee feature. In one system, it's implemented as a header-level pricing condition. Other than a bug fix in a custom form, we've had 0 issues with it in many years.

In the other system, people didn't want to use pricing for that, they wanted a line item. Since we use both order- and delivery-related billing, we have two separate materials and the users decide which one to enter, based on the other items in the order (our document volume is rather low). In the delivery-related scenario, the service fee appears as a line on delivery and, just like Veselina described, it's not relevant for picking. The only purpose of this is to get the whole shebang invoiced together.

We use delivery groups when needed and it is a manual process. The sales people wanted to have this "automated", of course, but could never come up with any criteria for automation.

It's been a f*g nightmare for years. "Where is my line so-and-so? Why was this not in the invoice? Why was it on a wrong invoice? Why this person in shipping ignored the warning?" As soon as one person finally learns the process they leave and don't train a replacement. These tickets subsided only in the last year or two since there was no staff rotation in sales.

[Former Member]

Thanks Jelena for sharing your experience on the same line .Could you please explain the solution of having this fee as a header level pricing condition in detail. If I create a new condition type for this fee, it definetely needs to reflect in the customer invoice as a seperate fee. I am hoping this will be handled similar to printing a tax or shipping charges which is also represented as a condition type in pricing procedure . Please share your thoughts.

Secondly , if I have an inter-company scenario , will this fee be transferred to other company code while creating a Inter-company PO?. I don't want this to happen .

Thanks

Sri

[Jelena]

Header pricing condition is standard functionality. Surely you don't need an ABAPer to explain it. 🙂 Should be plenty of information on this in Google.

Printing is a bit tricky here because you need custom code in the form to print the condition as a separate item. But, like you said, it can be done just like for taxes or any other pricing condition.

We don't use additional charges in the inter-company context, so I can't comment on that. But I'm guessing through the configuration you can make such condition to apply only on the customer invoice.

[VeselinaPeykova]

+1 to what Jelena suggests with a few more points:

If the reporting and accounting needs for the service fee are very simple - e.g. you need only to post 10 EUR in accounting and you have the same VAT and if the company policy permits manual adjustment of pricing in the order, a separate pricing condition will be my preferred way to approach the situation.

If the business tells you for example that VAT for FG is 20% in general, but VAT for service is 9% then a single condition will not suffice, so make sure to discuss with the business users and with the accounting department and determine what is the exact requirement before deciding between the possible options.

As Jelena said, relying on end users to populate correctly delivery groups manually in the order does not work well in reality. If your process is something like 'we sell product A and optionally we perform some service related to that material', and if you really cannot avoid the line for services, consider separate item categories, one of which is with BOM explosion. Of course, mistakes will happen even with well trained and experienced users, but I would expect these to be fewer compared to manual delivery group maintenance.

[Jelena]

Good point about the taxes. These considerations are frequently overlooked, unfortunately.

[Former Member]

Thanks Jelena and Vaselina for your valuable inputs and insights. I will check with business and come back based on the over all constraints they see on the available options.

Thanks

Sri.

[Former Member]

I can double check if the Item relevant for delivery was checked off due to any specific reason . If not, I can reinstate the flag and save creation of another Z item category .

In the above case , I see that the design fee ( assuming I am using TAW) is assigned to schedule line CT . Since this is a "fee" item with no tangible goods, will this create an issue with any of the MM postings ? . I checked other finished goods and they all have delivery relevant billing .

Do you still intend using the delivery group indicator for the design fee item along with other finished good item?

Thanks

Sri

[VeselinaPeykova]

A small remark - in the new platform members do not receive notifications unless you reply directly to content created by them or you use @mention feature.

This means that if you post an answer to your own question and do not @mention people, only you receive notification; other participants will not know that you provided an update.

Anyway, back to your question - CT has no MM movement type assigned, which means that there is no inventory posting and no material document created. I believe that in standard TAW is not picking relevant, which means no additional work is expected for it by logistics people. It is not weight/volume relevant, but just to be on the safe side - if you use transport cost calculation it will be a good idea to check if this item does not affect the price result. Also check whatever printforms the company uses for shipping - my understanding is that this item should not appear there.

If TAW settings were changed because somebody needed it for a different process it could become complicated if there are existing documents, so please proceed with extreme caution.

Re:delivery group feature - yes, I meant having the finished product and the fee within the same delivery group.

[Former Member]

Thanks Vaselina. I will keep this in mind. Hope I am doing it right this time :).

When I group the design fee and finished product in the same delivery group, is it something which the person creating the order needs to manually enter in the sales order under delivery group ( with the same number) , because the one in the item category level seems to cater more for the BOM material rather than for normal items .

Thanks

Sri.

[VeselinaPeykova]

In the sandbox where I checked TAW is relevant for delivery and it has billing relevance A.

Is there a specific reason why you don't wish to include the service item in the same delivery as the finished product?

The easiest way to ensure that the billing of the service item will not happen before you bill the finished product is to have both in the same delivery 🙂

[Former Member]

TAW in my system is not relevant for delivery. Probably they took the flag off for delivery. This item is just a design fee and is not relevant for delivery. This fee is charged per order and business wants to invoice this item along with the whole other items in the order.

Thanks

Sri

[VeselinaPeykova]

If in your system TAW is not relevant for delivery, then maybe whoever did this changes also other settings.

I am almost sure that in my system this was not changed, which is why I post screenshots for you to compare.

TAW is assigned to schedule line CT:

By using these settings an item with this item category can be copied from an OR order to a LF delivery and upon goods issue you generate confirmation of service.

Of course you still need to ensure that the service item does not go alone into a delivery if you do not have available stock of the finished product. I would probably try exploring delivery groups in this case (there is a small challenge with that if users are authorized for delivery creation in dialog mode, but it is manageable).

Create your own item category that is relevant for delivery - this is the easiest, cheapest and probably the most safe approach if your finished products are also with billing relevance A.

If your finished product items are relevant for order-related billing then I cannot think of a way to avoid development completely.