Payment Discount on Orderline, Invoice Candidate

[metas-mk]

Is this a bug or feature request?

Feature Request

What is the current behavior?

Currently, Payment Discounts are configured via Payment Terms. When an order is created the payment term is a mandatory field in order header. There is not possibility to create a payment term on orderline.

Which are the steps to reproduce?

Open, try and see.

What is the expected or desired behavior?

Provide the following functionalities:

• new field in orderline: c_paymentterm_id
• allow to record a payment term in discount schema
• if its set in discount schema and matched then update the paymentterm in orderline when setting the price
• add the paymentterm to invoice candidates from c_orderline
• adjust the aggregation header w/ payment term (make sure that different paymentterms lead to seperated invoices)

[cristinamghita]

Rough Concept

Column that needs to be added

• Add column c_paymentterm_id in C_Orderline
• Add column c_paymentterm_id in M_DiscountSchemaBreak
• Add column c_paymentterm_id in C_Invoice_Candidate

Modify Pricing area

• Extend org.adempiere.pricing.api.IPricingResult to support c_paymentterm_id
• modify org.adempiere.pricing.spi.impl.rules.Discount to inherit c_paymentterm_id from M_DiscountSchemabreak to C_Orderline

Update C_Orderline

• modify de.metas.order.impl.OrderLineBL.updatePrices(I_C_OrderLine) to set c_paymentterm_id in C_Orderline
  if was set in IPricingResult
• if is is not set, leave it null

Update C_Invoice_Candidate

• modify de.metas.order.invoicecandidate.C_OrderLine_Handler to inherit c_paymentterm_id from C_Orderline to C_Invoice_Candidate
• when the c_paymentterm_id is null, set the one from C_Order
• in case of fltrate term, we should inherit the c_paymentterm_id from C_Orderline ??? - talked with Mark: we ignore the case of FT; leave them are they are

Aggregation rule

• add a new aggregation rule that considers the c_paymentterm_id

[cristinamghita]

Dev tests

Order line with payment term

• Have a discount schema with a payment term
  • set this schema for product A
• Create an order for product A -> payment term from discount schema is set on order line OK
• IC genererated -> payment term from order line is set in IC OK
• Generate invoice
  • payment term is set in invoice candidate OK

Order with 2 order lines

• Have a discount schema with a payment term
  • set this schema for product A
• Create an order
  • add a line for product A -> payment term from discount schema is set on order line OK
  • add a line for product B -> payment term is empty OK
• IC genererated
  • IC with product A has payment term discount schema set in invoice candidate OK
  • IC with product B has payment term form order set in invoice candidate OK
• Generate invoice
  • we got 2 invoice with 2 different payment terms OK

Order with 2 products , just one product with discount, but the same packing material

• See the order lines
  
• See the shipment lines
  
• See the invoice candidates
  
• See the generated invoices - 2 invoices, each one having the correct line for the packing material and qty
  
  
  

[metas-dh]

Results of IT2
tested in release

• IC for TU is now created: OK
• 1 invoice for product & Gebinde: OK
• qty LU in IC = qty TU, e.g. 2, although only 1 LU was used (correct in material reeipt & shipment): NOK

[metas-lc]

IT
Case A

1. created sales order with 1 line, product without payment term override
   added TUs, created inout directly from shipment schedules
2. made invoice from candidates
   => OK: invoice is created with product and TU
   => qtys are correct in invoice and invoice cands

Case B

1. created sales order with 1 line, product without payment term override
   added TUs, created inout from picking terminal and using the action from shipment schedules
2. made invoice from candidates
   => OK: invoice is created with product and TU
   => qtys are correct in invoice and invoice cands

Case C

1. created sales order with 3 lines, 1 product without payment term override and 2 products with different payment terms (from discount schema)
   added TUs, created inout directly from shipment schedules
2. made invoice from candidates
   => OK: 3 invoices were created: 1 only with product (the one with the payment from order) and 2 with product and TUs (the ones with the payment override). The HU that was missing from the first invoice got into 1 of the other 2. I understood this is ok
   => qtys are correct in invoice and invoice cands

Case D

1. created sales order with 3 lines, 1 product without payment term override and 2 products with different payment terms (from discount schema)
   added TUs, created inout from picking terminal and using the action from shipment schedules
2. made invoice from candidates
   => OK: 3 invoices were created: 2 only with product (the one with the payment from order ,and another one that had payment term override) and 1 with product and TUs and LUs (HUs - the whole qty for all 3). The HU that was missing from the first 2 invoice got into the 3rd one. I understood this is ok
   => qtys are correct in invoice and invoice cands

note: created follow-up for C and D. Each TU shall stay with the product it contains. The LUs are fine to stay in another invoice: #3415

[metas-ts]

Cherry-picked to release