In playing with the email document settings to meet a specific client need, it seems to be lacking somewhat in how you can send emails for specific document types.
This is a discussion I started in the forum: https://community.dynamics.com/gp/f/32/p/279898/800443#800443
Essentially, I think you should be able to link a document type e.g. Invoice or Delivery Docket to an address ID type rather than a specific address.
Invoice goes to the Bill To Address as defined on the Card OR
Invoice goes to the Bill To Address as defined on the transaction
Delivery Docket goes to the Ship To address as defined on the Transaction
The forum post has some screen shots to elaborate and a very basic indicator of what I believe is needed.
The scenario that drove this investigation was a client who has multiple store locations but one customer ID. The Ship To address is updated on each transaction.
When performing SBA calls against exposed Dex procedures, if the operation takes longer than 10 minutes the BackgrounInstructions stops and throws an InternalRequestError. The operation does seem to finish but throws an error. It would be nice to change the program so we have a longer time out than 10 min. Workaround is to break up the SBA operation to stay under the 10 min time out.
When posting an Inventory Batch, the Post to GL checkbox can be unmarked. This results in the HITB record having a 1900-01-01 00:00:00.000 GL Post Date value ( which would be correct, since it was never posted to the GL side ).
However, if you run HITB for a date prior to the Doc Date, the transaction will show up ( and should not ). It should show up on and after the Doc Date.
So printing by GL Posting Date needs to also consider the Document Date when the GL Posting Date is 'blank'
When a batch edit list is printed and interrupted, it can cause the batch to be put into batch recovery. When the batch is recovered, GP thinks that the batch was "posting" and finishes the posting process. This causes batches to post without workflow approval and can cause issues if the user has not had time to review the batch.
The Batch Recovery process should not post the batch, but rather finish printing the Edit List or the interruption of the Edit list printing process should not put the batch in batch recovery.
In GP 2013 we added a feature for Historic years in the Journal Entry Inquiry window, this works for all modules except for Project Accounting. Once you close your year in GL, the drill backs no longer work on the source document of PATS Journal Entries which are project accounting for the historical years.
Would be nice to have project accounting work like all other sub modules
In GP2015 or later, a feature was added to warn a user if a PO exists for a vendor that a payables transaction has been entered for. If you click the Go To button, the transaction you were working on gets deleted and the PO Navigation window is opened to view PO's for this vendor. The message does not appear until the save button or the post button is activated. If the transaction had multiple distributions added this information will be lost and the user would have to start over again if there was no PO and the transaction should be entered in the Payables Transaction Entry window. I suggest that the Go To button minimize the window and then bring up the PO Navigation window for the vendor instead of deleting the transaction.
Payables Transaction Approval Workflow - add GL distributions to Fields available in notification emailPayables Transaction Approval Workflow - add GL distributions to Fields available in notification email.
Having the GL distributions available to show in the notification email would eliminate most approvers from needing to drill into GP to approve from their email remotely.
When an EFT file for payables is sent to the bank, they deduct the entire summary amount from your account on one line. However, GP posts them as individual lines in bank rec, so reconciling is difficult and time consuming. And eBank Rec will not recognize them. My suggestion is to have GP post these to the checkbook in summary as that is how they are in our real checkbook at the bank.
Our work around will be to setup a dummy EFT checkbook to run these from and then do a transfer each time we run EFT's from live checkbook to dummy checkbook in summary. We should be able to add that BAI code to eBank Rec to reconcile it as a transfer as well.
Would like to have the option to implement a variance tolerance for SOP transactions. Currently, our industry has standards for both Vendors and Customers to allow for a +/- 10% variance. Currently, GP will allow this on the Purchasing side, but not the Sales side. This lack of function is causing our business to manually track variance on SOP side which is time consuming.