在odoo 15企业版中，部分用户反馈在打印销售订单的送货单时，生成的pdf文档有时会错误地显示客户的默认地址（通常是账单地址或主要联系地址），而不是实际指定的送货地址。这个问题具有随机性，难以复现，且常规的调试方法难以定位其根源，甚至第三方咨询机构也未能有效解决。
为了解决这一问题，首先需要对Odoo的送货单报告（report_deliveryslip.xml）及其相关数据模型进行深入分析。
送货单报告的核心模板位于stock模块的report_deliveryslip.xml文件中。初步检查发现一个名为div_outgoing_address的代码块，它看起来负责打印地址信息：
<?xml version="1.0" encoding="UTF-8" ?>
<odoo>
<template id="report_delivery_document">
<t t-call="web.html_container">
<t t-call="web.external_layout">
<t t-set="o" t-value="o.with_context(lang=o._get_report_lang())" />
<t t-set="partner" t-value="o.partner_id or (o.move_lines and o.move_lines[0].partner_id) or False"/>
<t t-set="address">
<div name="div_outgoing_address">
<div t-if="o.should_print_delivery_address()">
<span><strong>Delivery Address:</strong></span>
<div t-field="o.move_lines[0].partner_id"
t-options='{"widget": "contact", "fields": ["address", "name", "phone"], "no_marker": True, "phone_icons": True}'/>
</div>
<!-- ... 其它地址逻辑 ... -->
</div>
</t>
<!-- ... 其它报告内容 ... -->
</t>
</t>
</template>
</odoo>这段代码中，t-field="o.move_lines[0].partner_id"似乎是获取送货地址的关键。然而，经过进一步分析，发现这个div_outgoing_address实际上是用于显示发货方（即我们自己的仓库或公司）的地址，而非客户的送货地址。这是一个容易引起混淆的命名。
为了确认销售订单和拣货单中的地址信息是否正确，我们可以在Odoo Shell中对一个出现问题的销售订单进行测试：
# 假设销售订单编号为 'S12345'
In [1]: so = self.env['sale.order'].search([('name', '=', 'S12345')])
# 销售订单的客户ID
In [2]: so.partner_id
Out[2]: res.partner(XXXXXX,) # 客户主地址
# 销售订单的送货地址ID
In [3]: so.partner_shipping_id
Out[3]: res.partner(YYYYYY,) # 期望的送货地址
# 关联的拣货单
In [4]: pick = self.env['stock.picking'].search([('origin', '=', so.name)])
# 拣货单的关联伙伴ID
In [5]: pick.partner_id
Out[5]: res.partner(YYYYYY,) # 期望的送货地址
# 拣货单移动行的伙伴ID (通常是实际送货地址)
In [6]: pick.move_lines[0].partner_id
Out[6]: res.partner(YYYYYY,) # 期望的送货地址
# 打印该伙伴的地址，确认其显示正确
In [7]: print(pick.move_lines[0].partner_id._display_address())
Correct Contact Name
123 Correct Street
Unit 456
New York NY 01234
United States # 显示为正确的送货地址
# 检查是否应该打印送货地址
In [8]: pick.should_print_delivery_address()
Out[8]: True从Odoo Shell的测试结果可以看出，so.partner_shipping_id、pick.partner_id和pick.move_lines[0].partner_id都正确地指向了预期的送货地址（YYYYYY）。这表明数据本身是正确的，问题可能出在QWeb报告的渲染逻辑上。即使手动调用_render_qweb_html等方法，生成的PDF依然显示错误的客户地址，进一步印证了这一点。
经过进一步的模板分析，我们发现真正负责渲染客户地址的XML片段位于information_block中，特别是div_incoming_address：
<t t-set="information_block">
<div class="row">
<div class="col-7" name="div_incoming_address">
<t t-set="show_partner" t-value="False" />
<!-- ... 其他条件 ... -->
<div t-if="o.picking_type_id.code=='outgoing' and partner and partner != partner.commercial_partner_id">
<span><strong>Customer Address:</strong></span>
<t t-set="show_partner" t-value="True" />
</div>
<div t-if="show_partner" name="partner_header">
<div t-field="partner.commercial_partner_id"
t-options='{"widget": "contact", "fields": ["address", "name", "phone"], "no_marker": True, "phone_icons": True}'/>
<!-- ... 其他信息 ... -->
</div>
</div>
</div>
</t>关键在于这一行：
<div t-if="o.picking_type_id.code=='outgoing' and partner and partner != partner.commercial_partner_id">
当拣货单类型为“outgoing”且partner存在时，如果partner与partner.commercial_partner_id不相等，则会显示“Customer Address”，并且更重要的是，它会打印partner.commercial_partner_id的地址，而不是partner本身的地址。
这意味着，如果我们的送货地址partner（即pick.move_lines[0].partner_id）与它的商业伙伴ID不一致，报告就会显示商业伙伴的地址。
为了理解partner != partner.commercial_partner_id为何会为真，我们需要查看res.partner模型中commercial_partner_id字段的定义和计算方法。
commercial_partner_id = fields.Many2one('res.partner', string='Commercial Entity',
compute='_compute_commercial_partner', recursive=True,
store=True, index=True)commercial_partner_id是一个Many2one字段，指向res.partner自身，用于表示该联系人的“商业实体”。
@api.depends('is_company', 'parent_id.commercial_partner_id')
def _compute_commercial_partner(self):
for partner in self:
if partner.is_company or not partner.parent_id:
partner.commercial_partner_id = partner
else:
partner.commercial_partner_id = partner.parent_id.commercial_partner_id这个计算方法逻辑如下：
结合QWeb模板的逻辑和commercial_partner_id的计算规则，问题的原因浮出水面：
对于那些送货单地址显示错误的销售订单，其对应的送货地址res.partner记录（即pick.move_lines[0].partner_id）被配置为“个人”类型（is_company为False），并且该“个人”记录设置了父级联系人，而这个父级联系人通常就是客户的“公司”主记录。
在这种情况下：
简而言之，当送货地址的联系人被设置为“个人”类型，且隶属于一个父级公司时，Odoo的默认送货单模板会错误地显示该父级公司的地址。
理解了问题的根源，我们可以考虑以下几种解决方案：
这是最直接且风险最低的解决方案。我们可以继承并修改report_deliveryslip.xml模板中的相关逻辑。
方案一：调整条件判断 修改div_incoming_address中判断是否显示“Customer Address”的条件，使其更精确地识别送货地址。例如，可以添加一个额外的条件，检查partner是否是o.partner_shipping_id或o.move_lines[0].partner_id，并优先显示其地址。
<!-- 示例：在原有逻辑前添加一个优先显示送货地址的逻辑 -->
<div t-if="o.picking_type_id.code=='outgoing' and o.should_print_delivery_address() and o.move_lines[0].partner_id">
<span><strong>Delivery Address:</strong></span>
<div t-field="o.move_lines[0].partner_id"
t-options='{"widget": "contact", "fields": ["address", "name", "phone"], "no_marker": True, "phone_icons": True}'/>
</div>
<div t-elif="o.picking_type_id.code=='outgoing' and partner and partner != partner.commercial_partner_id">
<span><strong>Customer Address:</strong></span>
<t t-set="show_partner" t-value="True" />
</div>
<!-- ... 原有逻辑继续 ... -->这个示例只是一个思路，具体实现需要根据业务需求和模板结构进行精细调整。目标是确保当存在明确的送货地址时，优先显示该地址，而不是回退到commercial_partner_id。
方案二：引入自定义字段 如果业务逻辑复杂，可以考虑在stock.picking或res.partner模型上添加一个自定义字段，明确标记某个联系人是否应该作为最终的送货地址，并在QWeb模板中根据这个字段进行判断。
修改送货地址记录类型 将作为送货地址的res.partner记录的is_company字段设置为True，并移除其parent_id。这样，这些送货地址记录本身就会被视为“公司”，其commercial_partner_id将指向自身，从而满足partner == partner.commercial_partner_id的条件。 注意事项： 这种做法可能会破坏原有的联系人层级结构，影响CRM或其他模块的逻辑，需要仔细评估其副作用。
修改父公司地址 直接修改父级公司记录的地址。但这并非解决送货地址显示错误的根本方法，因为送货地址和公司主地址可能需要保持不同。
定期审查和清理res.partner数据，确保送货地址的设置符合预期。例如，如果一个送货地址是公司的分支机构，可以将其设置为“公司”类型；如果是公司内部的一个特定收货人，则可以考虑将其作为主公司的子联系人，但要确保报告模板能正确处理。
解决Odoo 15送货单地址显示错误的问题，关键在于深入理解Odoo的QWeb报告渲染机制以及res.partner模型中commercial_partner_id字段的计算逻辑。当送货地址被配置为带有父级公司的“个人”类型联系人时，默认模板会错误地显示其父级公司的地址。通过调整QWeb报告模板，我们可以精确控制地址的显示逻辑，确保送货单始终显示正确的送货地址，从而避免业务流程中的混淆和错误。在进行任何修改之前，务必在测试环境中充分验证，以避免引入新的问题。
以上就是Odoo 15 送货单地址显示错误排查与解决方案的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
754
收藏
