• 6

    Give unit price with discount when quantity is greater than one (CalculateSalesDocument API endpoint)

    Suggested by Junior DUSSOUILLEZ – New  – 1 Comments

    Context: We use the Commerce (CSU) OData API to get prices and send orders in D365 from a home-made website.


    We are calling API endpoint "CalculateSalesDocument" to get prices for products. When there is a discount, we would like to get the discounted unit price to display it, even if the quantity is greater than 1.


    Example: my product price is 3.27€, with a 15% discount. My discounted unit price is 2.78€.


    When I call the API for quantity 1, no problem, I use "ExtendedPrice" to get the discounted unit price. But when quantity is greater than 1, I can't get the "2.78" value. It's not in CalculateSalesDocument endpoint response. Would it be possible to add it? It's very important value IMO.


    POST xxxx/Commerce/CalculateSalesDocument
    Content-Type: application/json
    {
      "salesDocument": {
        "Id": "CalculateSalesDocument",
        "CustomerId": "CS000003",
        "CartLines": [
          {
            "ProductId": 5637197959,
            "Quantity": 1,
            "UnitOfMeasureSymbol": "Pcs"
          }
        ]
      }
    }


    Response:

    {
     "@odata.context": "...",
     "CartLines": [
      {
       "Quantity": 1,
       "Price": 3.27,
       "ExtendedPrice": 2.78,
       "TotalAmount": 2.78,
       "NetAmountWithoutTax": 2.78,
       "DiscountAmount": 0.49,
       "LineDiscount": 0.49,
       "LinePercentageDiscount": 15.000000000000000000000000,
       "PriceLines": [
        // ...
        {
         "RecordId": 5652434827,
         "Value": 3.27,
         "PriceMethod": "Fixed"
        }
       ],
       "DiscountLines": [
        {
         "EffectiveAmount": 0.49,
         "EffectivePercentage": 14.98,
         "Percentage": 15.000000000000000000000000
         // ...
        }
       ]
       // ...
      }
     ]
     // ...
    }


    When I change quantity to 2, I can't find "2.78" anywhere in the response.

    {
      "@odata.context": "...",
      "CartLines": [
        {
          "Quantity": 2,
          "Price": 3.27,
          "ExtendedPrice": 5.56,
          "TotalAmount": 5.56,
          "NetAmountWithoutTax": 5.56,
          "DiscountAmount": 0.98,
          "LineDiscount": 0.98,
          "LinePercentageDiscount": 15.000000000000000000000000,
          "PriceLines": [
            // ...
            {
              "RecordId": 5652434827,
              "Value": 3.27,
              "PriceMethod": "Fixed"
            }
          ],
          "DiscountLines": [
            {
              "EffectiveAmount": 0.98,
              "EffectivePercentage": 14.98,
              "Percentage": 15.000000000000000000000000
              // ...
            }
          ]
          // ...
        }
      ]
      // ...
    }


    Having "2.78" value in a new field "DiscountedUnitPrice" would be great.


  • 1

    Prevent Item Scanning During Payment on Self-Checkout

    Suggested by Khaled Mohamed Mohamed Hussein El Tahawy – New  – 0 Comments

    Currently, if a customer scans an extra item while the payment screen is active on self-checkout, the item remains in the cart and is processed after payment. This can lead to confusion and missed charges. The proposed change is to block all item scanning during the payment process, ensuring that no new items can be added once tendering has started. This will improve transaction accuracy, reduce errors.


  • 0

    Extension Version Display in Back Office

    Suggested by Jen Shanahan – New  – 0 Comments

    We have several hundred registers nearly 1,000. It's increasingly difficult to manage versions when we roll out new custom extensions.


    We really need the ability to see via the back office the register Extension versions. We are presently having to query via a powershell script daily to get the registers to report back the extension versions. In the back office on the register offline status we get the client version but would like columns to represent extensions as well. This would greatly improve the ability for us to manage the roll out of updates.


  • 0

    Support for broker chargers from POS Sales Sales Orders

    Suggested by Mirko Bonello – New  – 0 Comments

    The functionality that generates the broker claims should be aligned across all the commerce channels including unified pricing. This has a major business justification because the broker contract is an agreement with the vendor which must be honored, irrelevant if the customer re-sells the product to its customers via POS, via Call Center or via E-commerce. The vendor expects that the broker agreement is always honored including those transactions sold via the POS channel (both Call Center and POS are Retail Sales Orders so they should behave the same).

<div>Please <a id="ideaforum-signin-link" href="/SignIn?returnUrl=%2Finsider%2Fpublic-profile%2Fideas%2Fdynamics-retail%2Ffilter%2Fhot%2Fthis-month">sign in</a> to Post Ideas and Vote on Ideas.</div>

Search Ideas