Troubleshooting: Resolving Packing Slip Errors on Stopped Sales Order Lines in Dynamics 365

Table of Contents

Overview and Error Details¶

When working within Dynamics 365 and attempting to process outbound shipments, users may encounter specific errors that prevent the completion of standard procedures, such as posting a packing slip. One such error is identified by the code SYS13203. This error specifically arises in scenarios related to the state of the associated sales order lines when a packing slip is being generated or posted, often in conjunction with warehouse management processes involving loads and shipments.

The system presents a clear message indicating the nature of the problem. Users typically see an error dialog containing text similar to the following:

Unable to post packing slip when stopping a sales order line after confirming the outbound shipment
A quantity cannot be picked.

This message points directly to a conflict between the state of the sales order line (being stopped) and the actions already performed on the related physical inventory movement (outbound shipment confirmation). The implication is that the system’s logic for processing packing slips is blocked because it perceives the line as being halted, even though the goods have conceptually left the warehouse.

Symptoms¶

The primary symptom is the inability to successfully post a packing slip for a load or a sales order after the related outbound shipment has been confirmed. This blockage occurs during the packing slip posting routine. The error message SYS13203 is displayed, explicitly stating that the action cannot be completed due to a stopped sales order line combined with a confirmed outbound shipment.

This issue prevents the finalization of the shipping process in Dynamics 365. Without a posted packing slip, the system cannot proceed to invoice the customer for the goods that have physically shipped. This leads to discrepancies between the physical inventory (shipped) and the system’s recorded state (not yet packed/invoiced), causing delays in billing, potential issues with inventory reconciliation, and a disruption in the order-to-cash cycle. The error specifically mentions that “A quantity cannot be picked,” which is a prerequisite for packing slip posting in many warehouse management configurations, further highlighting the system’s internal logic conflict.

Cause¶

The root cause of this error lies in the state of one or more sales order lines associated with the load or shipment you are trying to process. In Dynamics 365, a sales order line can be marked as “Stopped.” This ‘Stopped’ status is a control mechanism designed to halt any further processing of that specific line. Depending on the configuration and the specific reason for stopping, it can prevent actions like releasing to warehouse, picking, packing, or invoicing.

A common scenario leading to this issue involves a user deciding to stop a sales order line after the outbound shipment has already been confirmed. Why might a user stop a line? Perhaps the customer called to cancel part or all of their order. To reflect this cancellation, a user might navigate to the sales order line and set the ‘Stopped’ flag to ‘Yes’. However, if the goods for this order line were already included in a load that has undergone the ‘Confirm outbound shipment’ process in the warehouse module, the physical shipment has, in essence, already departed the warehouse.

Once the outbound shipment is confirmed, the system generally considers the physical movement complete from a warehouse perspective. The ‘Stopped’ status on the sales order line, intended to prevent future processing, now conflicts with this completed physical action. The packing slip posting process checks the status of the associated sales order lines. When it finds a line marked as ‘Stopped’, it interprets this as a directive to not proceed, even though the confirmed shipment indicates the goods are gone. This conflict triggers the SYS13203 error because the system cannot logically post a packing slip for a quantity that, according to the ‘Stopped’ flag, should not be moving forward, yet, according to the confirmed shipment, has already moved. The system’s check for a “pickable quantity” fails because the line is stopped, thus preventing the packing slip posting.

Understanding the Sales Order Process Flow¶

To fully appreciate why this error occurs, it’s helpful to understand the typical flow of a sales order through Dynamics 365, particularly when using advanced warehouse management functionalities:

```mermaid
graph TD
A[Sales Order Creation] → B{Order Confirmation};
B → C[Release to Warehouse];
C → D[Wave Processing];
D → E[Load Creation];
E → F[Pick Work Creation];
F → G[Picking Execution];
G → H[Packing (Optional)];
H → I[Load/Shipment Confirmation];
I → J[Packing Slip Posting];
J → K[Invoicing];

L[Stop Sales Order Line];
L --> C;
L --> J;

style L fill:#f9f,stroke:#333,stroke-width:2px;
style I fill:#f9f,stroke:#333,stroke-width:2px;
classDef highlight fill:#ffffcc,stroke:#333,stroke-width:2px;
class I,L highlight;

% Indicate the conflict point
subgraph Conflict Area
I --> J;
L --blocks--> J;
end

```
Diagram: Simplified Sales Order Process Flow in Dynamics 365 with Warehouse Management.

As the diagram illustrates, ‘Stopping’ a sales order line (L) is typically intended to prevent steps like ‘Release to Warehouse’ (C) or subsequent actions. However, if the ‘Stop’ action happens after ‘Load/Shipment Confirmation’ (I), the line state (L) conflicts with the completed physical process reflected by the confirmation (I). When you then attempt ‘Packing Slip Posting’ (J), the system checks both the confirmed shipment status and the line status. Finding the line ‘Stopped’ (L) while the shipment is confirmed (I) causes the conflict and prevents the packing slip (J).

The purpose of the ‘Stopped’ field is to give users control over the order’s progress. However, its timing is critical. Applying a ‘Stop’ after the goods are physically handled and confirmed as shipped creates this logical inconsistency within the system, as the physical action (shipping) cannot be undone by merely stopping the digital line record.

Resolution¶

The resolution for the SYS13203 error is straightforward once the cause is understood. To post the packing slip, the system requires that the sales order lines are not in a ‘Stopped’ state when it performs its validation during the posting process. Therefore, the solution involves removing the ‘Stopped’ status from the relevant sales order lines.

Follow these steps within Dynamics 365 to resolve the issue:

1. Navigate to the Sales Order: Go to Sales and marketing > Sales orders > All sales orders.
2. Find the Relevant Order: Locate and open the sales order that contains the lines linked to the load or shipment you are trying to post the packing slip for. You may be able to identify the sales order directly from the load or shipment details if those forms are accessible.
3. Access Sales Order Lines: Once the sales order is open, navigate to the ‘Sales order lines’ grid view.
4. Identify Stopped Lines: Scroll through the lines or filter the grid to find the lines where the ‘Stopped’ field is marked as ‘Yes’. This field is typically found on the ‘General’ tab within the details section of a sales order line. You might need to personalize the grid view or navigate to the ‘Line details’ fast tab for the specific line and check the ‘General’ section.
5. Unstop the Lines: For each line that is marked as ‘Stopped’ and is part of the confirmed shipment, change the ‘Stopped’ field value from ‘Yes’ to ‘No’.
   • Note: Ensure you are unstopping only the lines that are causing the conflict and are part of the confirmed shipment you need to process.
6. Save Changes: After changing the ‘Stopped’ status on the necessary lines, remember to save the changes to the sales order. This is usually done by simply exiting the line details or clicking a ‘Save’ button if available and necessary based on your D365 version and configuration.
7. Retry Packing Slip Posting: Once the sales order lines are no longer marked as ‘Stopped’, return to the load or sales order from which you were attempting to post the packing slip. Initiate the packing slip posting process again.

With the ‘Stopped’ flag removed, the system should now be able to validate the lines and proceed with generating and posting the packing slip successfully, assuming no other unrelated errors are present.

Handling Canceled Orders After Shipment Confirmation¶

As noted in the Cause section, a common reason for stopping a sales order line might be a customer cancellation. If you had to unstop the line to post the packing slip because the shipment was already confirmed, you now have a scenario where a packing slip has been posted for goods the customer canceled. The physical goods have likely left your premises (or are awaiting return). In this situation, you must handle the cancellation as a customer return rather than preventing the original shipment process.

Here are the typical steps to manage a return for an order line that was shipped but canceled:

1. Create a Return Order: In Dynamics 365, navigate to Sales and marketing > Returns > All return orders. Create a new return order. This is the standard way to process customer returns.
2. Link to the Original Order/Invoice: When creating the return order, you will link it back to the original sales order or, more commonly, the posted packing slip or invoice. This helps in tracking and ensures correct financial and inventory updates. You’ll specify the items and quantities the customer is returning (or has canceled and might return).
3. Specify Return Quantity and Reason: Enter the quantity of the item being returned/canceled. Select an appropriate return reason code (e.g., “Customer Cancelled,” “Customer Return”). Reason codes are important for reporting and analysis.
4. Generate RMA: A Return Material Authorization (RMA) number is typically generated as part of the return order process. This number is used to track the incoming return shipment.
5. Receive the Return: When the physical goods are received back into your warehouse (if applicable), the return order is used to record this receipt. This process can also integrate with warehouse management for directed put-away.
6. Quality Inspection (Optional): Depending on your setup, the returned items might go through a quality inspection process to determine their condition (e.g., salable, damaged).
7. Disposition: Based on the inspection or pre-defined rules, a disposition code is assigned. This code determines what happens to the inventory (e.g., return to salable inventory, scrap, quarantine) and influences the financial transaction (e.g., full credit, partial credit).
8. Post Credit Memo: Once the return receipt and disposition are confirmed, a credit memo is posted against the customer’s account. This reverses the financial impact of the original shipment/invoice for the returned items. This process effectively completes the cancellation and return cycle within the system.

Handling the situation as a return order is the correct procedure because it reflects the physical reality (goods were shipped, then returned) and ensures accurate inventory and financial records. Simply stopping the line after shipment confirmation and then trying to post the packing slip creates the logical inconsistency the system flags.

Further Considerations and Best Practices¶

To prevent this error from occurring frequently, consider implementing the following best practices:

• Process Adherence: Establish clear internal procedures for handling customer cancellations. Ensure that cancellations are processed before the related sales order lines are confirmed for outbound shipment or released to the warehouse. Communicate these procedures effectively to sales, customer service, and warehouse staff.
• System Alerts/Workflows: Explore setting up system alerts or simple workflows in Dynamics 365 to notify relevant personnel if a user attempts to ‘Stop’ a sales order line that is already linked to a confirmed shipment or load. This proactive notification can help catch the issue before it causes an error during packing slip posting.
• User Training: Provide comprehensive training to users on the impact of actions like ‘Stopping’ a sales order line at different stages of the order fulfillment process, especially in conjunction with warehouse management features. Understanding the flow described earlier can significantly reduce such errors.
• Review Stopped Orders Regularly: Periodically review sales orders with ‘Stopped’ lines to understand the reasons and ensure they are processed appropriately, either by resuming the order (if the stop reason is resolved) or processing as a return/cancellation correctly.
• Configuration Review: Review your warehouse management and sales order parameters to ensure they align with your business processes and provide appropriate controls or warnings where necessary.

By addressing the root cause (the timing of stopping the order line) and establishing clear procedures, organizations can minimize the occurrence of this specific packing slip posting error and maintain a smoother order-to-cash process. Recognizing that a confirmed shipment implies a physical action that needs to be reversed via a formal return process is key to correct system usage in these scenarios.

Do you have similar experiences with this error, or perhaps alternative solutions you’ve used? Share your thoughts in the comments below!