DynamicsSubs

  We all are aware of  'Complete' sales order functionality: which essentially completes a sales order by making differential payments, added to line. It submits the command by sending out a nudge to payment lines (CustPaymTable [if any]), by checking out the changes/added/removed from sales inventory/work added and then either closes the transaction by either authorizing the transaction or by failing it by declining the same: Suppose, you have a situation, where you need to automate this, by reading from some staging table, and then doing the needful to complete the payment. The following code explains the process:  MCROrderRecapStatus recapStatus =   MCREndOrder::orderRecap(_salesTable,                                                                         mcrSalesOrderTotals); Here you are calling the above shown form, (through code, we don't need to show it). Evidently, _salesTable is the sales table buffer with differential changes. And then getting the status of the

  While updating the delivery remainder through code, you must be aware of the following code, which is widely available in the Google market:  SalesUpdateRemain::construct().updateDeliverRemainder(salesLine2update,                                                                                         qty2Delv,                                                                                         qty2Delv); However, this won't help you, if you are working for a Call-center based client/retail clients/royalty clients . Retail clients have a facility known as: 'Complete' sales orders, which processes any payments or refunds, if you are making, from F&O.   Suppose I have ordered initially 5 qtys and want to receive only 3 out of them, scrapping the rest 2, I need to consequently update the same using delivery reminders. However, if you want to automate the same (some integration staging table from where a batch reads and updates the deliver reminder), then the above code

  Ever came across a situation, where you needed to process a voluminous staging record set, clubbing up similar records?  For example, we have a huge journal staging table, and we need to process journals records from it, and then post them along with. Or you have a big staging table, containing purchase lines, where you need to calculate the individual puchase price and update the lines and then after each purchase order is complete, you need to process some additional activity at the header level. This necessarily means that you have to split up the entire process, by grouping up Journal Id (or Purch Id as per the last example), feeding each group into one thread and then keep an eye on each thread: as it completes, you carry out the additional activity.   The above figure exactly explains this process, by subjugating itself, into groups of records and then assigning each of these groups to a parallely executing thread. And then waiting for the thread to be over. And then finally co