Delivery Value Check

This document describes how and when the delivery value check is controlled for customer order deliveries.

Outcome

When this functionality is activated, the expected outcome is a customer order delivery either ready for issue reporting or not. If the delivery value check is successful or if the delivery is manually approved the delivery is ready for issue reporting, but if the delivery value check is not performed or failed, issue reporting will not be available for the delivery.

How the system is affected

  • When a delivery is created, it is set to issue reporting status=10 (delivery check not performed). This will prevent the delivery from being issue reported without a passed delivery value check or a manually approved delivery value check.
  • When all active picking lists are moved to a dock location, a delivery value check can be performed, either triggered manually using option 75 in (MWS410)/(DRS100) or automatically using the auto start job (MWS976). The result will be a delivery of issue reporting status=30 (failed) or 80 (passed via delivery value check).
  • A failed delivery value check must either be manually approved by the use of option 76 in (MWS410) (issue reporting status=90) or pass a manually triggered delivery value check in order for the delivery to be issue reported.

Before you start

Delivery value check must first be activated in 'Dispatch policy. Open' (MWS010), using these parameters:

  • The OAPYNO object must be used either in the parameter 540, Delivery consolidation field 1, or the parameter 545, Delivery consolidation field 2
  • Parameter 570, Delivery value check point, must be activated (value 1 or 2)
  • Parameter 580, Delivery value check method, must have a value of 1.

The payer responsible must be specified in 'Customer. Open' (CRS610/F).

Credit limit 2 must be specified per payer in (CRS610/J).

The proper settings for a dispatch process must have been made, including the move to dock step.

Purpose

The functionality of the delivery value check is used to reduce the risk of providing high value deliveries to customers whose payers are not solvent. To achieve this, issue reporting of a delivery (or part of it) is prevented if the delivery value check has failed or not been executed.

When

The delivery value check functionality is activated in (MWS010/I).

Delivery value check point – decides how and when a delivery value check should be triggered.

The delivery value check could be triggered manually after all goods have been moved to a dock location. It can also be triggered either manually or automatically when all goods are moved to a dock location for all active picking lists.

The automatically triggered delivery value check is controlled by using ASJ in (MWS976). Each time a picking list suffix is set to status 60 (on a dock location), a record is controlled by ASJ. If all active picking list suffixes are set to picking status=60, a delivery value check is triggered.

Note: When a picking list suffix is deleted or zero-reported (set to picking status =60), an additional validation is triggered. If the remaining picking list suffixes are set to picking status=60 and the delivery value check has not been performed, the delivery value check is performed.

When validated

The result of a delivery value check is an update of the field issue reporting status.

These are the possible values:

  • 00-Not activated
  • 10-Activated, not performed
  • 30-Performed, failed delivery value check
  • 80-Performed, passed delivery value check
  • 90-Manually approved delivery value check

If the functionality of the delivery value check is activated, the field issue reporting status is validated when any goods on a customer order delivery are reported as issued. This means that when a part of a delivery, a full delivery, or even a shipment including a delivery with this functionality activated is issue reported, the issue reporting status is validated. If the issue reporting status is not 00 (not activated), 80 (passed), or 90 (manually approved), issue reporting is not allowed.

The same validations are implemented when reporting issue through APIs.

How

To perform the delivery value check, these parts are required:

  • Actual delivery value – controlled by the method for delivery value check using a parameter specified in (MWS010/I). This parameter controls how the value of the actual delivery is calculated. In the current solution, the only available option is to use the net price method. This method calculates the value per line as a sales price deducts line discounts, multiplied with the quantity moved to a dock location. The calculated values will be summarized for all lines on all active picking lists.
  • Active credit limit 2 for the payer of all customer orders grouped on the same delivery.
    Note: To activate the functionality of the delivery value check, only customer order lines with identical payers can be grouped in the same delivery. This is performed by enforcing the use of the OAPYNO field as a delivery consolidation field.
  • Information collected about outstanding invoiced amounts for payers in the payers currency.

A delivery will pass the delivery value check if the following is fulfilled for the payers:

  • Credit limit 2 – Outstanding invoiced amount ≥ Actual delivery value

For issue reporting of goods from a delivery that failed a delivery value check, only these alternatives are available:

  • Manually approve the delivery

    There are many reasons for a manual approval of a specific delivery for issue reporting. This could be a delivery to a strategic, important consignee or the payer could be considered trustworthy at the moment.

  • Manually trigger a delivery value check

    After reducing the delivery content/value or changes of payers credit limit 2 or invoiced outstanding amount, a manually triggered delivery value check will perform a new check and update the issue reporting status according to the result.

Application messages

The result of a delivery value check can trigger different application messages:

  • Application message 276 – Delivery value check failed

    Message sent to the customer responsible set for the payer's record including details like delivery number, calculated delivery value, delivery value variance, payer currency.

  • Application message 277 – Delivery value check passed

    Message sent to the customer responsible set for the payer's record including details like delivery number, calculated delivery value, delivery value variance, payer currency.

  • Application message 278 – Delivery value check passed

    Message sent to the customer responsible set for the payer's record including details like delivery number, issue reporting status, payer.

Limitations

Before activating the functionality of the delivery value check, note these limitations:

  • The functionality is only valid for customer order deliveries.
  • The functionality is only valid for dispatch policies with auto level (TRLV)=3.
  • The delivery consolidation object OAPYNO must be used for delivery consolidation field 1 or 2.
  • Credit limit 2 must be active (>0) in order for the value check to be performed. A delivery will always pass the delivery value check if credit limit 2=zero.
  • All active picking list suffixes must be moved to a dock location before a delivery value check can be performed. The delivery value check is assumed to be one of the final steps to be performed before goods are loaded on a truck and/or reported as issued.
  • The delivery value of a picking list line is calculated using the same logic as is used today when calculating the pro forma value of a delivery. A value calculated per line as a sales price deducts line discounts, multiplied with the quantity for goods on a dock location for all delivery lines. No order charges, invoice discounts, or VAT are included in the delivery value amount
  • A delivery value check performed will close the delivery, regardless whether it has failed or passed. The reason for this is to prevent any additional goods to be added to the delivery after a delivery value check.
  • No automatic changes of the delivery value or issue reporting status is performed caused by changes of delivery contents, changes of prices/discounts on the included order lines, or changes of outstanding invoiced amounts for payers.
  • An automatically triggered delivery value check will only be performed the first time all active picking list suffixes are set to picking status (PISS)=60 (on dock location).
  • The existing M3 functionality to add customer order lines directly to existing picking lists cannot be used when a delivery value check has been performed.
  • If the load building functionality is active, a delivery value check must be performed prior to the goods being loaded to the shipment.
  • Packages in a delivery with the functionality of the delivery value check activated cannot be connected to a shipment package, for example using (DRS150).