Just in case anyone is wondering what went wrong:
SCOPE:
I understand that you're using Web Services for Dynamics GP 2013 to update sales batches. Whenever the order with a payment is updated you're noticing that a new entry is made in the GL module. For example, updating the batch an existing order is assigned to creates additional records in the GL10000 and GL10001 table.
ASSESSMENT:
Looking at your code it appears that you're actually changing the Customer PO Number to 'TEST". The Batch lines have been commented out.
I performed some testing, first with the Native example of UpdateSalesOrder from the SDK which just adds a comment to an existing order. This worked just fine for me, so I copied in your code and tested again. I just needed to change how you're passing the company ID and SOP Number. It ran and updated the Customer PO Number just fine.
When I compare the records in the GL10000 before and after I ran your code the number remained the same.
I was just working with a Sales Order without a payment, so I entered a payment on it. Once the Payment was entered and the Order saved a new line was written to the GL10000 and 2 lines written to GL10001.
I then ran your code again to change the Customer PO Number to TEST2. When I look at the GL10000 there are 2 new records and the GL10001 has 4 new records. It looks like the process of running that created 2 new GL batches, each containing the 2 distributions from my payment.
So it looks like I can reproduce your issue.
Looking at the Sales Payment Work and History (SOP10103) what appear to actually be happening is that the existing payment is being voided out and a new payment is created. Mine incremented from PYMNT000000000275 to PYMNT000000000276 when I ran another update to set Customer PO Number to TEST3. This also added another 2 and 4 records to GL10000 and GL10001 respectively.
This is expected behavior from eConnect in regards to payments and orders. Because payments on orders are posted on saving the document, eConnect removes the payments on the document before modifying it. To do this, it essentially reverses them out. Once the document is updated, it then recreates the payment again (with a new payment number). Everything should "net" out the same however there will be extra documents to process (the multiple payments now) due to this process.
When I looked at the resulting batches and the JEs that they hold it does appear that it is reversing out the transactions. For example, the first payment I entered against my Sales Order was for $100. When I look at that transaction it's a $100 credit against 000-1100-00 and a $100 debit against 000-2740-00. When I look at the JE associated with the next payment that has been created, SLSDP00000005, those values are flipped, essentially cancelling out the first JE. That's why 2 batches/JEs are created each time I update the order, one to cancel out the previous payment and another to create the new payment. While this means more batches to post everything should total out the same.
I have found two cases where the customer used straight eConnect, which has much more flexibility in terms of what can be sent to the XML without the behaviors and policies of Web Services altering things.
Another approach that I just saw, but have not tested, would be to handle the total payment on the order in your application code and then set this amount to the PaymentAmount property of the SalesOrder object. Since the Web Services XSLT file only looks at the PaymentAmount and not the DepositAmount, you would take the existing amounts and then add them to set the PaymentAmount. The below should make more sense. Then to avoid the existing payments to be voided you will null the existing Payments array.
Code snippets to retrieve and update an existing order with existing payments:
// Create a sales document key
salesOrderKey = new SalesDocumentKey();
salesOrderKey.Id = "FIORA0002";
// Retrieve the sales order
salesOrder = wsDynamicsGP.GetSalesOrderByKey(salesOrderKey, context);
decimal existingDepositAmount = salesOrder.DepositAmount.Value;
decimal existingPaymentAmount = salesOrder.PaymentAmount.Value;
if (salesOrder.Payments != null)
{
salesOrder.Payments = null;
}
Share
Report
All responses (
Answers (
292,863
