Provide for quota-free import of in-store transactions ("take sale" / "cash and carry") for use in association with blind returns / refunds

Today, we may receive the return of an unit/sku which was purchased in-store (cash-and-carry, take sale. NOT an order...) to our distribution center, within a valid return window, with a request for a full refund to the original form of payment.

Because we cannot automatically link the inbound shipment to a valid in-store transaction (they are not present in OMS), this becomes a highly-manual process, to source the original in-store transaction from a separate, unconnected data store, and to manually adjust the refund amount from the "blind returns" pricebook (lowest price last x days) to the *validated* amount from the original in-store take-sale (NOT order.)

Additionally, because we do not have a record of the original payment authorization, even if the store is using the same payment gateway, we cannot refund with reference to the original authorization code, resulting in potential violations from the payment gateway for "unreferenced" refunds (ie. money laundering concerns.)

We cannot simply import all take sales as orders into OMS, given the very high transaction volume, consequent impact on quotas, and the fact that OMS played no role in a POS take-sale cash and carry transaction. They are however crucial as reference data to facilitate the refund of the same, as a harmonized OMS-based refund process, when store-purchased units are shipped back to DC by the customer.

Again, in-store ordering is not an issue here, only in-store take sales, for which OMS organically has no record.

Presumably this referential data store should be kept isolated from the order-based data store, given OMS will have no role in processing these transactions, but rather only requires the data for search and reference. A big-data type data store optimized for search and retrieval would likely be a good fit.