HemiKnowledge BaseHemiGeneral Information
Table of Contents
Related Articles
Knowledge Base
Hemi System Administration Integrations Hemi PRD Library Hemi Content Stream General Information Custom additions Core Integrations & Marketplace Documentation Hemi Advanced Functionalities Data Management MP Tokens generation Hemi Technology Trainings Hemi Platform Integrations Release Notes
FAQs

Architecture and Abstractions / Generic Marketplace claim store and behaviour [TBR

Generic Marketplace claim store and behaviour [TBR]

This document’s purpose is to describe how should we be storing the claim data(returns requests, cancel requests, etc.) if the marketplace supports it.

Claim body:

  1. As there can be more than one type of claim we need to know what was the claim type. Possible values:
  • Return
  • Cancel
  • Exchange

  1. As different requests can be initiated by different parties we would need to have this information. In the most common case the three different parties that can initiate the request can be the Buyer, the Seller, or the Marketplace.

  2. The next thing we would need to have is the Action that has been taken. Most commonly there are three types of actions:

  • Accept
  • Reject
  • Hold
  1. We need to have a Status in there so we can use it to define our different logics. Values should be as follows:
  • Pending
  • Sent
  • Completed
  • Error

Pending would be used when we download the claim but no Action has been taken.

Sent would be used when we have performed an Action and that Action has been sent to the Marketplace.

Completed would be used when we have received a response from the Marketplace that the Action has been successfully performed.

Error would be used if there an Error was either received from the Marketplace or an internal validation hasn’t been passed.

  1. The next thing would be to store the Status that the Marketplace has for the given claim.

  2. Marketplaces usually hold a separate ID for these Claims so we would need to be able to store it whenever available.

  3. Some Marketplaces would require a reason for an Action to be provided. We need to have a way of adding this Reason whenever required.

  4. Marketplaces usually would store what was the Reason for the initiation of the Claim. This is a separate Reason from the Action Reason. We need to be able to store this Marketplace claim reason whenever available.

  5. As some times we would need to be exporting these we need a flag to mark these Claims as Exported.

Claim row:

The claim row represents a specific quantity of specific SKU and is associated with order item line. In the claim row we must have he ability to assign separate tracking to each separate quantity so that is why we have against each order item line id, according tracking number.

Case for bundle SKU’s on order:

As we have bundle and component SKU’s we need to define a way of knowing for the specific claim row is it associated with a bundle SKU or with component SKU or with simple one that is neither bundle nor component.

We need to have this definition on claim row in order to be able do decide which rows we would like to export if needed.

Solution:

The information in claim row will be stored only for the Bundle SKU. The exports will be having the logic of getting the Component SKU within them when needed.

Is this article helpful?
0 0 0