AR/AP Netting 10.2.600

Epicor ERP 10
1

Just curious how many of you are or plan to use AR/AP Netting introduced in 10.2.600.

Accounts Receivable and Accounts Payable netting process helps to combine and calculate a net balance of all AR or AP invoices with a certain business.

In many companies the supplier that provides services to a customer also acts as customer and vice versa. As a result, the supplier requires to do netting of the AP and AR transactions, in order to have all the debits and credits retrieved for netting. The same logic applies to customers.

Looks like there is a bug, even if you are not using Netting and you link a Supplier (Multi-Company) it populates Netting ID on the first Customer it can find, potentially when you try to use it you will get wrong reporting because NettingVendorNum on the first Customer it can find gets populated (probably bug).

Leaving this post here for any future person who finds discrepencies in numbers. (DMT Customer.NettingVendorNum and set it to 0 before you use Netting Functionality, if you are MC).

Epicor received our notes and have been notified.

2

I’ll create a bug for this later.

But the impact is greatly reduced, there are several steps in the process where you could easily find an incorrect link.

*When reviewing your Customer/Supplier when setting up Netting
*When creating a Netting Transaction you can see the Customer/Supplier on the Entry
*When selecting Invoices to Net you should realize the relationship is not correct

If you find anything else let me know :slight_smile:

1 Like
3

I narrowed the cause of the bug down server side assembly Erp.Services.BO.Vendor.dll

Bug Behavior

  1. In Supplier Maintenance link a Supplier from another company down (a supplier you didn’t link before)
  2. When you say yes to Create Supplier since it doesn’t exist, another instance of Supplier Maintenance will open, with the new record. Notice the Netting Customer ID is already filled out
  3. You click Save, it creates the record and updates the first Customer it can find commits NettingVendorNum to it.

The Bug occurs in step #2 in the base of LinkGlbVendor when it calls VendorAfterGetRows()

// The problem is that VendorNum is still 0 and not assigned.
CustomerPartialRow customer = FindFirstCustomerNettingVendorNum(CompanyID, ttVendor.VendorNum);
if (customer != null)
{
    this.ttVendor.NettingCustNum = customer.CustNum;
    this.ttVendor.NettingCustID = customer.CustID;
}

The problem is that VendorNum is still 0 and not assigned until the user clicks Save on the second Supplier Maintenance instance, only then is the Vendor commited via RowMod = “A”, yet the Customer has already been identified (oops).

The SQL that is ran is:

SELECT TOP 1 CustID, CustNum 
FROM Erp.Customer 
WHERE Company = 'ABC' AND NettingVendorNum = 0;

Of course the default of NettingVendorNum is 0, so it will find the first Customer it can and say “hey we are related”.

Temp Fix via BPM

You can create a BPM via Method Directives Erp.Vendor.LinkGlbVendor in the POST-Processing to set set the ttVendor columns to blank.

  // These columns are only avail in Tableset (temp) [Method Directive]
  ttVendRow.NettingCustID = string.Empty;
  ttVendRow.NettingCustNum = 0;
3 Likes
4

Thanks. This one and AP Invoice Cancellation are long overdue functionality which I would like to use.