microsoft / microsoft/BCApps

[Bug]: Align Refund Shipping Line Handling with Order Shipping Mapping

Open
#7,847 4 comments 0 reactions 2 assignees View on GitHub

@onbuyuka is already working on this.

Since Jul 9, 2026.

AI-Triage Approved Team: Integrations
Dominant language
AL
Stars
683
Forks
459
Avg merge
3d 26m
Merged PRs (30d)
633

Description

Describe the issue

Codeunit 30246 Shpfy Create Sales Doc. Refund currently writes every refunded shipping charge as a G/L Account line posted to Shpfy Shop."Shipping Charges Account" and unconditionally calls TestField on that account.

This diverges from the sales order flow in codeunit Shpfy Process Order (CreateSalesLines, the shipping-charges loop), which:

  1. Looks up Shpfy Shipment Method Mapping by Shop Code + shipping title
  2. When the mapping's Shipping Charges Type is set, writes the line as that Type/No. (G/L Account, Item, or Charge (Item))
  3. Only falls back to Shop."Shipping Charges Account" when no mapping applies
    Result: Shops that represent freight as an Item (or Charge (Item)) on sales orders are forced to use a G/L account when creating refund credit memos, creating inconsistent shipping line shapes between orders and their corresponding refunds.
Expected behavior

When a refund credit memo is created with a shipping charge:

  • The system should look up Shpfy Shipment Method Mapping using Shop Code + RefundShippingLine.Title
  • If a mapping exists and Shipping Charges Type <> " ", the shipping line should be created as the mapped Type/No. (G/L Account, Item, or Charge (Item))
  • If no mapping exists or Shipping Charges Type = " ", the system should fall back to posting as a G/L Account line to Shop."Shipping Charges Account" (current behavior)
  • Refund credit memos should produce the same shipping line shape as the originating sales order
  • Shipping Agent Code and Shipping Agent Service Code should be propagated from the mapping
Steps to reproduce

When a refund credit memo is created with a shipping charge:

  • The system should look up Shpfy Shipment Method Mapping using Shop Code + RefundShippingLine.Title
  • If a mapping exists and Shipping Charges Type <> " ", the shipping line should be created as the mapped Type/No. (G/L Account, Item, or Charge (Item))
  • If no mapping exists or Shipping Charges Type = " ", the system should fall back to posting as a G/L Account line to Shop."Shipping Charges Account" (current behavior)
  • Refund credit memos should produce the same shipping line shape as the originating sales order
  • Shipping Agent Code and Shipping Agent Service Code should be propagated from the mapping
Additional context
  • Affected codeunit: ShpfyCreateSalesDocRefund.Codeunit.al — specifically CreateSalesLinesFromRefundShippingLines
  • Related codeunit: Shpfy Process Order (CreateSalesLines shipping-charges loop) — this is the order-side pattern to mirror
  • Table: Shpfy Shipment Method Mapping (table 30131) is keyed on Shop Code + Name, which covers both order and refund lookups
  • Risk: Low. New code is gated on the presence of an explicit mapping row; the default path is unchanged. Feature reuses an already-shipped table and the well-tested order-side pattern.
  • No schema changes required
I will provide a fix for a bug
  • I will provide a fix for a bug

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.