We are implementing payment registry for a customer, and we noted that when we apply a payment to an invoice, that payment doesn’t registry the parent order id (the order that generate the invoice).
So, we have two possible ways to understand this:
A payment can be applied to an invoice (related to an order), but the order must consider this payment in its payment information (perhaps actual behavior is a bug).
or
A payment can be related to an order and not to its invoice (as application of this payment) and can be applied to an invoice but not related to the original order.
If you’re trying to force Moqui to make it use a single Payment for an Order and an Invoice always, that’s going to be trouble because it’s not how the real world works. Often you’ll have a “promised” payment associated with an order that then gets used first on related invoices, but there is intentionally a many-to-many relationship between orders and invoices, and between invoices and payments.
If I’m misunderstanding your concern let me know. This one comes up now and then and sounds like what might be bothering you.
I understand this.
So, if we intend to find all the payments for a order, then we have to go through all the billing items , invoice items, and then finally get hold of all the payments. And then, actually, those payments, billings, invoices actually possibly including payment/billing/inovice info for other orders. Of couse, I noticed there is orderid in payment entity if I remember it correctly, and i am always confused about how should this orderId field in Payment entity be used？
This just bump into my head when i read this thread.
We do have the case where we generate an order, the customer places it and needs the invoice before making a payment through a bank deposit or transfer. We will apply the payment to the invoices, and eventually the invoices will be completely paid. So, while all items of an order are billed and its invoices completely paid for, the “Payment Information” section in the OrderDetail screen still shows 0 payments and allows us to add e.g. new credit card payments.
So there are 2 issues here:
we might be ending up requesting or accepting a second payment to an order
we will not be changing the order statusId to Approved if the business logic requires the order to be paid in order to do so.
As the payment application concept is only suitable to invoices and not orders, we currently cannot register when or how much of an order has been paid for. We only know this if there is a payment that was created precisely and only for that order, like in an online store during checkout.
We can, however, go through the route pointed out by @strand and calculate this information on the fly and determine how much of an order is actually paid and if the order is paid completely, allow the autoApproval process to change its status if the other criteria are met.
If we want the payment information presented in the OrderDetail screen to be accurate, we should calculate it based on OrderItemBilling information. Currently, only payments having the corresponding orderId field set are attributed to that order, and payments applied to an invoice that bills items from that order are ignored.