Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Payment Entry - Several Issues
03-14-2018, 05:28 AM, (This post was last modified: 03-15-2018, 12:48 AM by VortecCPI.)
#1
Payment Entry - Several Issues
Payments.php

In my test instance the "Update" button does nothing and readonly field "ttl" does not update.

What is the expected functionality of this field and button?

   
https://www.linkedin.com/in/eclipsepaulbecker
Reply
03-14-2018, 06:19 AM, (This post was last modified: 03-14-2018, 06:19 AM by TurboPT.)
#2
RE: Payment Entry - No Update?
Paul, do you show any javascript errors at that screen, after clicking Update?

The handling for the Update goes through 'update1', which is in MiscFunctions.js.
Reply
03-14-2018, 06:44 AM,
#3
RE: Payment Entry - No Update?
No errors but as I look at MiscFunctions.js i do not see that function, which is odd because I thought I had the latest version.

I will grab the latest version and try again...

Thank you!
https://www.linkedin.com/in/eclipsepaulbecker
Reply
03-14-2018, 07:05 AM, (This post was last modified: 03-14-2018, 07:29 AM by TurboPT.)
#4
RE: Payment Entry - No Update?
Hmmm, that could be a post 4.14.1 change? ... so you might not want the latest file, as there is other new handling that might break other things, such as the calendar picker and column sorting, mainly.

I'll have to check the history on this matter.
Reply
03-14-2018, 07:12 AM, (This post was last modified: 03-14-2018, 07:45 AM by VortecCPI.)
#5
RE: Payment Entry - No Update?
Okay... I grabbed the latest MiscFunctions.js and still no joy for me...

But... After CTL + F5 it is now working...

Thank you!
So now another issue...

In my case supptrans table is no longer updating settled field:

   

Also causing AUTO_INCREMENT to add 1 in suppallocs table:

   
https://www.linkedin.com/in/eclipsepaulbecker
Reply
03-14-2018, 07:43 AM, (This post was last modified: 03-14-2018, 07:44 AM by TurboPT.)
#6
RE: Payment Entry - No Update?
I'm not sure about those last two items, but please double check my post #4 info, I did add some additional info since we posted around the same time.
Reply
03-14-2018, 07:48 AM, (This post was last modified: 03-14-2018, 11:15 PM by VortecCPI.)
#7
RE: Payment Entry - No Update?
I believe we are missing one UPDATE query as allocations are still available AFTER committing the payment.
The SQL UPDATEs for supptrans do not seem to be correct. Trying to unravel it now...
I had to add "settled=1, " to the SQL statements:


PHP Code:
/* Firstly subtract from the payment the amount of the invoice  */
                    
$SQL "UPDATE supptrans SET settled=1, alloc=alloc-" $PaidAmount " WHERE id='" $PaymentID "'";
                    
$ErrMsg _('Cannot update an allocation against the supplier because');
                    
$DbgMsg _('Cannot update an allocation against the supplier using the SQL');
                    
$Result DB_query($SQL$ErrMsg$DbgMsgtrue);
                    
/* Then add the amount of the invoice to the invoice allocation */
                    
$SQL "UPDATE supptrans SET settled=1, alloc=alloc+" $PaidAmount " WHERE id='" $PaidID "'";
                    
$ErrMsg _('Cannot update an allocation against the supplier because');
                    
$DbgMsg _('Cannot update an allocation against the supplier using the SQL');
                    
$Result DB_query($SQL$ErrMsg$DbgMsgtrue); 

But then if you click on "Allocate this payment" on the following page it takes you to an allocation page with invalid data because it is passing "?AllocTrans=25" even though the payments are already allocated. I believe this is what caused the AUTO_INCREMENT value to increase by 1 though there are no new records created (i.e., due to failed INSERT)...
While I think the IDEA of integrated allocation is nice I think we need a lot more testing before we release it...
And I say that with the greatest of respect for all work done here...
I think if logic is added around line 693 to remove "?AllocTrans=NNN" when already allocated this can be made to work properly...

For now I have stripped out all the new code on lines 375-387, 549-559, 591-622, and 1329-1369.
https://www.linkedin.com/in/eclipsepaulbecker
Reply
03-14-2018, 11:09 PM, (This post was last modified: 03-14-2018, 11:10 PM by VortecCPI.)
#8
RE: Payment Entry - No Update?
Attached is the script I am using with 4.14.1.

PLEASE NOTE I made changes to SQL commands to use ChequeNO in the GLTrans table so I can track check numbers in 4.14.1.

Since we are in full production there is no way for me to move to latest GIT version at this time so I have to make due with what I have.

Besides changing where ChequNo lives I removed all the new-feature-related code and it works fine.

I sure wish we could segregate Bug Fixes from Feature Additions...


Attached Files
.php   PaymentsNEWb.php (Size: 57.05 KB / Downloads: 0)
https://www.linkedin.com/in/eclipsepaulbecker
Reply
03-15-2018, 12:13 AM, (This post was last modified: 03-15-2018, 12:22 AM by VortecCPI.)
#9
RE: Payment Entry - No Update?
Okay... This script seems to work for me but I am still not too sure if I like the auto-allocate feature...

AGAIN PLEASE NOTE I made changes to SQL commands to use ChequeNO in the GLTrans table so I can track check numbers in 4.14.1.


Attached Files
.php   PaymentsNEWc.php (Size: 60.5 KB / Downloads: 0)
https://www.linkedin.com/in/eclipsepaulbecker
Reply
03-15-2018, 02:52 AM,
#10
RE: Payment Entry - Several Issues
If the user selects to pay certain invoices then it is correct to automatically allocate the payment against those invoices. When the user selects an invoice to pay against then the amount to be paid should be increased, and when the invoice is deselected it should be decreased from the total. I wrote a nice clean implementation of this that has worked for years, but instead of using it somebody chose to try and re-implement it, and in an attempt to make it different dropped the most important features. Would have been better to use my implementation.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)