Entity model
How the entities are organized in return management.
Only the key entities and their field subsets are listed in the illustration below.
The mapping between RMA and SO, and between SRO rows and SO rows, is described here:
We have the following relationships between RMA, SO and SRO:
- One SO can have multiple RMA
- Each RMA could have 0 (when it is not approved and completed) or 1 SRO
SO -> RMA1 -> SRO 1
-"- -> RMA2 -> SRO 2
The relationship between SO and SRO rows looks like this:
| SO 1: |
Article |
Quantity |
Unit price |
Row total |
| Row 1 |
Item A |
2 |
$100 |
$200 |
| Row 2 |
Item B |
3 |
$150 |
$450 |
| |
|
|
|
|
| SRO 1: |
Article |
Quantity |
Unit price |
Row total |
| Row 1 |
Item A |
-1 |
$100 |
-$100 |
| Row 2 |
Item B |
-1 |
$150 |
-$150 |
Each SRO row will have a link to link back to the original SO row. In the example above, SRO row 1 will have a link back to SO row 1, which tells us the maximum number of items that can be returned.
Mapping items
The returned items are mapped to the original order row. This facilitates the calculations and makes it possible to find the unit return price. For cross referencing, each SRO row is matched to the corresponding original SO Row. This could mean that an individual RMA row results in multiple rows in the SRO
Sales return processing
Here is a class diagram with classes to manipulate RMA objects:
RmaService
A Litium API service that handles the RMA entity. This is a service class pattern for all new Litium entities.
IRmaBuilder
Builds an RMA, from a return slip or using the original order system id. Basic validations of quantities are made, since other returns from same order may have happened. This is to make sure that nothing is over-returned. Only the maximum amount a customer bought in the first place can be returned.
IRmaSroLookupService
This service returns the mapping between RMA, SO and SRO. It also allows the related entity system id to be fetched, without having to load the source entity.