Update 27.2.202608.157159

This release updates the Intercompany app's dimension handling so that the options are predictable and aligned with standard Business Central behavior.

What has changed

The dimension handling dropdown is simplified to two options: 'None' and '1-1'.

'None' now truly means no Intercompany dimension synchronization between Sales and Purchasing. Dimensions on documents are then handled only by standard BC logic (vendor, item, customer defaults etc.).

'1-1' keeps the existing behavior where dimensions are passed through unchanged between companies (same codes, same values), regardless of whether a dimension is marked as an IC Dimension.

A new hidden boolean field 'Enable Legacy Dimension Mapping' has been added to Intercompany Setup. When visible and enabled together with 'None', it re‑enables the old behavior where IC Dimension / IC Dimension Value Map‑to fields are used between Sales Order and Purchase Order in the Sales company.

Key behavior

None (new behavior)

No dimensions are transferred from Sales Order to Purchase Order or on to the partner company.

Dimensions on documents follow standard BC rules only.

1-1 (unchanged)

All dimensions on the Sales Order are copied 1:1 to the Purchase Order and to the partner Sales Order.

Legacy (optional, for None only)

When 'Enable Legacy Dimension Mapping' is enabled with 'None', dimensions are mapped using the IC Dimension and IC Dimension Value Map‑to fields between Sales Order and Purchase Order, as in earlier versions of the app.

Compatibility notes

Existing customers relying on the old 'None' behavior can keep it by personalizing the Intercompany Setup page, showing the 'Enable Legacy Dimension Mapping' field and enabling it.

For correct behavior in multi‑company scenarios, all Intercompany partners should use the same dimension handling setting.

This change has been regression tested across typical Intercompany flows (standard IC transactions, G/L lines, multi‑line orders, drop shipments, returns and blanket orders) to ensure no unintended side effects when dimensions are not involved.

The check that prevents reopening a Sales Order on the supply company now uses the same rules for warehouse shipments and picks as already applied to normal (non-warehouse) shipments.

Previously, the check blocked reopening if any Warehouse Shipment Line or Warehouse Activity Line (pick) existed for the order. This had two problems:

A Sales Order could not be reopened while a warehouse shipment or pick document was open — even if nothing had been shipped or handled yet

A Sales Order could be reopened after the shipment was fully posted — because posted warehouse shipment and activity lines are deleted in Business Central, making the existence check ineffective

The check now evaluates actual quantities instead:

Reopen is blocked if Qty. Shipped (Base) > 0 on warehouse shipment lines

Reopen is blocked if Qty. Handled (Base) > 0 on warehouse activity lines

This mirrors the existing behaviour for normal shipments, where reopen is blocked based on Quantity Shipped on the Sales Line — and correctly handles both the partial and fully-posted scenarios.

We have corrected an outdated help link on the Intercompany Setup Guide Finish page. The link previously pointed to the old Zendesk documentation article and now directs you to the updated Abakion documentation at https://docs.abakion.com/docs/webservice-setup. This ensures users are guided to the current instructions for configuring web service and OAuth setup for Abakion Intercompany.

Added a new Intercompany event before purchase quantity validation in codeunit 6082631 "SCB IC Functions". The event is raised as part of the IC flow triggered by posting the final shipment in the Supply company and allows extensions to update the related sales order line quantity in the Sales company. The process can now increase the sales quantity to match the actually delivered quantity, as long as the new quantity is at least the quantity already received. Event added: OnAfterValidateQuantityPurchaseLine() (before purchase quantity check) in/around codeunit 6082798 "SCB IC Subscriber Events 647" / codeunit 6082631 "SCB IC Functions" to allow partner handling of quantity update when new Quantity >= Quantity Received.

Added new event OnPurchOrderReceiveFromICDocBeforePostReceipt (and/or after validating Qty. to Receive) to enable partners to update Unit Cost from IC inbox purchase line before posting receipt during IC purchase receipt processing. Events have been added to the IC purchase receipt process, specifically OnPurchOrderReceiveFromICDocBeforePostReceipt (and/or after validating Qty. to Receive). These events enable partners to set the Unit Cost from the IC inbox purchase line before posting the receipt, ensuring that cost prices can be updated accurately during IC purchase receipt processing. This change supports more precise cost management and integration scenarios for partners. This enhancement allows partners to set the Unit Cost on purchase order lines during intercompany purchase receipt processing by leveraging the new event OnPurchOrderReceiveFromICDocBeforePostReceipt. This provides greater flexibility and accuracy in cost price management for IC transactions.

In Intercompany (IC) Custom Fields, enum/option fields on lines were not handled correctly when the enum values were non-sequential (e.g. 0,1,5,7,10,...). On import, the IC logic mapped the incoming caption back to the position in the option caption list instead of the actual enum value, which caused wrong values after reopening and re-releasing documents.

This fix changes the IC custom field import logic so that incoming captions are resolved to the real enum/option integer value using Config. Validate Management functions. The solution no longer assumes that enum values are sequential or equal to their position in the caption list. As a result, IC custom fields mapped to enum/option fields now behave correctly on both first release and subsequent reopen/release cycles, even when the enum uses non-sequential values.

Problem:

Intercompany (IC) Custom Fields did not handle non-sequential enum/option values correctly on import.

Export side: The IC logic sends the enum value as its caption/name (using Format(FldRef.Value())).

Import side (before fix): The logic searched the option caption list for the incoming caption and then assigned FromOptionNo - 1, i.e. the index/position of the caption, as the stored value.

This worked by coincidence for enums with sequential values (0,1,2,3,...) but failed when the enum had non-sequential values (for example 0,1,5,7,10,13,15,17,20) and the document was reopened, the value changed, and then re-released. In those cases, the target document ended up storing the caption position instead of the actual enum value, leading to mismatches between caption and underlying value.

Fix:

The EvaluateTextToFieldRef / IC custom field import logic has been updated to evaluate incoming captions for Option/Enum fields using Config. Validate Management codeunit functions. The caption is now resolved to the correct enum/option integer value defined on the field, instead of assuming that the enum values are sequential or equal to the caption index.

Effect

IC custom fields mapped to enum/option fields now correctly store the underlying integer value, even for non-sequential enums.

Reopen → change enum value → re-release scenarios are handled correctly: the target company receives the caption and resolves it back to the proper enum value.

This ensures consistent behavior for setups where IC custom fields are mapped to enums like the test enum "Test Logistic Status" on Sales Lines in App-UAT.

Summary

When posting a sales order from the SALES company with an IC buy-from vendor specified only on the sales line (not on the header), the system correctly locks the order and displays an error, indicating that posting must be done from the SUPPLY company. However, when posting multiple sales orders at once with IC buy-from vendor on the lines (but not on the header), the system allowed the orders to be posted without any error, leaving the corresponding orders stuck in the flow.

Solution

Batch posting of intercompany sales orders is now prevented when the buy-from vendor is not set on the sales header. The system now enforces the same error lock for multiple orders as it does for single orders, ensuring that orders remain locked in SALES and cannot be posted incorrectly.

How to Reproduce (Before Fix)

In IC SALES, create sales orders with no buy-from vendor on the header, but with IC buy-from vendor on the line.

Posting a single order correctly triggers an error and locks the order.

Posting multiple such orders at once would previously allow them to be posted, leaving the corresponding orders stuck.

Result (After Fix)

The system now blocks batch posting of such orders, ensuring consistent behavior and preventing orders from being left in an inconsistent state.

Still possible to post multiple unreleased Sales Orders if they are not managed by the Intercompany flow