Uploaded image for project: 'mod-data-import'
  1. mod-data-import

Fill Rancher environment via sample data for EDIFACT invoice testing



    • Folijet Sprint 109, Folijet Sprint 110
    • 5
    • Folijet


      The main goal is to fill Rancher env via sample testing data. Some info about it:

      Scenarios to test:

      • Thin thread: An invoice with one-time orders, no adjustments, no currency exchange, all lines match to POLs, use the fund distribution from the POL)
      • An invoice with lines for one-time orders
      • An invoice with lines for ongoing orders
      • An invoice with invoice-level adjustments
      • An invoice with invoice line-level adjustments
      • An invoice with an exchange rate
      • An invoice with an acquisitions unit (the import user - is it part of an acq unit?)
      • An invoice with lines matching via vendor reference number instead of POL
      • An invoice with some lines matching via POL and some via vendor reference numbers
      • An invoice with some or all lines that do not match to POLs or vendor ref numbers (so the "else" field mapping logic for Description kicks in; if the invoice line is then linked to a POL, the POL title should update the invoice line description)
      • An invoice with an invoice line that matches to multiple POLs (no POL on the invoice, and the vendor ref number of the invoice line matches several POLs; in this case we would want the invoice line info to load without a POL link, and the user would link to the appropriate POL manually)
      • An invoice with a line that matches to an incorrect POL (so the invoice line needs to be unlinked and relinked to the correct POL, which will update the invoice line description and possibly fund distribution info)
      • An invoice with many lines that match to incorrect POLs (so the invoice lines need to be unlinked and relinked to the correct POLs, which will update the invoice line description, and possibly fund distribution info)
      • An invoice with fund distribution from the invoice, rather than the POL
      • An invoice that matches to POLs that do not have fund distributions (so the fund distribution info would need to be added manually to the invoice lines before approval)
      • An invoice with several invalid/missing POLs
      • An invoice with prices higher than available in the assigned funds (assigned budget will not have enough money in it; should not cause a problem until the invoice is approved, right?)
      • An invoice with lots of lines (serials renewal?)
      • An invoice that is a credit, or contains a credit (see Duke example in EBSCO folder)
      • A duplicate invoice
      • An EDIFACT file with multiple invoices in it (to be sure that they are broken into separate invoices with the proper invoice lines)

      TestRail: Results


          1. 20201205072029.TAMU-SER-PRINT
            6 kB
          2. 20201212072013.TAMU-SER-PRINT
            46 kB
          3. 20210109072016.TAMU-SER-PRINT
            31 kB
          4. 20210130072009.TAMU-SER-PRINT
            0.7 kB
          5. 20210206072019.TAMU-SER-PRINT
            24 kB
          6. 565780us20210108.edi
            2 kB
          7. 565780us20210115.edi
            2 kB
          8. 565780us20210122.edi
            3 kB
          9. 565780us20210129.edi
            2 kB
          10. 565780us20210205.edi
            2 kB
          11. 565780us20210212.edi
            3 kB
          12. 565780us20210219.edi
            3 kB
          13. 565780us20210226.edi
            1 kB

          Issue Links



                wwelling William Welling
                VRohach Volodymyr Rohach
                0 Vote for this issue
                3 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases