Billing Block - Exclude Item from Credit Exposure?

[former_member787999]

At times there are technical issues which for one reason or another don't allow us to Bill (Invoice) our customers. They are rare however they do occur. They can range from an order with a payment card that is already partially invoiced yet now the card is expired to a systemic issue that simply won't allow us to bill the customer.  While we do manually create a FI-AR invoice in these cases so we account for Revenue and AR the issue we face is that the credit exposure is now incorrect as the Open Delivery/Billing document portion contains an invoice that in essence will never bill. Is there a way to assign a particular Billing Block and in doing so get it out of the credit exposure?

For example if a particular reason code is assigned to an open AR item and that Reason Code is flagged as a "Disputed Item" in configuration that amount is deducted from the overall credit exposure.  Looking for something similar but on the SD side. 

Alternatively is there a way to somehow update the underlying SIS structures (a custom program or something that changes the status of the Delivery so that it thinks the Delivery and Billing document are fully complete)?  I do recall seeing a note many years ago that would change the status of a Delivery so that it would think the Billing Document was Complete however I don't know if that updates the SIS/Credit Exposure values and if I recall if certain programs were run it would redetermine the document status and make it open again effectively negating the fix.

Ideally I'm looking for something straight forward in config but have been unsuccessful so I'm guessing nothing is there but would be interested to hear if other people had the same problem and if they were able to resolve it how.

TIA

[Former Member]

Hi,

You have to define reason for rejection with statistcial mark.

If statistical check is activated, item value will not be added to the header total.

This can exclude a particular item from credit check.

Regards,

Raja Durai

[andrea_brusarestelletti]

Hello,

  is  there a reason avoiding the usage of the "Reason for rejection" on the items affected? In that case the item wouldn't be considered anymore among the sales values.

I guess you can develop you own program that runs periodically and according to your criteria (i.e. al the documents with billing block set since more than let's say 30 days) are updated forcing the billing status as "Completed" and updates consequentely the Information Structures. It's not so nice as a solution, but if you are quite sure that those document will be opened for ever, I guess that you'll need anyway to think about a way to close them

Another suggestion could be to define a special ledger posted when you manually create the FI-AR invoice, and link this special ledger as credit active: it that way the corresponding amount would be written in the field "Special liabilities" and you can treat it like an advance payment (so it would reducec the credit exposure of the customer). I know it would be tricky,  since the "Sales order open value" will still contain the open sales order.

Best regards,

Andrea

[former_member787999]

Thanks for the reply. If an order is open than we would definitely assign a Rejection reason and problem solved. The problem is that as these Orders/Items are wanting to be billed they have for the most part been fully PGI'ed and we can't reject them anymore.

The SL is an interesting solution but as we're posting an invoice it seems that it would only double up the problem. We've already got an amount in the Open Billing consuming part of the exposure and when we add the FI-AR entry in it would just double it.  As it is we're already doubling it because it's counting it in the Open AR portion of the exposure.  Even if we tagged it as a Disputed Item that would make it so that it isn't double counted while the FI-AR item is open but it still doesn't address the Open Billing doc.

I'm not sure if forcing the Billing Status to complete would even update the SIS structure values but the concern I had with that approach was that I recall there was a program that would redetermine document status if run so even if we did forcibly complete it, it is possible that they would be made open again.  Still though that is an option we were considering looking at.

Thanks,

Dave