[Bug]: Align Refund Shipping Line Handling with Order Shipping Mapping
Open
@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:
- Looks up
Shpfy Shipment Method MappingbyShop Code+ shipping title - When the mapping's
Shipping Charges Typeis set, writes the line as that Type/No. (G/L Account, Item, or Charge (Item)) - 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 MappingusingShop 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 toShop."Shipping Charges Account"(current behavior) - Refund credit memos should produce the same shipping line shape as the originating sales order
Shipping Agent CodeandShipping Agent Service Codeshould 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 MappingusingShop 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 toShop."Shipping Charges Account"(current behavior) - Refund credit memos should produce the same shipping line shape as the originating sales order
Shipping Agent CodeandShipping Agent Service Codeshould be propagated from the mapping
Additional context
- Affected codeunit:
ShpfyCreateSalesDocRefund.Codeunit.al— specificallyCreateSalesLinesFromRefundShippingLines - Related codeunit:
Shpfy Process Order(CreateSalesLinesshipping-charges loop) — this is the order-side pattern to mirror - Table:
Shpfy Shipment Method Mapping(table 30131) is keyed onShop 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.