-
True TABLE to GROUP to ALL Pricing
Business Central allows for the creation of multiple Sales Prices for a given Item/Customer combination, including for "Customer," "Customer Price Group," and "All Customers." This implies that BC supports true TABLE to GROUP to ALL pricing like other systems (most notably Dynamics AX, which we have been using for the last 10 years, and Dynamics GP, which we used for the 10 years before that): when entering a sales order, the system first looks for a TABLE (customer-specific) price, and if there is none, it looks for a GROUP (customer group-specific) price, and if there is none, it uses the ALL (base) price. Oddly, BC does not use this logic. Instead, as described in https://docs.microsoft.com/en-us/dynamics365/business-central/sales-how-record-sales-price-discount-payment-agreements#best-price-calculation and supported by our own testing, BC just looks at all the possible prices for an Item/Customer combination and uses the lowest price available. There is no prioritization of the TABLE to GROUP to ALL hierarchy. This would be fine if our TABLE price was always lower than our GROUP price and our GROUP price was always lower than our ALL price, however that is not the case: we are wholesale distributors, so we use ALL to hold our base “wholesale” price, but we also charge full retail to walk-in customers via GROUP “retail” (“retail” prices are of course higher than “wholesale” prices); we also factor freight into the prices for a few specific customers, so their TABLE prices are higher than the ALL prices. We propose that an option be added to BC base code to allow for true TABLE to GROUP to ALL pricing: for a given Item/Customer combination, if a "Customer" price exists, use that price...else if a "Customer Price Group" price exists, use that price...else use the "All Customers" price. Our partner is developing an extension for us to accommodate this functionality deficit, but we are of course concerned that future updates will wreak havoc with the extension. Although the current BC pricing structure surely works for many customers, we’re also sure there are other customers out there who would benefit from this proposal. Thank you for your consideration!
-
Parent vs. Child Report Logic in Document Layouts
We email a Confirmation Order for every sales order by specifying the Send To Email address in the DOCUMENT LAYOUTS for each customer. For most customers, this works exactly as expected and Confirmation Orders go to the address specified. However, we also have several “child” customer accounts with a separate “parent” Bill-to Customer No. (usually individual stores that belong to a larger chain). These child accounts place their orders with us directly and want to receive their own Confirmation Orders, so we specify the child’s email address in the child’s DOCUMENT LAYOUTS just like we would for a non-child customer record (one that does not have a Bill-to Customer No. specified). Unfortunately, BC doesn’t look to see if there is a destination specified for the child customer, and instead sends the Confirmation Order to the Send To Email specified in the parent’s DOCUMENT LAYOUTS settings. It seems to us that BC should look at the child DOCUMENT LAYOUTS first to see if there is a destination specified. If it sees one, it should use that, and if it does not see one, it should look to the parent DOCUMENT LAYOUTS. The existing logic that bypasses the child altogether may be sound for invoices (because the bill should obviously go to the parent), but it doesn’t work for situations like this where the child needs to receive a report that the parent doesn’t. It also seems to us that our proposed logic – first look at the child record and then at the parent record – would provide the flexibility to accommodate any customer scenario: If the Confirmation Order should go to the child, specify a destination on the child, and if it should go to the parent, specify a destination on the parent but not on the child. Similarly, if an Invoice should go to the parent, specify a destination on the parent and not on the child, and if it should go to the child, specify a destination on the child. Thank you for your consideration! -
Item Merge
BC allows "Merge With" on the customer and vendor table, but not on the item table. I think it would be incredibly useful to be able to combine duplicate item records into one.
You’re offline. This is a read only version of the page.
