This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

50 Returns

1 - Resy

1.1 -

1.1.1 -

Property Type Description

(Root)

object

returns.returnsAnnouncement.brain
data from Brain regarding returns announcements

    eventId*

string (uuid)

The uniq eventId
Global uniq Id

    eventTime*

string

Time of technical occurrence of the event
Time at which this record(event) was technically generated in RFC3339 format. Strongly recommended: in UTC time.

    eventType*

string (enum)

The concrete type = kind of record(event)
Type of the event. The possible values are defined as Enum

Any of: [ "INSERT", "UPDATE" ]
Minimum Length: 1
Maximum Length: 50

    traceId*

string (uuid)

The uniq traceId
Global uniq Id for tracing the flow of events

    version*

string

The number of version schema
Number of version of this data structure. Only required if no $schema is specified!

Regular expression: \d+\.\d{1,2}

    data*

object

        returnKey*

string

Retourenschluessel
surrogate key for one physical article that is part of this announcement

Minimum Length: 1
Maximum Length: 25

        announcementTime*

string (date)

announcementTime
time, when customer announced his return in ISO 8601-Format.

        shipmentTrackingNumber*

string

Carrier Tracking Number
trackingnumber for the parcel of the given returnKey

1.2 - R01 Shipment Registration

Status

In Production

Approval

  1. …​

  2. …​

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/shipmentregister/README

Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

Consumer

Consumer

2. Business Context

This event will take care in the receiving of the returns facility, when the package will be unloaded from the truck. The event can be triggered manually by a staff member or automaticly by a camera in combination with a conveyer. If the camera scans more the one barcode at a time, because there are many barcodes on the package, we will generate a message for each barcode!

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.3 - R02 Container Registration

Status

IN DEVELOPMENT

Approval

  1. DeepSea:

  2. AboutYou:

  3. Bonprix:

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/containerregister/README Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Inbound

InterfaceOwner

Producer

ReSy

OSP

Consumer

FLASH

Consumer

DeepSea

Consumer

AboutYou

Consumer

Bonprix

2. Business Context

This event will be triggered when a bin was unloaded in the returns facility.

It will collect all data from the bin and send it via KAFKA to differnt external systems.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.4 - R03 Container Manifest

Status

In Development

Approval

  1. …​

  2. …​

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/bintrackinghandler/README

Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Consumer

AboutYou

Consumer

Bonprix

Consumer

FGH

Consumer

Witt

Consumer

KR1

Consumer

COBRA

Consumer

WMSx/SON

Consumer

Warenverwertung

2. Business Context

The bin tracking handler is responsible for keeping track of all created bins (containers) and all items contained inside those containers. The service knows the current status and attributes of the container itself as well as of all of its content (e.g. item cancelled true/false) at any given time.

The bin tracking handler accepts incoming events from other services, e.g. about finalized bins, and creates an according business object for that container. This business object may be enhanced with additional information such as stack information.

This information can then be compiled in different forms for various purposes, e.g. for generating a container manifest, stocknotes for stockhandling, etc. and then forwards these events to the respective recipient.

Keeping track of items that are not part of a container (e.g. bulky items) is also handled by the bin tracking handler in the same way.

For clarification: Tracking of evaluation results is NOT done by this service.

This event will be triggered when

a bin was finalized
a QA bin was finalized
a bin was correced or canceled

It will collect all data from the bin and send it via KAFKA to differnt external systems.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS

Version

Number

File

Published on

Changes

5. Kafka Topics

Unresolved directive in <stdin> - include::../../../../integration-layer/topics/interfaces/R03.adoc[]

1.5 - R04 Bulky Item Manifest

Status

In Development

Approval

  1. …​

  2. …​

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/bintrackinghandler/README

Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

ReSy

Consumer

COBRA

Consumer

Warenverwertung

2. Business Context

The bin tracking handler is responsible for keeping track of all created bins (containers) and all items contained inside those containers. The service knows the current status and attributes of the container itself as well as of all of its content (e.g. item cancelled true/false) at any given time.

The bin tracking handler accepts incoming events from other services, e.g. about finalized bins, and creates an according business object for that container. This business object may be enhanced with additional information such as stack information.

This information can then be compiled in different forms for various purposes, e.g. for generating a container manifest, stocknotes for stockhandling, etc. and then forwards these events to the respective recipient.

Keeping track of items that are not part of a container (e.g. bulky items) is also handled by the bin tracking handler in the same way.

For clarification: Tracking of evaluation results is NOT done by this service.

The event will be triggered, when a bulky return was evaluated in the returns facility and will be given to the warehouse without a container (bin).

BULKY_ITEM_MANIFEST and CONTAINER_MANIFEST are in opposition to each other.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.6 - R05 Loading Manifest

Status

In Development

Approval

  1. FLASH:

  2. Heine-Zollsystem:

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/loadingoperation-backend/README

Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

ReSy

Consumer

FLASH

Consumer

Heine Zoll

2. Business Context

This backend:

  • Will initially open loadings, offer the possibility for general changes and complete loadings with a loading manifest (support for loading-manifest 1.0)

  • Will partially save the container manifest

  • Is working together with

  • Desktop UI → backfish_resy_loading-operation-ui

  • Handscanner UI → backfish_resy_loading-operation-handscanner-ui UI

Some fields have to be encrypted before insert the values to mongo database.

This event will be triggered when

a loading was finalized

It will collect all data from the staks and bin and send it via KAFKA to differnt external systems.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

5. Kafka Topics

Unresolved directive in <stdin> - include::../../../../integration-layer/topics/interfaces/R05.adoc[]

1.7 - R06 Stock Change

Status

In Production

Approval

  1. DeepSea/Retuna:

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/stockhandler/README

Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

ReSy

Consumer

Retuna

2. Business Context

The stock handler is in charge to keep track about all changes related to the quantiy of products of individual owners. Any change must be reported to the owner of the products. To keep track of all changes the current stock needs to be always present and the individual changes must be stored as stock history record. To get the corresponding stock accoutns, saying from which to what account a change has happened, the account setup (source → target) is defined per businesscase, hence the RESY components itself are not required to know about the individual stock accounts. All the components have to know is theirs own business process, the location where the changes has happend and what product was involved. To also allow the legacy system 'ROM' to report all changes, the service will map legacy specific values into RESY allowed value, f.e. definition of locations and owners. Any stock change will be reported via an event. How to calculate stock changes based on defined business cases is explain inside the use case definition.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.8 - R07 Return Order Contract

Status

In Production

Approval

  1. …​

  2. …​

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/returncontract/README Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

ReSy

Consumer

Consumer

2. Business Context

The service is in charge to receive any reported (by individual retailer) Return Order Contract (ROC) whereby the business object 'RETURNCONTRACT' will be generated. The service will take care about update features, saying only latest status of ROC will be performed. Whenever the Business Object 'RETURNCONTRACT' could be generated successfully, different outgoing Business Events are created, to inform retailer as well as all further RESY serices about a recieved and successfully performed ROC. Nevertheless the retailer will always reveive an acknowledgment about the status itself.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.9 - R07 ROC Acknowledge

Status

In Production

Approval

  1. …​

  2. …​

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/returncontract/README Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

ReSy

Consumer

Consumer

2. Business Context

The service is in charge to receive any reported (by individual retailer) Return Order Contract (ROC) whereby the business object 'RETURNCONTRACT' will be generated. The service will take care about update features, saying only latest status of ROC will be performed. Whenever the Business Object 'RETURNCONTRACT' could be generated successfully, different outgoing Business Events are created, to inform retailer as well as all further RESY serices about a recieved and successfully performed ROC. Nevertheless the retailer will always reveive an acknowledgment about the status itself.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.10 - R09 Returns Tracking Result

Status

In Production

Approval

  1. …​

  2. …​

Comment

Der Service ist aktuell beschrieben unter: https://docs.nonlive.backfish.platform.otto.de/#/./docs/services/returnstrackinghandler/README

Die Konsolidierung der Dokumentation ist in Arbeit.

Assumption

…​

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

Resy

InterfaceOwner

Producer

ReSy

Consumer

Consumer

2. Business Context

The service is in charge to receive any process tracking event of the returns process itself, whereby tracking also includes information about the evaluated product itself. Tracking events refer to the operational process and based on the operational process an evaluation has happened. Also, a just 'evaluation' process might happen. Some sensitive data are encrypted, before inserting to database.

3. Informationflow

to be defined

4. Interface

4.1. Direction HG to FINE

4.1.1. Header

4.1.2. Datamodel

4.1.3. Enumeration

4.1.4. Example

4.1.5. Schema

Table 1. Version ERP to FINE
Version Number File Published on Changes

4.2. Direction FINE to RESY

4.2.1. Header

4.2.2. Datamodel

4.2.3. Enumeration

4.2.4. Example

4.2.5. Schema

Table 2. Version FINE to WMS
Version Number File Published on Changes

1.11 - R20 Returns Announcements (internal for merchant OTTO)

Status

Released

Approval
Comment
Assumption

_

1. Stakeholder

Role Application Responsible

Communication

Integration Layer

Leading App

FLASH

InterfaceOwner

FLASH, Domain RT

Producer

BRAIN, Team Babelfish

Consumer

FLASH

Consumer

2. Business Context

Customers of merchant OTTO annouce their returns via a frontend. BRAIN consumes this data and provides the positions in charge (identified via returnKey that is also known in RESY) and the parcel-Tracking-Id for the returns-basket.

This data is useful to do a forecast of items heading to the return-warehouses.

3. Informationflow

flow

4. Interface

4.1. Direction BRAIN to FINE

4.1.1. Header

This interface uses the Service Header

4.1.2. Datamodel

Property Type Description

(Root)

object

returns.returnsAnnouncement.brain
data from Brain regarding returns announcements

    eventId*

string (uuid)

The uniq eventId
Global uniq Id

    eventTime*

string

Time of technical occurrence of the event
Time at which this record(event) was technically generated in RFC3339 format. Strongly recommended: in UTC time.

    eventType*

string (enum)

The concrete type = kind of record(event)
Type of the event. The possible values are defined as Enum

Any of: [ "INSERT", "UPDATE" ]
Minimum Length: 1
Maximum Length: 50

    traceId*

string (uuid)

The uniq traceId
Global uniq Id for tracing the flow of events

    version*

string

The number of version schema
Number of version of this data structure. Only required if no $schema is specified!

Regular expression: \d+\.\d{1,2}

    data*

object

        returnKey*

string

Retourenschluessel
surrogate key for one physical article that is part of this announcement

Minimum Length: 1
Maximum Length: 25

        announcementTime*

string (date)

announcementTime
time, when customer announced his return in ISO 8601-Format.

        shipmentTrackingNumber*

string

Carrier Tracking Number
trackingnumber for the parcel of the given returnKey

4.1.3. Enumeration

nothing special here

4.1.4. Example

4.1.5. Schema

Table 1. Version WMS to FINE
Version Number File Published on Changes

current version

1.0

Download

12.09.2023

final

previous version

coming version
Interface WMS to FINE
{
	"$schema": "http://json-schema.org/draft-07/schema",
	"$comment": "Schema for return announcements from BRAIN to FINE",
	"$id": "https://doc.fine.gcp.osp-dev.de/registry/Returns/ReturnsAnnouncement.Brain.v1.00.schema.json",
	"type": "object",
	"title": "returns.returnsAnnouncement.brain",
	"description": "data from Brain regarding returns announcements",
	"required": [
		"eventId",
		"eventTime",
		"eventType",
		"traceId",
		"version",
		"data"
	],
	"properties": {
		"eventId": {
			"type": "string",
			"format": "uuid",
			"title": "The uniq eventId",
			"description": "Global uniq Id",
			"examples": [
				"00ce536f-923a-42f4-8128-be118faf1d87"
			]
		},
		"eventTime": {
			"type": "string",
			"title": "Time of technical occurrence of the event",
			"description": "Time at which this record(event) was technically generated in RFC3339 format. Strongly recommended: in UTC time.",
			"examples": [
				"2016-04-16T16:06:05Z"
			]
		},
		"eventType": {
			"type": "string",
			"title": "The concrete type = kind of record(event)",
			"description": "Type of the event. The possible values are defined as Enum",
			"minLength": 1,
			"maxLength": 50,
			"enum": [
				"INSERT",
				"UPDATE"
			],
			"examples": [
				"INSERT"
			]
		},
		"traceId": {
			"type": "string",
			"format": "uuid",
			"title": "The uniq traceId",
			"description": "Global uniq Id for tracing the flow of events",
			"examples": [
				"00ce536f-923a-42f4-8128-be118faf1d87"
			]
		},
		"version": {
			"title": "The number of version schema",
			"description": "Number of version of this data structure. Only required if no $schema is specified!",
			"type": "string",
			"pattern": "\\d+\\.\\d{1,2}",
			"examples": [
				"1.01"
			]
		},
		"data": {
			"type": "object",
			"required": [
				"returnKey",
				"announcementTime",
				"shipmentTrackingNumber"
			],
			"properties": {
				"returnKey": {
					"type": "string",
					"title": "Retourenschluessel",
					"description": "surrogate key for one physical article that is part of this announcement",
					"maxLength":25,
					"minLength":1,
					"examples": [
						"417919950186"
					]
				},
				"announcementTime": {
					"type": "string",
					"format": "date",
					"title": "announcementTime",
					"description": "time, when customer announced his return in ISO 8601-Format.",
					"examples": [
						"2022-09-26T13:59:36.631+02:00"
					]
				},
				"shipmentTrackingNumber": {
					"type": "string",
					"title": "Carrier Tracking Number",
					"description": "trackingnumber for the parcel of the given returnKey",
					"examples": [
						"H12345678901234566789"
					]
				}
			}
		}
	}
}