[fearless359]

I see there is a problem. I will work on fixing it. In the meantime, I need to know if there are only the two invoices in the database? If yes, can you start with a new installation? To do this, simply empty all tables in the database. An admin tool such as phpMyAdmin simplifies this. You will need to disable the Check Foreign Keys option when you do this. This is a setting on the Yes/No empty table confirmation line when using the phpMyAdmin tool. Hopefully something similar if you are using another maintenance tool.

With the database empty, access SI. Do the initial installation and then start using SI. Add your biller, customer and product records. Now go to the Inv Prefs option in the Settings tab. Edit the Invoice record and set the Starting Number to the value you want assigned to your first invoice. I assume this is 106. Save this change and then you should be able to add your invoices with the correct invoice numbers being set as new ones are added.

Let me know if it isn’t an install with two invoices in it, such that you can’t really start over. Also, what is the next invoice number you want to be assigned? I’ll let you know what you can do in this case.

• This reply was modified 2 days, 18 hours ago by fearless359.

[fearless359]

First, have you read the How To topic on Change The Invoice Number Starting Point? It’s a bit complicated but then again so is the logic SI uses to determine the value. In the simplest case, there is only one index record and all preferences get their numbers from that record.

For me to try and determine what is happening on your system, I would need you to export the si_index, si_invoices and si_preferences tables. Zip them and attach the zip file to a response to this message. There is no revealing data in these tables as identities exist as numbers to the ids of records in other tables. You can review this to verify it to your satisfaction before giving me the data.

[fearless359]

The issue is that the patch process couldn’t handle the case where not all applied patch history records are present in the si_sql_patchmanager table. Yours starts at patch 319 and ends at patch 335. I have corrected this error so your situation is not an issue. Download the latest SI version and run it. This should fix your issue.

[fearless359]

I think the issue is with the content of your si_sql_patchmanager table. Please export it, zip it and attach it here?

[fearless359]

The section you are looking at is a default login, typically when a new installation is being implemented. This is not an issue. What is an issue is that the program is acting as though you have an empty database, or at least an empty si_sql_patchmanager table. You say you are doing an upgrade. Is your custom.config.ini pointing to the correct database?

[fearless359]

I’ve implemented a fix to round the calculated tax amounts to two decimal places. Editing and saving the invoice with this change in place should recalculate the amount owing to show what is left. Upgrade to the most current version of SI to get this fix.

[fearless359]

That’s not giving me enough information to determine the issue. Please enable logging to output debug info. Do this by changing the loggerLevel setting in the custom.config.ini to the DEBUG setting. Then delete the si.log file in the tmp/log directory. Then run SI. This should create a new si.log file. Please zip this and attach the zip file to a response to this topic. Hopefully that will help guide me to where the error is.

Oh, before uploading the log file, you should read through it a blank out personal info such as the SI login password as once uploaded, anyone can view the file.

• This reply was modified 1 week, 6 days ago by fearless359.

[fearless359]

I’ve replicated the problem and will work on a solution.

[fearless359]

Is there more information in the tmp/log/php.log file? In particular the actual command that is trying to be executed?

[fearless359]

The json is stored in the public directory. If this directory doesn’t exist, it is made by SI. Check the directory’s existence and the access permissions. From shell command line the command is ls -l public assuming you are in the root directory. On my system (windows running xampp), SI builds the directory with -rw-r–r– or 644 access. If I delete the directory and build it from the shell, I get drwxr-xr-x or directory with 755 access. Which both work on my system.

Bottom line, it should come down to directory access permissions. If you want to go whole hog to avoid any possible restrictions you can chmod 777 public and give universal access to anyone. This is overkill and should be used just for testing.

Hope this helps.

[fearless359]

Check the Version Update Process menu topic and the Unable to set Foreign Keys Error Handling tab. What you don’t show in your error log message is the list of foreign key values that prevent the foreign key constraints from being implemented. This issues need to be manually resolved before the update and proceed.

• This reply was modified 2 months, 3 weeks ago by fearless359.
• This reply was modified 2 months, 3 weeks ago by fearless359.

[fearless359]

I’ve developed a solution for this that allows you to use custom field 1 (or could be 2,3 or 4) on the invoice management table screen in place of the preference field. The extension I developed is contained in the attached zip file. I will be supplementing the help information on extension development with this example to assist future users. Note that you need to download the current version of SI (version 2026.00.04) to load a change I made to the change of Invoice class private methods to be protected so the attached solution can simply replace the methods that need to be changed thus minimizing what you have to possibly change when loading future updates. Hope this helps.

Attachments:

1. InvCustomeFld.zip

[fearless359]

I haven’t begun working on the issue of namespaces for extensions (which is what the Inc\Claz path effectively is). I’m currently addressing screen formatting for mobile device presentation which I introduced in the last update with mobile device menu support. I need to complete my work on this before working on extension development issues.

[fearless359]

I’m a bit flummoxed with the complication that using namespaces appears to have introduced.

Given this, the simplest approach might be to add logic in the extension modules\invoices\manage.php file to take the $invoices array and add a loop to run through it, taking the index_id, accessing the Invoice::getOne() method to read the invoice record, pull the custom fields and add them to the row being processed. Effectively updating what Invoice::manageTable() returns with the additional fields. This is kind of ugly, in that it means reading the invoice records twice to display once. But given how namespaces work with autoloading, I can’t think of a more elegant resolution off hand.

Note that if you to this, you are working with the index_id field to get the invoice. So you need to set the $useIndexId parameter to true.

• This reply was modified 4 months, 1 week ago by fearless359.
• This reply was modified 4 months, 1 week ago by fearless359.

[fearless359]

The issue is that the Invoice::manageTableInfo method does not preserve the custom fields for the invoice. Hence, they are undefined by the time it gets to the screen. The easiest way to resolve this is to modify said method to include these fields which would be referenced as $row['custom_field1'], etc. Copy the Inc/Claz/Invoice.php file into the extension directory preserving the “Inc/Claz/” path the same as you did for the template and module files. Then modify the method to add the custom field assignments to the table.

[Author]

Posts