Skip to main content

Upload EDC Disconnection Data (T164)

Upload Electronic Dispensing Controller (EDC) disconnection and abnormal transaction logs to the EFRIS system. This endpoint records device disconnection events, communication failures, and abnormal transactions for audit and compliance monitoring. Request is encrypted; response is unencrypted.

Endpoint Overview​

PropertyValue
Interface CodeT164
Request Encrypted✅ Yes
Response Encrypted❌ No
Request Body[{ "deviceNumber": "...", "disconnectedType": "...", ... }]
Response FormatNULL (empty on success)

Flow Description​

  1. Client detects EDC disconnection event or abnormal transaction.
  2. Client collects disconnection details (device number, type, timestamp, remarks).
  3. Client submits disconnection log array via T164 with encrypted payload.
  4. Server validates device registration and logs the disconnection event.
  5. Server returns NULL response on successful logging.

💡 Tip: Upload disconnection logs periodically (e.g., every 15 minutes) or immediately upon detecting disconnection events. Maintain local log queue for offline scenarios and batch upload when connectivity is restored.

try {
    // Call T164: Upload EDC Disconnection Data
    $disconnectionLogs = [
        [
            'deviceNumber' => '208178192251887451',
            'disconnectedType' => '101',  // 101=TCS disconnected, 102=Abnormal Transaction
            'disconnectedTime' => '2025-02-19 10:00:00',
            'remarks' => 'Abnormal transaction detected'
        ],
        [
            'deviceNumber' => '208178192251887451',
            'disconnectedType' => '102',
            'disconnectedTime' => '2025-02-19 10:15:00',
            'remarks' => 'Communication timeout with controller'
        ]
    ];
    
    $response = $client->uploadEdcDisconnect($disconnectionLogs);
    
    // Response is NULL on success
    echo "✅ Disconnection logs uploaded successfully\n";
    echo "   Logs submitted: " . count($disconnectionLogs) . "\n";
    
} catch (\UraEfrisSdk\Exceptions\APIException $e) {
    echo "❌ Upload failed: " . $e->getMessage() . "\n";
    echo "   Return Code: " . $e->getReturnCode() . "\n";
    
    // Queue logs for retry on failure
    // $retryQueue->add($disconnectionLogs);
}

Request Structure​

{
  "data": {
    "content": "BASE64_ENCRYPTED_PAYLOAD",
    "signature": "JKQWJK34K32JJEK2JQWJ5678",
    "dataDescription": {
      "codeType": "1",
      "encryptCode": "2",
      "zipCode": "0"
    }
  },
  "globalInfo": {
    "interfaceCode": "T164",
    "appId": "AP04",
    "version": "1.1.20191201",
    "tin": "1000029771",
    "deviceNo": "TCS9e0df01728335239",
    "taxpayerID": "1"
  }
}

Request Fields (Encrypted Payload)​

FieldRequiredTypeLengthDescription
deviceNumber✅ YesString≤50EDC device serial number or identifier
disconnectedType✅ YesString (3)3101=TCS disconnected with Controller, 102=Abnormal Transaction
disconnectedTime✅ YesString20Disconnection timestamp (yyyy-MM-dd HH:mm:ss)
remarks❌ NoStringVariableAdditional notes about the disconnection event

💡 Tip: Multiple disconnection logs can be submitted in a single request as an array. Batch upload reduces API calls and improves efficiency.

Response Structure​

{
  "globalInfo": {
    "interfaceCode": "T164",
    "returnStateInfo": {
      "returnCode": "00",
      "returnMessage": "SUCCESS"
    }
  }
}

📋 Note: On success, the data.content is NULL or empty. Validation results are returned via globalInfo.returnStateInfo only.

Response Fields​

Global Info​

FieldRequiredTypeDescription
interfaceCode✅ YesString (5)Echoes T164
returnStateInfo✅ YesObjectContains returnCode and returnMessage

Return State Info​

FieldRequiredTypeDescription
returnCode✅ YesString00 = Success, otherwise error code
returnMessage✅ YesStringHuman-readable status message

Return Codes​

CodeMessageDescription
00SUCCESSDisconnection logs uploaded successfully
99Unknown errorGeneric server error
400Device does not existdeviceNumber not registered for this TIN
402Device key expiredDevice credentials expired; re-run T102
403Device status is abnormalDevice blocked or suspended
2924disconnectedType: cannot be empty!Missing disconnection type
2925disconnectedType: Byte length cannot be greater than 3!Disconnection type format error
2926disconnectedType: Invalid field value!Must be 101 or 102
2927disconnectedTime: cannot be empty!Missing disconnection timestamp
2928disconnectedTime: The time format must be yyyy-MM-dd HH:mm:ssInvalid timestamp format
2918deviceNumber: cannot be empty!Missing device number
2919deviceNumber: Byte length cannot be greater than 20!Device number exceeds limit
2920deviceNumber does not belong to youDevice not registered to authenticated TIN

💡 Tip: Error 2920 indicates the device number is registered to a different taxpayer. Verify device assignment via T168/T169 before uploading logs.

Common Use Cases​

  1. EDC Communication Monitoring
    Log TCS-controller disconnection events for network reliability analysis and uptime reporting.

  2. Abnormal Transaction Detection
    Record abnormal transaction events (e.g., incomplete dispensing, meter mismatches) for investigation.

  3. Compliance Audit Trail
    Maintain historical records of all EDC disconnection events for URA compliance audits.

  4. Offline Operation Logging
    Queue disconnection events during network outages and batch upload when connectivity is restored.

  5. Device Health Monitoring
    Track disconnection frequency per device to identify hardware or network issues requiring maintenance.

  6. Incident Investigation
    Correlate disconnection logs with invoice data to investigate transaction discrepancies or fuel leakage.

Integration Checklist​

✅ Validate deviceNumber is registered to current TIN via T168/T169 before uploading
✅ Ensure disconnectedTime format is yyyy-MM-dd HH:mm:ss
✅ Use disconnectedType=101 for communication disconnections, 102 for abnormal transactions
✅ Implement local log queue for offline scenarios with retry logic
✅ Batch multiple disconnection logs in single request to reduce API calls
✅ Log upload attempts locally for audit trail and debugging
✅ Handle NULL response gracefully (success = no content, check returnCode only)
✅ Implement exponential backoff for failed uploads to avoid rate limiting
✅ Cross-reference disconnection times with invoice timestamps for discrepancy analysis
✅ Monitor disconnection frequency alerts for proactive device maintenance