Sales Order => Mixed POS Improvements

[Chuck Boecking]

Hi Everyone,

I am excited about the Sales Order => Payment Rule => Mixed POS option; however, it seems to be lacking functionality and consistency with how iDempiere works and thinks.

I am asking for feedback because I am going to ask Logilite to make the below changes, and I would like your feedback before I do.

Here are my thoughts:

• I believe that I should be able to specify a POS Tender Type => Payment Processor if the POS Tender Type => Tender Type = "Credit Card". This effectively allows me to choose the resulting Bank Account.
  
• I believe that I should be able to specify a POS Tender Type => Bank Account if the POS Tender Type => Tender Type = "Cash" or "Check".Otherwise, how else do I tell the system which Till/Register I am using?
• The Payment Rule = Mixed POS should behave the same as other payment rules where you can click the icon after order completion.
• The Mixed POS should NOT be coupled to order completion. Instead, the individual Sales Order => POS Payment should be processed individually in real time. This allows to keep a running total of how much is 'successfully' paid thus far. It also allows users to try a different option if an online payment is declined.
  
• It is possible to create a Sales Order window => "Standard Order" Document Type record where the Payment Rule = "Mixed POS Payment". The problem is that the system does not automatically created the resulting Payment records. Instead, the system just ignores the Sales Order => POS Payment records.

Thank you for your time and consideration!

Regards,


Chuck Boecking
512.850.6068 (office and cell)
ch...@chuboe.com
www.ChuckBoecking.com
chuck.boecking (skype)

@ChuckBoecking

http://www.linkedin.com/pub/chuck-boecking/10/970/17b

[Carlos Antonio Ruiz Gomez]

Hi Chuck,

Well, first to say is that this functionality was developed as a way to receive via web services a sales order coming from a POS system (f.e. Unicenta POS) or coming from a webstore.

So, for direct usage as a POS register is probably underdeveloped as you found out.

My 2¢ (but I'm not sure if I understood completely your proposals):

> I believe that I should be able to specify a POS Tender Type => Payment Processor if the POS Tender Type => Tender Type = "Credit Card".

> This effectively allows me to choose the resulting Bank Account.

The POS Tender Type is just the same list of Tender Type that you find in Payment, so, Payment Processor is not an option there.

The functionality is developed in a way that all payments end in the POS cash register.

It sounds an interesting addition to enable it to manage multi-bank/cash - but I think is just to add the optional column C_POSPayment.C_BankAccount_ID and use that one if filled.

But, I'm not sure if I understood here, what is the relationship with Credit Card here?

> I believe that I should be able to specify a POS Tender Type => Bank Account if the POS Tender Type => Tender Type = "Cash" or "Check".

> Otherwise, how else do I tell the system which Till/Register I am using?

I think the answer above applies also to this (but probably I didn't understand your idea)

> The Payment Rule = Mixed POS should behave the same as other payment rules where you can click the icon after order completion.

So, you mean that "Mixed POS Payment" doesn't require to fill the table below and it's filled after completion?

Sounds like interesting idea, at this moment it seems the user can change the payment rule after completion to "Mixed POS" but nothing happens there.

> The Mixed POS should NOT be coupled to order completion. Instead, the individual Sales Order => POS Payment should be processed individually in real time.

> This allows to keep a running total of how much is 'successfully' paid thus far.

> It also allows users to try a different option if an online payment is declined.

This is more tricky, AFAIK in iDempiere there is no prevision to process payments before order completion (except maybe the Prepay Order which requires some sort of "Complete and Wait")

Changing this is not about the Mixed POS, but sounds like a big different change to the way how payments work.

Think about that without the mixed POS tab, you would need to capture plain payments (no invoice, no order, no charge) - that can be done at this moment.

But then you would need to "allocate" those payments to the draft order - that's not possible at this moment, and additionally you would need to think how to manage the case where you got payments but form some reason the order cannot be completed and you need to reverse those in-advance payments.

This makes me think this is not about the Mixed POS functionality, but something more on the Payment side.

> It is possible to create a Sales Order window => "Standard Order" Document Type record where the Payment Rule = "Mixed POS Payment".

> The problem is that the system does not automatically created the resulting Payment records.

> Instead, the system just ignores the Sales Order => POS Payment records.

Yes, this was originally developed just for POS, but it sounds interesting to improve it to manage other cases.

Regards,

Carlos Ruiz

El 5/1/22 a las 15:54, Chuck Boecking escribió:

[Chuck Boecking]

Hi Carlos,

This is hugely helpful - thank you!

Here are my thoughts:

1. Direct use of Mixed POS (and the ability to directly capture multiple payment methods for a single order without using the dedicated Payment window)
   
   1. I believe it does make sense to build out for direct use
   2. I believe that all the development would be in the post-complete Payment Rule field icon popup that you get with all the other Payment Rule field controls
   3. We would just need a provision (system configurator) to allow for the Sale Order to complete without the Sales Order => POS Payment records present
2. The only other real issue I had the POS in implementation was the following
   1. We need the ability to process a Payment Rule = "Credit Card (offline)" Sales Order where the payment was not auth/captured in iDempiere
   2. This is an issue because iDempiere assumes that if you choose Payment Rule = Credit Card, that you always want to perform an online transaction
      
   3. This option would be for situations where someone captured a payment using a dedicated terminal or a webstore
      
   4. This option would allow you to choose set (1) bank account and (2) have a field to capture the transaction ID
3. The 'no modification' hack that I used to get around the offline credit card situation was to use Payment Rule = "Check" and paste the off line transaction ID in all three required fields.
   
4. I really like the addition of the POS Tender Type concept. iDeally, we would modify all post-complete Payment Rule field icon popup dialogs to chose the POS Tender Type instead of the actual Bank Account.
   
   1. This gives the integrator more options to set (or simply reference) more fields on the Payment (including the Bank Account) without needing to write customization code.
   2. It allows me to show the users more appropriate names/options in the drop down (instead of showing a list of bank account names)
      

The no-code alternative to the above is to simply create a Sales Order window => Receipt (C_Payment) subtab where the window is optimized to default as many field from the Sales Order as possible. The user simple sets the following fields as part of completing the Receipt:

1. PayAmt
2. Bank Account
3. TenderType
4. DocAction Button

Please let me know which (if any) of the above ideas are good for the core.

Thank you again for your time and consideration!

Chuck Boecking

www.ChuckBoecking.com

[entregpag Serv]

Alan

This process is the same as ours.  This process interests us.

Jorge Babo

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/316bd38a-fc89-4398-beeb-e0d7d33dd5f6n%40googlegroups.com.

[Norbert Bede]

Hi Chuck,

did you find a solution to your problem?

we are facing similar issue. we have REST API based POS app, and plan to use pos tenders tab for make plan of payment by combination of various payment methods.

 

Not sure, but looks the best solution would be start payment processor when  POS order has docstatus in-progress . When POS order to be completed payment will be created for Cash, and payment transaction invoke regular AR payment creation. at the end would looks as regular POS payment with mixed N payments (2). 

Norbert

[Chuck Boecking]

Hi Norbert,

I have not thought about this topic in 2 years. I do not remember how we solved it. I believe this thread was tied to an ERP Academy discussion. This probably means it never made it into production.

Regards,


Chuck Boecking
512.850.6068 (office and cell)
ch...@chuboe.com
www.ChuckBoecking.com
chuck.boecking (skype)

@ChuckBoecking

http://www.linkedin.com/pub/chuck-boecking/10/970/17b

You received this message because you are subscribed to a topic in the Google Groups "iDempiere" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/idempiere/Fz3Mxn2D_zw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/d531ea1e-71bd-4ad3-a667-8a2b3ae6f634n%40googlegroups.com.