curryj
Well Known Member
We finally figured out that whenever we edit a customer rebate - e.g. to change the percentage - we are triggering a corruption of the rebate history data in the F4078. What we do is go into the price adjustment details, "expire" the current rebate as of a Saturday in the future, then create a new line in the adjustment details effective the following Sunday with an expiry date far in the future, reflecting the new percentage. Then we do exactly the same thing in the threshold.
The problem is that between the time we make that change and the effective date of the new rebate percentage, the system writes a separate line in the F4078 for every order line that goes through that attracts the rebate. It should write one new line and then update it with subsequent order lines.
We could just live with this, because the file isn't that big, and the rebates still get calculated, except that in amongst these multiple records there are typically some credits. The system doesn't create open rebate amounts for credits, so these all get ignored when we process rebates, and we end up overpaying the customers, or doing a big long reconciliation process to correct the rebates.
Bottom line - we submitted a SAR and Oracle isn't going to fix it because the system gives a warning that the data might be corrupted if we change the threshold dates, therefore it's functioning as designed. Their solution - set up new rebates when changes are necessary. This seems to be a dumb suggestion to me, and it certainly isn't practical for us.
I'm wondering if anyone else is having the same problem, and if they would be interested in joining with us to try to get the problem corrected?
Thanks
The problem is that between the time we make that change and the effective date of the new rebate percentage, the system writes a separate line in the F4078 for every order line that goes through that attracts the rebate. It should write one new line and then update it with subsequent order lines.
We could just live with this, because the file isn't that big, and the rebates still get calculated, except that in amongst these multiple records there are typically some credits. The system doesn't create open rebate amounts for credits, so these all get ignored when we process rebates, and we end up overpaying the customers, or doing a big long reconciliation process to correct the rebates.
Bottom line - we submitted a SAR and Oracle isn't going to fix it because the system gives a warning that the data might be corrupted if we change the threshold dates, therefore it's functioning as designed. Their solution - set up new rebates when changes are necessary. This seems to be a dumb suggestion to me, and it certainly isn't practical for us.
I'm wondering if anyone else is having the same problem, and if they would be interested in joining with us to try to get the problem corrected?
Thanks
