Determining who received the payment
Locked
Determining who received the payment
 
|
We are working on a report where we would show the identity of the user that actually received the payment (think brick and mortar POS). There is a user login tied to the OrderPreference record. Later when the payment is received and the payment entity is created, there is no longer a createdByUserLogin available.
Ultimately an invoice is created and payments are applied to that invoice, an acctgTrans entity is created and there is a createdByUserLogin attribute. However, it appears that this value is "system" (at least with our processing). So -- if we were to try to figure out who received a payment in general where in the data model would you expect to get that information. Is it missing or am I missing it or .... should the AcctgTrans entity have the value of the user that was logged in. |
Re: Determining who received the payment
|
|
the datamodel vol 1 page 266 (fig 8.2) show the Accounting Transaction
model. There are two transaction type, internal and external this show a party connected to the Originatedfrom for the external. The external is used for Sales Acct Transactions. Bob Morley sent the following on 7/13/2009 10:29 AM: > We are working on a report where we would show the identity of the user that > actually received the payment (think brick and mortar POS). There is a user > login tied to the OrderPreference record. Later when the payment is > received and the payment entity is created, there is no longer a > createdByUserLogin available. > > Ultimately an invoice is created and payments are applied to that invoice, > an acctgTrans entity is created and there is a createdByUserLogin attribute. > However, it appears that this value is "system" (at least with our > processing). > > So -- if we were to try to figure out who received a payment in general > where in the data model would you expect to get that information. Is it > missing or am I missing it or .... should the AcctgTrans entity have the > value of the user that was logged in. -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator. |
Re: Determining who received the payment
|
|
In reply to this post by Bob Morley
taking this to the POS level, Normally any data like who ran the
transaction at the POS is not carried into the normal accounting. This stays in the POS Journal. Reports for who did what on a particular POS is run on the POS Device (thinking in normal POS B&M) I have to go back and review how post journal works before I say to much. also it looks like Scott did some work on POS transactions so he may add something to this. BJ Freeman sent the following on 7/14/2009 2:29 AM: > the datamodel vol 1 page 266 (fig 8.2) show the Accounting Transaction > model. > There are two transaction type, internal and external this show a party > connected to the Originatedfrom for the external. > The external is used for Sales Acct Transactions. > > Bob Morley sent the following on 7/13/2009 10:29 AM: >> We are working on a report where we would show the identity of the user that >> actually received the payment (think brick and mortar POS). There is a user >> login tied to the OrderPreference record. Later when the payment is >> received and the payment entity is created, there is no longer a >> createdByUserLogin available. >> >> Ultimately an invoice is created and payments are applied to that invoice, >> an acctgTrans entity is created and there is a createdByUserLogin attribute. >> However, it appears that this value is "system" (at least with our >> processing). >> >> So -- if we were to try to figure out who received a payment in general >> where in the data model would you expect to get that information. Is it >> missing or am I missing it or .... should the AcctgTrans entity have the >> value of the user that was logged in. > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator. |
Re: Determining who received the payment
|
|
I think the problem stems from the fact that the "created_by_user" on the acctgTrans table is somewhat inconsistent. When a user records an incoming payment (for example) it will be set to that user's login id. When the payment gets applied to the invoice (through the quick ship mechanism) the creation of the invoice and application of payments is done through an ECA (createInvoicesFromShipment triggered from updateShipment) that is set to run-as system. This results in these transactions being created by the system user.
Based on your comments, I think this makes sense. The user that triggered the quickship did not explicitly create the invoice / apply payments (the system did in fact do that). Where as, when they are recording a payment they are clearly the person performing that action. The trouble was that our report designer looked at this table and deduced that the user would always be the logged in user. We made an assumption that changes over the last few months have changed how that field is being populated; but I have not found any evidence of that. So, I think from our perspective the only time an incoming payment is going to hit this accounting table is when it is manually recorded in our POS by the logged in user (this may not be true for payment gateway which we currently do not support). I am going to change our report to get the unique account transaction entity for the payment in question of type "INCOMING_PAYMENT" to determine the user that entered the payment. (Unless you would suggest otherwise -- I considered drilling back down to the order preference that started the whole process but decided against). However, I think we should consider an enhancement where we keep track of payment status changes much like we do for other entities in the model. That way we would have history of the payment workflow as well as the user that triggered those status changes. Unless I am missing something in the model (and I will grab my data modeling book shortly); and in fairness I have not focused on the payment mechanism in Ofbiz in tremendous detail. Thoughts?
|
Re: Determining who received the payment
|
|
In reply to this post by BJ Freeman
my comments are for the POS component of ofbiz.
the code for payment is in the org.ofbiz.order.shoppingcart.CheckOutHelper.java faceToFace = POS it puts payments in OrderPaymentPreference You referenced OrderPreference I think they are the same. CheckOutHelper.java is where the POS merges into the rest of ofbiz. I would say that the created_by_user is more to track how actually created the record, but not ment to track the party the did the transcation. By this I mean that who paid what, per the model. Now maybe you can use the order notes to put in the POS ID that handled the transaction, which I believe your using the created_by_user for. the PaymentGatewayResponse is only good for payments like CC or Paypal. it does not cover check, Cash, GiftCards. Bob Morley sent the following on 7/14/2009 7:48 AM: > I think the problem stems from the fact that the "created_by_user" on the > acctgTrans table is somewhat inconsistent. When a user records an incoming > payment (for example) it will be set to that user's login id. When the > payment gets applied to the invoice (through the quick ship mechanism) the > creation of the invoice and application of payments is done through an ECA > (createInvoicesFromShipment triggered from updateShipment) that is set to > run-as system. This results in these transactions being created by the > system user. > > Based on your comments, I think this makes sense. The user that triggered > the quickship did not explicitly create the invoice / apply payments (the > system did in fact do that). Where as, when they are recording a payment > they are clearly the person performing that action. > > The trouble was that our report designer looked at this table and deduced > that the user would always be the logged in user. We made an assumption > that changes over the last few months have changed how that field is being > populated; but I have not found any evidence of that. > > So, I think from our perspective the only time an incoming payment is going > to hit this accounting table is when it is manually recorded in our POS by > the logged in user (this may not be true for payment gateway which we > currently do not support). I am going to change our report to get the > unique account transaction entity for the payment in question of type > "INCOMING_PAYMENT" to determine the user that entered the payment. (Unless > you would suggest otherwise -- I considered drilling back down to the order > preference that started the whole process but decided against). > > However, I think we should consider an enhancement where we keep track of > payment status changes much like we do for other entities in the model. > That way we would have history of the payment workflow as well as the user > that triggered those status changes. Unless I am missing something in the > model (and I will grab my data modeling book shortly); and in fairness I > have not focused on the payment mechanism in Ofbiz in tremendous detail. > > Thoughts? > > > BJ Freeman wrote: >> taking this to the POS level, Normally any data like who ran the >> transaction at the POS is not carried into the normal accounting. >> This stays in the POS Journal. Reports for who did what on a particular >> POS is run on the POS Device (thinking in normal POS B&M) >> I have to go back and review how post journal works before I say to much. >> >> also it looks like Scott did some work on POS transactions so he may add >> something to this. >> >> BJ Freeman sent the following on 7/14/2009 2:29 AM: >>> the datamodel vol 1 page 266 (fig 8.2) show the Accounting Transaction >>> model. >>> There are two transaction type, internal and external this show a party >>> connected to the Originatedfrom for the external. >>> The external is used for Sales Acct Transactions. >>> >>> Bob Morley sent the following on 7/13/2009 10:29 AM: >>>> We are working on a report where we would show the identity of the user >>>> that >>>> actually received the payment (think brick and mortar POS). There is a >>>> user >>>> login tied to the OrderPreference record. Later when the payment is >>>> received and the payment entity is created, there is no longer a >>>> createdByUserLogin available. >>>> >>>> Ultimately an invoice is created and payments are applied to that >>>> invoice, >>>> an acctgTrans entity is created and there is a createdByUserLogin >>>> attribute. >>>> However, it appears that this value is "system" (at least with our >>>> processing). >>>> >>>> So -- if we were to try to figure out who received a payment in general >>>> where in the data model would you expect to get that information. Is it >>>> missing or am I missing it or .... should the AcctgTrans entity have the >>>> value of the user that was logged in. >> -- >> BJ Freeman >> http://www.businessesnetwork.com/automation >> http://bjfreeman.elance.com >> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro >> Systems Integrator. >> >> >> > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator. |
Re: Determining who received the payment
|
|
In reply to this post by BJ Freeman
in reviewing this more, i suggest fields FacetoFace (boolean) PosID(who
was at the POS),TermialID(which POS station) and faclilityID(where the pos station is located) to the OrderPaymentPreference and/or the payment entites. This could be a seperate entity as well then there would be a faceToFaceID in the OrderPaymentPreference and/or the payment entites this would be null if no POS entry was made. BJ Freeman sent the following on 7/14/2009 10:49 AM: > my comments are for the POS component of ofbiz. > the code for payment is in the > org.ofbiz.order.shoppingcart.CheckOutHelper.java > faceToFace = POS > it puts payments in OrderPaymentPreference You referenced > OrderPreference I think they are the same. > > CheckOutHelper.java is where the POS merges into the rest of ofbiz. > > I would say that the created_by_user is more to track how actually > created the record, but not ment to track the party the did the > transcation. By this I mean that who paid what, per the model. > Now maybe you can use the order notes to put in the POS ID that handled > the transaction, which I believe your using the created_by_user for. > > > > > the PaymentGatewayResponse is only good for payments like CC or Paypal. > it does not cover check, Cash, GiftCards. > > > Bob Morley sent the following on 7/14/2009 7:48 AM: >> I think the problem stems from the fact that the "created_by_user" on the >> acctgTrans table is somewhat inconsistent. When a user records an incoming >> payment (for example) it will be set to that user's login id. When the >> payment gets applied to the invoice (through the quick ship mechanism) the >> creation of the invoice and application of payments is done through an ECA >> (createInvoicesFromShipment triggered from updateShipment) that is set to >> run-as system. This results in these transactions being created by the >> system user. >> >> Based on your comments, I think this makes sense. The user that triggered >> the quickship did not explicitly create the invoice / apply payments (the >> system did in fact do that). Where as, when they are recording a payment >> they are clearly the person performing that action. >> >> The trouble was that our report designer looked at this table and deduced >> that the user would always be the logged in user. We made an assumption >> that changes over the last few months have changed how that field is being >> populated; but I have not found any evidence of that. >> >> So, I think from our perspective the only time an incoming payment is going >> to hit this accounting table is when it is manually recorded in our POS by >> the logged in user (this may not be true for payment gateway which we >> currently do not support). I am going to change our report to get the >> unique account transaction entity for the payment in question of type >> "INCOMING_PAYMENT" to determine the user that entered the payment. (Unless >> you would suggest otherwise -- I considered drilling back down to the order >> preference that started the whole process but decided against). >> >> However, I think we should consider an enhancement where we keep track of >> payment status changes much like we do for other entities in the model. >> That way we would have history of the payment workflow as well as the user >> that triggered those status changes. Unless I am missing something in the >> model (and I will grab my data modeling book shortly); and in fairness I >> have not focused on the payment mechanism in Ofbiz in tremendous detail. >> >> Thoughts? >> >> >> BJ Freeman wrote: >>> taking this to the POS level, Normally any data like who ran the >>> transaction at the POS is not carried into the normal accounting. >>> This stays in the POS Journal. Reports for who did what on a particular >>> POS is run on the POS Device (thinking in normal POS B&M) >>> I have to go back and review how post journal works before I say to much. >>> >>> also it looks like Scott did some work on POS transactions so he may add >>> something to this. >>> >>> BJ Freeman sent the following on 7/14/2009 2:29 AM: >>>> the datamodel vol 1 page 266 (fig 8.2) show the Accounting Transaction >>>> model. >>>> There are two transaction type, internal and external this show a party >>>> connected to the Originatedfrom for the external. >>>> The external is used for Sales Acct Transactions. >>>> >>>> Bob Morley sent the following on 7/13/2009 10:29 AM: >>>>> We are working on a report where we would show the identity of the user >>>>> that >>>>> actually received the payment (think brick and mortar POS). There is a >>>>> user >>>>> login tied to the OrderPreference record. Later when the payment is >>>>> received and the payment entity is created, there is no longer a >>>>> createdByUserLogin available. >>>>> >>>>> Ultimately an invoice is created and payments are applied to that >>>>> invoice, >>>>> an acctgTrans entity is created and there is a createdByUserLogin >>>>> attribute. >>>>> However, it appears that this value is "system" (at least with our >>>>> processing). >>>>> >>>>> So -- if we were to try to figure out who received a payment in general >>>>> where in the data model would you expect to get that information. Is it >>>>> missing or am I missing it or .... should the AcctgTrans entity have the >>>>> value of the user that was logged in. >>> -- >>> BJ Freeman >>> http://www.businessesnetwork.com/automation >>> http://bjfreeman.elance.com >>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro >>> Systems Integrator. >>> >>> >>> > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator. |
Re: Determining who received the payment
|
|
In reply to this post by Bob Morley
Bob, Which user is it that you would like to capture, the one who called the quick ship service? Are there other services that the user you want to track will call? Either way I guess you have 2 options: 1. trace down through the service you know the user will call to see if/where the user information is saved and change your report to look there 2. decide where you'd like the information to be saved (perhaps based on your current report) and change functionality to pass that down to where it needs to go and make sure it is saved in the place you want If you go with #2 please feel free to submit the change in a Jira issue. It might actually be nice in cases like this to save the original user and not the "system" user. That would be done in a separate variable since in many of these cases the system user is needed because the system is automatically doing stuff based on the user's actions (ie the user isn't really controlling it), but it might be nice to know anyway which user got things started. -David On Jul 14, 2009, at 8:48 AM, Bob Morley wrote: > > I think the problem stems from the fact that the "created_by_user" > on the > acctgTrans table is somewhat inconsistent. When a user records an > incoming > payment (for example) it will be set to that user's login id. When > the > payment gets applied to the invoice (through the quick ship > mechanism) the > creation of the invoice and application of payments is done through > an ECA > (createInvoicesFromShipment triggered from updateShipment) that is > set to > run-as system. This results in these transactions being created by > the > system user. > > Based on your comments, I think this makes sense. The user that > triggered > the quickship did not explicitly create the invoice / apply payments > (the > system did in fact do that). Where as, when they are recording a > payment > they are clearly the person performing that action. > > The trouble was that our report designer looked at this table and > deduced > that the user would always be the logged in user. We made an > assumption > that changes over the last few months have changed how that field is > being > populated; but I have not found any evidence of that. > > So, I think from our perspective the only time an incoming payment > is going > to hit this accounting table is when it is manually recorded in our > POS by > the logged in user (this may not be true for payment gateway which we > currently do not support). I am going to change our report to get the > unique account transaction entity for the payment in question of type > "INCOMING_PAYMENT" to determine the user that entered the payment. > (Unless > you would suggest otherwise -- I considered drilling back down to > the order > preference that started the whole process but decided against). > > However, I think we should consider an enhancement where we keep > track of > payment status changes much like we do for other entities in the > model. > That way we would have history of the payment workflow as well as > the user > that triggered those status changes. Unless I am missing something > in the > model (and I will grab my data modeling book shortly); and in > fairness I > have not focused on the payment mechanism in Ofbiz in tremendous > detail. > > Thoughts? > > > BJ Freeman wrote: >> >> taking this to the POS level, Normally any data like who ran the >> transaction at the POS is not carried into the normal accounting. >> This stays in the POS Journal. Reports for who did what on a >> particular >> POS is run on the POS Device (thinking in normal POS B&M) >> I have to go back and review how post journal works before I say to >> much. >> >> also it looks like Scott did some work on POS transactions so he >> may add >> something to this. >> >> BJ Freeman sent the following on 7/14/2009 2:29 AM: >>> the datamodel vol 1 page 266 (fig 8.2) show the Accounting >>> Transaction >>> model. >>> There are two transaction type, internal and external this show a >>> party >>> connected to the Originatedfrom for the external. >>> The external is used for Sales Acct Transactions. >>> >>> Bob Morley sent the following on 7/13/2009 10:29 AM: >>>> We are working on a report where we would show the identity of >>>> the user >>>> that >>>> actually received the payment (think brick and mortar POS). >>>> There is a >>>> user >>>> login tied to the OrderPreference record. Later when the payment >>>> is >>>> received and the payment entity is created, there is no longer a >>>> createdByUserLogin available. >>>> >>>> Ultimately an invoice is created and payments are applied to that >>>> invoice, >>>> an acctgTrans entity is created and there is a createdByUserLogin >>>> attribute. >>>> However, it appears that this value is "system" (at least with our >>>> processing). >>>> >>>> So -- if we were to try to figure out who received a payment in >>>> general >>>> where in the data model would you expect to get that >>>> information. Is it >>>> missing or am I missing it or .... should the AcctgTrans entity >>>> have the >>>> value of the user that was logged in. >>> >> >> -- >> BJ Freeman >> http://www.businessesnetwork.com/automation >> http://bjfreeman.elance.com >> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro >> Systems Integrator. >> >> >> > > -- > View this message in context: http://www.nabble.com/Determining-who-received-the-payment-tp24465961p24481109.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |