Notifier: Goods Receipt update

Functional documentation for the Aiden WMS purchase document update mapper (inbound).

This document describes what happens after the mapper is installed: how a WMS purchase document status update is written back to SAP Business One (B1) as a PATCH on the related B1 document. It is intended for end-users and functional consultants.

1. Overview

This is a minimal status-sync integration. It does not create goods receipt POs, inventory documents, or lines. It only patches a status UDF on an existing B1 document (typically a purchase order).

What gets updated

Which B1 document is patched?

The Service Layer endpoint is built at runtime from WMS custom fields:

PATCH {cf_objectType}({cf_externalId})

Example from inputExample.json: cf_objectType = PurchaseOrders, cf_externalId = 9417 →

PATCH PurchaseOrders(9417)

with body:

{ "U_AEN_WMS_STATUS": "Started" }

2. What the mapper uses as input

2.1 Message shapes

The integration accepts two payload shapes. Custom-field paths differ:

After split (if any), MapForce expects a document-level object that includes at least:

• status — WMS status string (what is mapped)

• (optional on input schema) documentId, documentType, user — present but not mapped to B1 body

Other WMS fields (business partner, lines, saved lines, receive dates, etc.) may appear on real messages (see inputExample.json) but are not mapped into the B1 PATCH body.

2.2 External application id / correlation

There is no B1 GET enrichment step in this project.

3. Business behavior

3.1 Split multi-document messages

If the Kafka payload contains $.documents:

1. The route logs that an array of documents was received.

2. Each document is processed independently.

3. For each document: external id = that document’s documentId; custom fields from that document’s customFields.

4. Each document produces outbound Kafka traffic with its own PATCH endpoint.

If documents is absent, the single-message branch runs and reads nested document.customFields.

3.2 Status mapping (MapForce)

Any status string WMS sends is written as-is. Align allowed WMS statuses with what B1 users expect on the UDF.

Note on nested single-message payloads: MapForce’s input schema exposes status at the root of the object it receives. In the single-message example, root status is Started while nested document.status is Busy. The mapped UDF follows the root status of the JSON body passed into MapForce (after any split). For multi-doc splits, that is each document element’s own status.

3.3 Dynamic PATCH endpoint (Camel)

Before the parent route publishes with headers, Camel sets:

Consultant impact:

• cf_objectType must match a real B1 Service Layer collection.

• cf_externalId must be the correct B1 key (usually DocEntry).

• Single-message payloads must place these under document.customFields.

• Multi-document payloads must place them under each documents[].customFields.

• These fields are not produced by MapForce; they are read only in the Camel route for headers and external id.

3.4 Runtime publish behavior (for support/maintainers)

In the current MainRoutes implementation:

1. ROUTE_MAPPER runs MapForce, writes mapped status, and already sends the body to to.kafka.

2. The parent branch then sets PATCH headers and sends again to to.kafka.

Functionally, status mapping and the intended PATCH endpoint headers are defined as above. Maintainers should be aware of this double-publish path when troubleshooting duplicate Kafka messages or messages without headers.

3.5 What is intentionally not done

• No line, batch, serial, package, or expense mapping

• No creation of new B1 documents (PATCH only)

• No warehouse master or BOM logic

• No status translation table in MapForce

• Does not set native B1 DocumentStatus — only UDF U_AEN_WMS_STATUS

4. Field mapping tables

Columns: B1 target field | WMS / source input | What happens | Notes

4.1 PATCH body (MapForce)

4.2 PATCH routing (Camel — not in MapForce body)

4.3 Not mapped (examples)

Although the output schema lists a full B1 document shape, the following are not written by this mapper (non-exhaustive):

5. Value translations (reference)

5.1 Status

No closed/open prefix stripping and no valuemap in this project.

5.2 Endpoint pattern

5.3 Message handling

6. What is not mapped / important omissions

7. End-to-end expectation (happy path)

1. WMS updates a purchase document status (e.g. receiving started or document closed).

2. Integration receives Kafka message (single envelope or documents[]).

3. For each logical document:

   • Resolve cf_objectType / cf_externalId from the correct custom-fields path

   • Map root/document status → { "U_AEN_WMS_STATUS": "<status>" }

   • PATCH that B1 entity

4. B1 document shows the latest WMS status on UDF U_AEN_WMS_STATUS.

8. Example (from mappings/inputExample.json)

Scenarios under scenario_files/1_mainRoute are placeholders. Prefer this example.

WMS input (excerpt)

Expected B1 PATCH

9. Implementation checklist for consultants

1. For single-message payloads, put cf_objectType and cf_externalId under document.customFields.

2. For multi-document payloads, put those fields under each documents[].customFields.

3. Ensure cf_objectType is a valid B1 collection (e.g. PurchaseOrders).

4. Ensure cf_externalId is the B1 DocEntry of the document to update.

5. Align WMS status values with UDF reporting expectations in B1.

6. Remember this flow only updates U_AEN_WMS_STATUS — it does not post purchase receipts or stock.

7. Use documentId / XIAM external application id for support tracing.

10. Source artifacts (for reference)

Generated from the mapping definition and integration behavior in this project. If the MapForce mapping or routing changes, this document should be reviewed and updated.

Maintaining this document

For the original documentation intent, when to update, source-of-truth checklist, and a ready-made refresh prompt, see README.md and the repository AGENTS.md.