Uploaded image for project: 'CFA MX '
  1. CFA MX
  2. CFAMX-22643

(2023R2) Signal Integration -> Transfers -> Receive Transfer API

    Details

    • Type: Story
    • Status: Closed (View Workflow)
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Links:
      Hide

      Story

      As a developer, I would like to expose an API so that a transfer can be received/denied outside of inform.

      Description

      the APIs will be created in ~\inform\Mobile\Mx.API solution

      For this story lets disable the Authentication. So that it will be easy to QA.  

      We will try to get a little data as possible from Signal side. That means we will have to do lots of property mappings so Redis caching would play an important role for the static data.

       

      This API endpoint will be used to Receive the transfer created from Signal side. So we will be receiving the transfer via signalTransferId (this should be introduced as a new column in transfer header). 

       

      Here is the sample request json: 
      {

        "Transfer": {

          "SignalTransferId": 553718,

         "SendingStoreNumber": “00440”,

          "ReceivingStoreNumber ":”00442”,

          "HeaderLevelComment": "some notes", // no required

          "Details": [

           

      {         "ItemCode": 1072236, // mandatory         "UnitCost": 3.0044, // mandatory         "TransferUnit1": "36 Lb Case", // mandatory         "TransferUnit2": "6 Lb Bag", // mandatory         "TransferUnit3": "Pound", // mandatory         "TransferQty1": 3,         "TransferQty2": 3,         "TransferQty3": 0,         "TransferQty4": 0,         "DeniedTransferQty1": "2",         "DeniedTransferQty2": "1",         "DeniedTransferQty3": 0,         "DeniedTransferQty4": 0,         "OriginalTransferQty1": 5,         "OriginalTransferQty2": 4,         "OriginalTransferQty3": 0,         "OriginalTransferQty4": 0,         "ItemLevelComment": 0, // optional field reason for declining                       }

          ],

          "DeliveryCheck":

      {       "CrossContaminationChecked": true, // mandatory when receiving       "TemperatureChecked": true // mandatory when receiving       }

        },

        "IsApproved": true, // true for Receiving and false for denying

        "IsTransferPartiallyDeclined": true, // mandatory

        "Reason": "" // optional

      Once the transfer is received or denied we will return ok status. 

      When implementing we shall try to reuse the same service layer to receive and deny transfers. 

       

      AC

      1. Confirm that the transfer is received/denied same way it is done through inform. 
      2. Confirm that partial Receive transfer working the same way with inform.
      3. Confirm that the the mandatory fields (in the example json) are required frields and valid
      4.  Confirm that all static data should be cached in Redis
      5. Confirm that  Received By field is populated with "Mx.Api" (or a better name, something that indicates the transfer is created  outside of inform)
      6. Confirm that the failure is logged as an error in the audit table 
      7.  Confirm that the exception details are returned from the API calls
      Show
      Story As a developer, I would like to expose an API so that a transfer can be received/denied outside of inform. Description the APIs will be created in ~\inform\Mobile\Mx.API solution For this story lets disable the Authentication. So that it will be easy to QA.   We will try to get a little data as possible from Signal side. That means we will have to do lots of property mappings so Redis caching would play an important role for the static data.   This API endpoint will be used to Receive the transfer created from Signal side. So we will be receiving the transfer via signalTransferId (this should be introduced as a new column in transfer header).    Here is the sample request json:  {   "Transfer": {     "SignalTransferId": 553718,    "SendingStoreNumber": “00440”,     "ReceivingStoreNumber ":”00442”,     "HeaderLevelComment": "some notes", // no required     "Details": [       {         "ItemCode": 1072236, // mandatory         "UnitCost": 3.0044, // mandatory         "TransferUnit1": "36 Lb Case", // mandatory         "TransferUnit2": "6 Lb Bag", // mandatory         "TransferUnit3": "Pound", // mandatory         "TransferQty1": 3,         "TransferQty2": 3,         "TransferQty3": 0,         "TransferQty4": 0,         "DeniedTransferQty1": "2",         "DeniedTransferQty2": "1",         "DeniedTransferQty3": 0,         "DeniedTransferQty4": 0,         "OriginalTransferQty1": 5,         "OriginalTransferQty2": 4,         "OriginalTransferQty3": 0,         "OriginalTransferQty4": 0,         "ItemLevelComment": 0, // optional field reason for declining                       }     ],     "DeliveryCheck": {       "CrossContaminationChecked": true, // mandatory when receiving       "TemperatureChecked": true // mandatory when receiving       }   },   "IsApproved": true, // true for Receiving and false for denying   "IsTransferPartiallyDeclined": true, // mandatory   "Reason": "" // optional }  Once the transfer is received or denied we will return ok status.  When implementing we shall try to reuse the same service layer to receive and deny transfers.    AC Confirm that the transfer is received/denied same way it is done through inform.  Confirm that partial Receive transfer working the same way with inform. Confirm that the the mandatory fields (in the example json) are required frields and valid  Confirm that all static data should be cached in Redis Confirm that  Received By field is populated with "Mx.Api" (or a better name, something that indicates the transfer is created  outside of inform) Confirm that the failure is logged as an error in the audit table   Confirm that the exception details are returned from the API calls
    • Sprint:
      2023.R2 Signal Int. Sprint 2, 2023.R2 Signal Int. Sprint 5
    • SCRUM Team:
      Globogym Purple Cobras
    • Story Points:
      5
    • Work Type Classification:
      Sustaining

      Description

      Signal Integration -> Transfers -> Receive Transfer API

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                caner.saritac Caner Saritac
                Reporter:
                caner.saritac Caner Saritac
              • Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 36h Original Estimate - 36h
                  36h
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 46h 32m
                  46h 32m

                    PagerDuty

                    Error rendering 'com.pagerduty.jira-server-plugin:PagerDuty'. Please contact your Jira administrators.