Wednesday, March 12, 2014

SOP Orders imported with eConnect auto allocate and auto fulfill

By Steve Endow

I received a call from a customer who has an eConnect application to import SOP orders.  The import was developed by another partner many years ago, and I inhereted it for ongoing support.  It has been working fine, but the client is changing their warehouse processes, and they want to use a separate fulfillment process for the imported orders.

No problem, except that the orders imported with eConnect  were automatically coming into GP as allocated and fulfilled, so they wanted to turn that off.  I checked the code for the eConnect import, and it was not set to auto allocate, and it was not specifying a quantity fulfilled on the line items, so I assumed it must be an option in GP.  But we then checked the Order setup options in GP, and it was properly setup to use a separate fulfillment process.

And to confirm that the issue was with the import, they manually entered an order, and it did not automatically fulfill.

I was puzzled.

We checked the GP settings again, and I checked the code again, but I still didn't see what was causing the fulfillment.

I then went back to the eConnect Help file and started searching for "fulfill".  Behold, on the taSopLineIvcInsert schema page, the word "fulfill" showed up on the DOCID field.  And to my surprise, here is what it says:

 Document ID; if left blank, line will autoallocate and fulfill

Huh, go figure.  Even though the DOCID was being specified at the Order Header, if you don't specify it at the line level as well, those lines will auto allocate and auto fulfill.

I checked the GP 2013 eConnect documentation, and it's the same.

That type of defaulting (to no Doc ID) would have never occurred to me, and seems a little odd.  I would have thought that the lines would default to the Doc ID used by the header, but apparently not.  This would explain the issue the customer was seeing.

After all the work that I've done with eConnect, I would thought I would have been aware of that--maybe I knew it at one point but forgot--but it's just another example of the depth and detail involved in ERP systems.  I continue to learn new things regularly...


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter


Tuesday, March 4, 2014

Delete Deductions? Um, Not So Fast.

Did you know you can delete a deduction assigned to an employee even if there is activity for that deduction?   As long as the activity is in a prior year, and the year end close for Payroll has been completed, Dynamics GP will allow you to delete the code from Cards-Payroll-Deduction.

Well, that sounds like an easy way to clean up your deduction list?  Just delete the ones that are no longer in use (they can't have any current year activity).  However, it is important to note that removing a deduction that was tax sheltered can cause issues.  The two that I have come across:

1.  Your 941 for prior years will be incorrect, as it will no longer have the deduction's TSA settings to refer to when calculating the taxable wages.
2.  There is no reliable method for determining the tax settings for the deduction once it has been deleted, so it becomes difficult to reconcile anything for the prior year.

Of course, both of these items are not an issue if you have completed your reconciliations and no further questions come up.  But if you are concerned about potentially having to revisit your filings and/or reconciliations for the prior year-- it is better to inactivate the deduction rather than delete it (even if there is no current year activity).

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.