Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-1986

Suspend or delay orders



    • New Feature
    • Status: Draft (View Workflow)
    • P4
    • Resolution: Unresolved
    • None
    • None
    • None
    • Small < 3 days
    • Medium < 5 days
    • Thunderjet
    • 1
    • 57.6
    • R5
    • R4
    • R4
    • R2
    • R4
    • R4
    • R4
    • R4
    • R2
    • R2
    • R4



      Ongoing orders: Often orders are interrupted by unforeseen circumstances. These are not canceled as the vendor is still committed to fulfill them. This may result in multiple payments in excess of what has been received for subscriptions. This may also result in claims being sent unnecessarily if we are aware of the reason why we aren't receiving items. However, the claim being sent is often how we find out this order should be suspended.

      Onetime orders: The encumbrance will possibly need to be moved into the following year. The expected date must be changed/extended and information needs to be captured regarding why it was changed. Sometimes the vendor will not respond. As invoices may come in relating to multiple orders it is important to know that one of the lines on that invoice relates to something that has been suspended and should not be paid. However if the amount due is 0 for that line it should not matter.

      High-Level Requirements:
      Ability to indicate that activity surrounding an order which is not yet closed should cease until further notice.
      Capture the date on which this is done
      Capture the expected suspension end date
      Capture information regarding this activity

      TestRail: Results


          Issue Links



                dennisbridges Dennis Bridges
                dennisbridges Dennis Bridges
                0 Vote for this issue
                2 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases