web
You’re offline. This is a read only version of the page.
close
  • Use the Due Date on a Cash Flow Forecast Entry for a Purchase Order

    Currently, when a Due Date is manually typed in on a Purchase Order, the Cash Flow Forecast entry date is a recalculated date based on the Purchase Order's Payment Terms. For example, a user creates a Purchase Order with a Payment Terms of Net 30. Assuming the Document Date is March 1st, the Due Date defaults to March 31st. The user will manually override the Due Date to an arbitrary date (e.g. April 15th). When the user runs the Cash Flow Forecast, the entry date for the Purchase Order will be March 31st and not April 15th. Per Microsoft, this is current limitation where the Cash Flow Forecast recalculates the date based on the Purchase Order's Payment Terms. However, if a user does the exact same process for a Purchase Invoice, the Cash Flow Entry Date uses the manually typed in Due Date - this is what we would like for the Purchase Orders too.
  • Service Contract doesn't use Item's General Product Posting Groups GLs

    When a Service Contract is setup, it will only post to the sales GL mapped in the Service Contract Account Group Code. The issue with posting to the single GL associated in the Service Contract Account Group is that when there is a Service Contract with multiple Service Items, each Service Item can be mapped to Items that have different General Product Posting Groups (which we know drives the P&L postings in BC). There is no granularity of the Items sold and consumed when everything is linked to the one sales GL used in the Service Contract Account Group. Instead, the Service Contract postings should be driven based on the Item's General Product Posting Group so that it has consistency with the way Business Central drives postings for Sales and Purchase documents of Items.
  • Service Order Resource costs should post to the General Ledger

    When a Resource is posted on a Service Order, the entries posted will only DR. AR and then CR. Sales to the General Ledger (GL). It does not post the Resource Costs to the GL. I would expect it to record the costs to the GL that is associated with the Service Order. Without the costs, it's recognizes sales to the GL without costs and it requires someone to manually book an entry for the costs which is prone to errors (i.e. using the wrong GL, Dimensions, amounts, etc). Can we please look into posting the Resource Costs directly to the GL when a Service Order is posted?
  • Reversal of Job Journals

    For Job Journals that are posted, it current way to reverse them is creating a new Job Journal with the reversal amount.


    Rather than having a user rekey the reversal, it would be nice to select a Posted Job Journal and then have an Action or Process that allows them to reverse it automatically.

  • Have Resource's Work Type drive the GL Postings

    A few of our clients have asked for the ability for a Resource's Work Type to drive different General Ledger postings. For example, if the Work Type is for Regular Hours, they want it to post to the Regular Hours Wages in the GL. If the Work Type is Overtime Hour, they would like the amounts to post to the Overtime Hours Wages in the GL. Perhaps we can add the General Product Posting Group to the Resource Cost and Resource Price pages so that a General Product Posting Group can be linked to the Work Type on the Resource Cost and Resource Price pages. Therefore, when a Resource is used on a Job or Service Order with the Work Type selected, it will pull the General Product Posting Group to know which GLs to post to.


    We are open to any other ideas on how to get the Work Type to drive the GL posting; it does not need to be adding the Gen. Product Posting Group to the Resource Cost and Resource Price pages.

  • Default the Work Type on Resource card

    It would be nice to default the Work Type on the Resource card. The purpose of this is to populate the Work Type based on the Resource's default Work Type setting on a Job Journal, Time Sheet, Service item Worksheet, etc.


    For example, if the Work Types are Regular Time, Overtime, Double Time, and the Resource card has "Regular Time" as the default Work Type, then "Regular Time" Work Type should be defaulted on the transaction lines when a Resource is used.

  • Prevent reusing the same Document Number in a General Journal

    Some of our GP migration clients have brought up their concern over the ability to reuse a Document Number in a General Journal. The issue is similar to this community post: https://community.dynamics.com/forums/thread/details/?threadid=e402c201-4441-4d51-a9f5-337c9352f601


    Although we have suggested the answer from this post, our GP migration clients do not like the idea to have to constantly renumber their Document Numbers. They are hoping to have the Document Numbers to always be unique and for the system to determine the Document Number automatically especially if there are multiple General Journal batches.

  • Default GLs on Customer and Vendors do not carry over in a GP to BC migration

    In GP, a Customer and Vendor can have default P&L GLs assigned to them. This is similar to Business Central's Recurring Sales Lines and Recurring Purchase Lines. When we do a GP to BC migration, it would be nice to have these default P&L GLs auto create the Recurring Sales and Purchase Lines and assign them to the Customer and Vendor.


    Otherwise, when we do a GP to BC migration, we need to manually export the data from GP, create a Configuration Package to load them in and then assign them to the Customer and Vendor.

  • Be able to assign Allowed Currency Codes on the GL Account

    In GP, a General Ledger Account has the ability to assign which Currency Code(s) are allowed to be used in a transaction. The GP window is under Cards > Financial > Account Currencies. This function restricts users from posting transactions in Currencies that are not assigned to the GL.


    It would be nice to have something similar in Business Central as this has came up a few times in our GP to BC migrations. GP migration clients are asking for this because they have GLs that are currency specific. For example, they may have an AP GL that is for USD transactions only. Therefore, they would want only USD transactions posted to that AP GL.



  • Migrate open Sales Orders using the GP to BC migration tool

    When using the GP to BC migration tool, the open Sales Orders do not migrate over. It would be nice to bring the open/unshipped Sales Orders into Business Central.


    The expectation is to bring over the unshipped Sales Order lines to Business Central. Currently, when we use the migration tool, we have to manually calculate the unshipped quantity per Sales Order line and manipulate the GP SQL data to put it into a Config Package to load. It's an added step we need to do during the cut over period. It would be nice if it can be included in the migration tool since Purchase Orders already come over.