cancel
Showing results for 
Search instead for 
Did you mean: 

FSCM-DM Customer-Disputed (how to identify)

Former Member
0 Kudos

I know Customer-Dispute cases aren't process integrated with AR, but our company wants them to automatically close when the AR in the Cust-Disp folder clears. Is there a table that I can easily identify if the case is process integrated (disputed item) or not (customer-disputed).

My understanding of Customer-Disputed functionality is that it's way more flexible, not process integrated, and the case is supposed to be initiated by the customer. Does anyone have a different interpretation ? It seems SAP left this one not too clearly defined and it's very confusing  to explain to our users. I want to simplify it if possible. Be happy to hear any other opinions on this functionality. Thanks,,

Joe

Accepted Solutions (0)

Answers (3)

Answers (3)

0 Kudos

Hi Joe,

Did you finally implemented any solution. If yes, Can you please tell me the logic you used to identify the Customer Disputes and which ones to close.. Would like to know the exact table and field names please .

Code Snippet would be of great help!

Regards,

Vinny Chawla

former_member214808
Participant
0 Kudos

Hi Joe,

Why don't you use the Cust. Disputed amount field (UDMCASEATTR00-FIN_CUSTDISP_AMT). But checking this field will not be enough because a dispute case can have both Customer disputed amount and Disputed amount.

So you can go with the logic if Cust. Disputed amount is not zero and Disputed amount is zero. Those dispute cases can be cleared. I am not sure after this what will be your criteria to decide which Cust. Disputes to close.

Thanks and Regards,

Prateek

Former Member
0 Kudos

Prateek,

The Cust Disp amount field is not going to work because that field is freely editable even when the case does not have a customer-disputed folder. I find it strange that the system will accept a value in that field with no customer disputed folder.

The logic as I've come up with is: Case must be in an active status(not closed/confirmed/voided) and Original Dispute Amt = 0. If that's true check the underlying AR docs , if all are in BSAD then close the case.

If anyone knows a better way let me know. Thanks,

Joe

Private_Member_10672
Active Participant
0 Kudos

Hi Joe,

This logic sounds good to me.

Thanks,

Nirav

former_member214808
Participant
0 Kudos

Hi Joe,

From Attribute Profile settings in SPRO you can make that field not modifiable just like the Original Disputed amt. field. Just a config. Why not do this rather than building logic in custom program.

Thanks

Prateek

Former Member
0 Kudos

Prateek,

I really only want Cust-Disp Amt to be not editable when the case has no customer-disputed folder. I wouldn't want to make it not modifiable completely. My understanding is that having this flexibility to manually enter an amount that is not the same as the disputed AR is a feature of customer dispute cases. I wouldn't want to change that.

For example: Customer calls and disputes an invoice but only a portion. Then if the invoice were for $100 , you could enter the disputed amount in the Cust-Disputed amount field. It could be $25.

You don't have that flexibility on a "disputed item" case.

former_member214808
Participant
0 Kudos

Hi Joe,

As per my understanding the purpose for Cust-Disp cases is to give AR analyst more time to investigate the dispute and assign a Debit item (invoice) latter on to the dispute case and make it a regular dispute case which then becomes process integrated with AR and closes automatically once the invoice is cleared. In case the AR analyst does not find any item to be attached i.e. the dispute case is invalid. The analyst should manually close the Cust-Disp Case.

So, as per that explanation to close them automatically does not make sense to me. I will suggest you to go back to client and have this discussion. Because with the logic we discussed above we might close a Cust-Disp case during the time AR analyst was investigating it.

Thanks,

Prateek

Former Member
0 Kudos

Prateek,

If you have a CDIS case because the customer notified that they will short pay ;and then if they actually do shortpay how would you get that residual debit into the CDIS case automatically. Where I work the residual debit would wind up in a new case with no reference to the original CDIS case because the auto-create program just scoops up all residual debits after the lockbox runs and creates cases for them. In theory I get what you are saying, but it's not clear to me how to attach the residual debit back to the CDIS case automatically. We have too much AR to look at each shortpay and manually link that residual item back to a CDIS case if one exists. If it can be done automatically then yes I'm all for it, but how can that be done ? We would just close the CDIS case automatically because the original invoice is cleared and have a new case for the shortpay debit amount. Thanks,

Joe

former_member214808
Participant
0 Kudos

Hi Joe,

Its a really good discussion going on here!

Just tell me one thing in the example you gave above. If customer calls and notifies that they will short pay, won't they give the invoice number for which they will. If yes, why can't we create a process integrated (normal) dispute case for that invoice and assign the amount by which it will be a short payment (as per customer) to the cust.disp.amt. field.

Now there are two possibilities:

1. Customer short pays: Invoice gets cleared, original dispute closes and another automatic dispute opens for the residual amount. which is still process integrated and will close automatically once that residual amount is cleared either by payment or credit memo, etc.

2. Customer makes full payment: Invoice gets cleared, original dispute closes.

I do not see any issue with CDIS in this case. Please share your thoughts.

Thanks,

Prateek

Former Member
0 Kudos

Prateek,

There is nothing wrong with doing it like you have described however I find it to be very confusing when the case is process integrated AND the customer-disputed amount is populated (especially if no CDIS folder is present). When you have both folders in the case "Customer Disputed" and "Disputed Objects"; the case is process integrated. So you could have AR still open in the CDIS folder but as soon as the AR clears in the Disputed Objects folder that case will close regardless of the open items in the CDIS folder. I think it's easier to try to keep the CDIS cases separate. And then you can report total AR in dispute (both CDIS and process integrated) and further break it down to understand how many cases were initiated by the customer vs internally. If you mix cases it would be difficult to get this breakdown. Bottom line, if the customer initiates it, I think it should be customer disputed.

Joe

Private_Member_10672
Active Participant
0 Kudos

Hi,

Can you please be elaborate with example when you say our company wants them to automatically close when the AR in the Cust-Disp folder clears?

Do you mean to clear AR open item automatically when Dispute is cleared/closed?

Examples for your AS IS scenario will help us understand better and reply properly.

Thanks,

Nirav

Former Member
0 Kudos

Sure an example is if someone creates a dispute case for an open payment (credit). This case will not automatically set the status to "Closed" even when the AR is cleared. This is the nature of Cust-Disp cases, they aren't process integrated with AR, so the status only changes if the user changes it manually. We want to develop a program to set these cases to "Closed" if the cust-disputed AR is cleared. The challenge is we don't want to select all cases, just the customer-disputed ones. There's no need to select the "disputed item" cases because they are process integrated with AR and will close automatically.

Private_Member_10672
Active Participant
0 Kudos

Ok, so there are different settings in your system for 'Disputed item' which gets cleared automatically when AR item is cleared- which is a standard process, vis-a-vis 'Cust-Disp cases' which are NOT AR integrated and hence requires manual intervention to close the case.

Can you explain the second type of dispute case i..e 'Cust-Dispute Cases' settings in your system? How,in the first place, dispute case is created if not integrated with AR? Is it Non-SAP AR system, and dispute cases are created by users manually for every deductions?

Please explain.

Thanks,

Nirav

Former Member
0 Kudos

Nirav,

Turning on customer-disputed functionality is a feature of SAP that came in EHp2. If you turn it on the users have the ability to create two different types of cases. "Disputed Item" or "Customer-Disputed". When a user creates the case they have the option of selecting which type of case to create. Cust-Disputed cases are not process integrated with AR. So they don't close automatically. That is standard behavior for these cases. I'm trying to find a way to close them automatically. I need a table or field that will easily help identify these cases. It's confusing because SAP allows both Disputed Item and Customer Disputed folders to exist in the same case which makes it difficult to distinguish them apart. The only logic I can think of is to select only cases where "original disputed amount" is zero. But I was hoping for something a little more clean than that to identify the non-process integrated cases (Customer-Dispute Cases)

Private_Member_10672
Active Participant
0 Kudos

Hi Joe,

Got it now! You took me down to the memory lane,when we implemented DM. Well, we've a regular DM model and not CDIS model (Customer-Dispute). So, I never had this issue.

Well, but here my two cents;

I think you should be able to find the field which distinguishes between Disputed Item and Customer-Dispute, in either table SCMG_T_CASE_ATTR or UDMCASEATTR00. Just compare both the types of disputes in this table, and you should find one field which will help you filter Cust-Dispute case.

For future ref., you can always insert a new Attribute in Attribute Profile which will have values like '1.Disputed' and '2.Cust-Disputed', and have users select appropriate option at the time of creating Dispute, specially for Cust-Dispute. You can also have a BAdi update the field based on some logic. This way, you'll be able to differentiate between these two types of dispute cases.

Final question, just curious to know the reason for using both types of Dispute cases in your system, and what's the user of regular Dispute over another (Cust-Dispute) one. I know one feature of Cust-Dispute that you can create two different dispute cases per invoice whereas it's not possible for regular Disputed Item case.

Thanks,

Nirav


Former Member
0 Kudos

Nirav,

We already looked at those tables: SCMG_T_CASE_ATTR or UDMCASEATTR00, but nothing was there to make the distinction between the 2 types of cases. Creating a new field on the case might help but there is complexity in that users can add customer disputed items or disputed items after the case has been created which could change the identifier value.

The reason we turned the functionality on was because the business wanted to track open payments(credits) in dispute cases, which I really don't agree with. I believe that applying cash does not require a dispute case.  But it was done , and now we in the process of trying to educate the users on how to correctly use Customer-Disputed functionality because it was turned on and nobody was correctly trained on these different types of cases and when and how to use them.

Former Member
0 Kudos

Hi Joe

OK Customer Disputed Objects can be used for a number of reasons

1 - Raise a dispute against a customer, not an invoice

2 - Raise a dispute against a Credit line in isolation

3 - Raise a pre-notification of a dispute. So a customer has said they will part pay an invoice. Rather than disputing the full invoice, a customer disputed object is raised so you can dispute part of the invoice (amount that will be unpaid)

In terms of the first two use cases you would not link these back to core FI-AR and therefore the closure has to be manual.

With the third process - the idea is that you start to resolve the issue and then when the customer does actually short pay, or not pay the invoice, that is then converted into a full dispute, or the residual item turns into a full dispute.

In FMCG there is also the process of a deduction - the customer will pay the invoice in full and then raise a debit note against you. This debit note needs to be disputed, and therefore you cannot dispute the original invoice, and it will close the dispute once the invoice is paid.

Former Member
0 Kudos

Hi Mark,

Your scenario 1 , I assume is a CDIS case that has no AR items. I really can't think of a scenario to create a case with no AR like that but I know it's possible. Perhaps the customer calls with a general complaint not tied to any AR ?... I think all CDIS cases are supposed to be initiated by the customer. That is the key distinction. Every example that SAP provides, it's the customer initiating the CDIS case. I think that is important because then you can report how much AR is in dispute and how much of that was initiated by the customer. I've often thought that maybe they created this mostly for biller direct so that when the customer creates a dispute case it's classified differently. Do you agree that it's  supposed to be the customer initiating the CDIS cases ? I'm not sure I follow scenrio 2, but I know if you want to dispute credit items the system requires a CDIS case. In scenario 3, the original invoice would be linked to the case in the CDIS folder and the CDIS amount would be different. When the original invoice clears this case can be closed automatically because even if they shortpay the residual debit will get a new case. At our company all residual debits get a dispute case automatically after lockbox runs.

The reason our company needs a way to close these automatically is because we have thousands of them, too many to do manually. The system was designed in such a way that residual credits are getting cases after the lockbox runs. That means all unapplied cash is sitting in a CDIS case. I think I've finally convinced them to stop creating cases automatically like that for credits but we still have a ton of CDIS cases.

Another feature of CDIS is to create cases for cleared AR items. We are designing the program that auto-closes CDIS cases to skip certain categories. We wouldn't want to close a case if it was intentionally created with cleared AR items. So I agree that auto-closing does not make sense for all CDIS cases. And these will have to be closed manually.

The problem is that our AR people weren't really trained to know the distinction between CDIS cases and process integrated cases. And SAP doesn't do a great job of clearly explaining CDIS. But I have concluded that the key distinction is it should be initiated by the customer. As opposed to when a customer short pays , that is initiated internally. Interesting to hear your thoughts on the topic as it seems SAP just says here's this new functionality, it's more flexible. But doesn't really tell us the best practice for using it. Thanks,

Joe

Former Member
0 Kudos

OK if you have a deduction process, we have a solution for that.

However I always question the need to dispute cleared items

Former Member
0 Kudos

I suppose if the AR is cleared and for whatever reason they ask for a refund or credit it could be a reason to dispute cleared AR. I just know the business expressed an interest in the functionality when I showed them that cleared AR can go into a CDIS case.