Removing Operations

These operations take some Avatars as inputs, and have no outcomes.

Of course, since Anyblok / Wms Base keeps the full history, technically, the incoming Avatars are not removed from the database. Rather, their state field is being set to past during execution.

Model.Wms.Operation.Departure

class anyblok_wms_base.core.operation.departure.Departure[source]

Operation to represent goods physically leaving the system.

Downstream libraries and applications can enhance this model with additional information (e.g., a shipping address) if needed, although it’s probably a better design for rich shipment representation to issue separate Models and relation tables.

TYPE = 'wms_departure'
after_insert()[source]

Either finish right away, or represent the future decrease.

cancel_single()[source]
depart()[source]

Common logic for final departure step.

execute_planned()[source]
id = <anyblok.column.Integer object>
input_location_altered()[source]

A Departure doesn’t care if its input changed locations.

Even if we have in the future Departures that check that the input location is a suitable one, they should do it at execution time, so that it’s still possible to plan a rough Departure from any location, that will have to be later refined to be executed.

obliviate_single()[source]

Model.Wms.Operation.Disparition

This Operation Model inherits from the following Mixins:

class anyblok_wms_base.core.operation.disparition.Disparition[source]

Inventory Operation to record unexpected loss of PhysObj

This is similar to Departure, but has a distinct functional meaning. Disparitions can exist only in the done state.

Fields and their semantics

id = <anyblok.column.Integer object>

Primary key.

Mandatory methods of Operation subclasses

after_insert()[source]

Put the input Avatar in the ‘past’ state