slpa: consolidate the containers, then issue a gate pass for each - #41
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
502ff48 to
77686f3
Compare
6aa8bae to
461de68
Compare
ginaxu1
left a comment
ginaxu1
left a comment
There was a problem hiding this comment.
Not safe to merge.
The description still pairs this with OpenNSW/nsw-srilanka#367, #368 and #369, and still describes a sequential node 5 then a node 6 fan-out. The branch no longer matches that. slpa_workflow.json prepares SLPA_CONTAINER_SPLIT_BUILDER items and fans out slpa-container-branch, which runs consolidation then gate pass per container. That graph calls SLPA_CONTAINER_SPLIT_BUILDER, SLPA_CONSOLIDATION_RESOLVE, SLPA_CONSOLIDATION_DELETE, and the SLPA_CONSOLIDATION projector. Those are not on nsw-srilanka main. 368 and 369 only registered FETCH, SAVE, and GATE_PASS. The matching Go work is still open as OpenNSW/nsw-srilanka#392.
Merging the artifacts first would load a workflow whose first post-invoice step is an unregistered task type. StartSubTask would fail when it tries to run slpa-container--prepare-transform.
Suggested fix: land and deploy nsw-srilanka#392 in the same release as this PR, then merge this. Update the description so it cites #392 and the per-container branch, not 367-369 and a 5-then-6 layout the code no longer has.
Agree @ginaxu1 , Please keep this PR until last two PRs, related to SLPA get merged into nsw-srilanka. |
461de68 to
b52ad8a
Compare
a040e33 to
a14f209
Compare
a14f209 to
bdbe563
Compare
Two nodes after the invoice is settled, ending the SLPA flow where the consignment can actually leave: 1 ECDN, 2 service order, 3 approval, 4 invoice, 5 consolidation, 6 gate pass. Node 5 asks SLPA which containers are available under the CUSDEC serial and offers both sides to the trader. The pairing is theirs to make: a pre-advised container carries the real container number and a service order container the placeholder it was priced against, so the two never match and nothing here pretends to derive it. Submitting with nothing ticked re-runs the lookup rather than sending SLPA an empty request, which is also how the trader waits for a terminal that has not pre-advised anything yet. Node 6 fans out over what was consolidated, one branch per container, each carrying everything its call needs — a split child inherits nothing else. The trader gives the truck, driver and seal for that container; the container itself comes from the consolidation, so a pass cannot be asked for one SLPA never paired.
The macro flow now splits on the containers the trader put on the service order, one branch per container, each carrying that container from consolidation through to its own gate pass. It replaces the single form that covered every container followed by a separate gate-pass fan-out. Per branch: the consolidation view shows the service order container it owns, read-only, and a dropdown of the real containers SLPA is currently offering — rendered by the SLPA_CONSOLIDATION projector, since the list belongs to the consignment and to the moment. A container not yet pre-advised in Navis simply is not there; Check Again re-runs the lookup, so the trader completes the pre-advice and returns to that one task. A save the CMS refuses returns to the same choice with its reason. Once saved, a resolve step records the container by both of its names — the sqid the delete is addressed by, and the number the pass is requested by — and the branch opens its gate pass view: generate the pass, or delete the consolidation and choose again. Delete is offered only before a pass exists. Needs OpenNSW/nsw-srilanka's SLPA_CONTAINER_SPLIT_BUILDER, SLPA_CONSOLIDATION_RESOLVE, SLPA_CONSOLIDATION_DELETE and the SLPA_CONSOLIDATION projector, so the two land together.
… pass The gate pass step offered "Generate Gate Pass" and "Delete Consolidation" as two render actions, so the branch was driven by __command. Replace that with an "action" field on the form itself: the trader chooses generate or delete, and truck/driver/seal are only shown and only required for generate. The gateway now reads gpform.action. Also carry gate_pass_url out of the SLPA issue response through the branch workflow so the issued message can offer a download link, and register slpa-ecdn-submission in the trade split-items transform.
The step's copy still described the form it replaced. It told the trader to tick each container and set the service order container it goes with, but the per-container form has no ticks and shows the placeholder read-only: there is one dropdown, and the only choice is which real container this one is. The done message counted in the plural for a step that now consolidates one. The container field pointed at a "Check Again" button. No render config here declares a second handle, and this flow expresses an alternative as a form field rather than another button, so it now describes what actually re-runs the lookup: submitting without a choice.
bdbe563 to
91ce8d1
Compare
3 participants
Stacked on #26. Go side: OpenNSW/nsw-srilanka#392. Stacked on top of this: #67, which deletes the superseded gate-pass fan-out.
The two nodes after the invoice is settled, ending the SLPA flow where the consignment can actually leave:
The fan-out is per container, and it starts at node 5.
SLPA_CONTAINER_SPLIT_BUILDERturns the containers the trader put on the service order into one branch each, and that branch carries its container all the way through: consolidation, then its own gate pass. The count comes from the order rather than from what SLPA is holding, because the terminal pre-advises real containers as they arrive — so a branch exists from the start for a container whose real number does not exist yet. The trader completes the pre-advice in Navis and comes back to that one task; nothing else waits on it.This replaces the earlier shape, where node 5 showed one form covering every container and node 6 then fanned out over whatever had been consolidated, having to reconstruct which of them the trader kept.
Node 5 — consolidation. Each branch shows the placeholder it owns, read-only, and asks one question: which real container is this? The pairing is the trader's to make and cannot be derived — a pre-advised container carries the real number, a service-order container the placeholder it was priced against, so the two never match and nothing here pretends otherwise. The choice is a list rather than free text, because which containers are available belongs to the consignment and to the moment; the option's value is SLPA's sqid, since one answer keys the save, the delete, and — resolved back to a number — the gate pass. Submitting without choosing re-runs the lookup, which is also how a trader waits for a terminal that has not pre-advised anything yet.
Node 6 — gate pass. The trader gives truck, driver and seal; the container comes from the consolidation. The same form offers deleting the pairing to choose a different container, which is only available before a pass exists, since that endpoint takes the consolidation and everything hanging off it.
Refusals are per container. A save or an issue the CMS rejects returns the trader to that same step with the CMS's own reason. A mismatch on one container is not a mismatch on the rest.
Landing
This does nothing without OpenNSW/nsw-srilanka#392, which adds
SLPA_CONTAINER_SPLIT_BUILDERandSLPA_CONSOLIDATION_RESOLVEand removesSLPA_GATE_PASS_SPLIT_BUILDER. #67 deletes the five leftover node-6 fan-out artifacts, one of which still declares that removed plugin. All three land in one cutover somake clean && make devloads matching plugins and workflows.Verified
Every id resolves, no dangling edges, nothing unreachable or dead-ended, all gateway routes evaluated through the real
exprengine (exactly one edge taken in each state), and every markdown panel rendered with both full and sparse data with no<no value>leaking.