Forum Replies Created
-
Posts
-
This update is adding foreign key support so that the situation you have now won’t occur in the future. The si_invoice_item_tax table contains orphaned records. That is, they contain a value in the invoice_item_id field that references a record in the si_invoice_items table that no longer exists. You can verify this for yourself by verifying that a record with the value shown in the INVALID VALUE column does not exist in the id field of any record in the si_invoice_items table, but does exist in the invoice_item_id field of the si_invoice_item_tax table.
Once you are satisfied this is the case, you just need to delete those orphaned records from the si_invoice_item_tax table. After the orphaned records are deleted, you can run SI again and it will pick up at this point and move forward from there.
The payment_warehouse ia how excess payments are handled. Example: Invoice is for $35. Client sends in $40. You apply the $40 payment and see a warning that the payment exceeds the invoice amount. If you proceed to apply the $40 payment, $35 is applied to the invoice and $5 is warehoused. Same customer now has an invoice of $50. If you apply a payment, you are forced to apply the warehoused %5 before you can apply any other payment. After the warehoused payment has been applied, you can apply a new payment.
In the past, you could apply the $40 to the $35 balance and the $5 excess has no invoice item corresponding to it. You could adjust the $35 invoice to be $40 and apply the payment. But to my thinking, that invalidates the invoice that the client received and paid. If you want to do this without changing the invoice now, you apply the $40, let the excess be warehoused and then delete the warehoused record.
I have customer’s with recurring costs and they prepay several months in advance. I use the recurrence feather to generate their invoices. I don’t email the invoices when generated. First, I allow the warehoused payment to be applied. Then I regenerate the invoice and then send it to the client. This way, they see their excess has been applied with what the remaining balance of the invoice, if any, is left to be paid.
Hope this explanation helps.
In the error log you will find the following statement:
Unable to apply patch 318. Found foreign key table columns with values not in the reference table column. The following list shows what values in foreign key columns are missing from reference columns. There two ways to fix this situation. Either change the row columns to reference an existing record in the REFERENCE TABLE, or delete the rows that contain the invalid columns. To do this, the following example of the SQL statements to execute for the test case where the 'cron_log' table contains invalid values '2' and '3' in the 'cron_id' column. The SQL statements to consider using are: UPDATE si_cron_log SET cron_id = 6 WHERE cron_id IN (2,3); ---- or ---- DELETE FROM si_cron_log WHERE cron_id IN (2,3); FOREIGN KEY TABLE COLUMN REFERENCE TABLE COLUMN INVALID VALUE ------------------------ ------------------ ----------------------- --------- ------------- cron_log cron_id cron id 7 invoice_items invoice_id invoices id 0 invoice_items product_id products id 19 invoice_items product_id products id 20 invoice_items product_id products id 21This is telling you that there are orphaned records in your database. The table names are shown without the leading ‘si_” prefix.
The first error says there is a cron_log table record that has a cron_id field with a value of 7 that has no corresponding record in the cron table’s ID field.
The next says there is an invoice_items table record with an invoice_id field with a value of 0 that has no corresponding record in the invoices table’s ID field.
The final three errors say there are records in the invoice_items table with product_id fields containing values of 19, 20 and 21 with no corresponding records in the products table with those ID values.
You need to manually correct these issues. The first two are truly orphaned records and should just be deleted. The final three need to be reviewed. If these products should be valid, you need to add them to the products table if they don’t exist. And then you need to change the product_id of these orphaned records to have the correct value for the corresponding records with the ID’s in the products table.
The fact that these errors exist in the database, is why this foreign key support is being added at that time. Once you correct these issues, your conversion should process to completion.
There is no export.pdf.screensize parameter. And the export.pdf.papersize name should be changed to exportPdfPaperSize.
Here are the parameters I use for your reference:
exportSpreadsheet = xls exportWordProcessor = doc exportPdfDefaultFontSize = 10 exportPdfPaperSize = Letter exportPdfLeftMargin = 5 exportPdfRightMargin = 5 exportPdfTopMargin = 5 exportPdfBottomMargin = 5Hope this helps.
The currency sign is €. The currency code is EUR. You can get this info from the help info for each field in the Inv Prefs option of the Settings tab.
In the schema you attached, the following is the id settings in si_invoice_items:
CREATE TABLE si_invoice_items ( id int(10) NOT NULL AUTO_INCREMENT,
It should be:
CREATE TABLE si_invoice_items ( id int(11) UNSIGNED NOT NULL AUTO_INCREMENT,
If the table is set correctly, then the update process should complete as it did once I made the change. Note, you can change the field setting manually in phpMyAdmin by selecting the Change option on the id column under the Structure tab when si_invoice_items is selected.
Via phpMyAdmin, access the si_invoice_items table and execute the following SQL command:
ALTER TABLE si_invoice_items MODIFY id INT(11) UNSIGNED NOT NULL;
Had to dig, but issue is that the invoice_item_id field in the si_invoice_item_tax table is configured differently than the id field in the si_invoice_items table. This command corrects the issue.
FYI, your password recovery directions to another forum user, were excellent. I hadn’t thought of it before. I tested it and other than some template warnings related to not having a role name stored for the user’s session, it works. So I just delivered an update that fixes the warnings and formalized recovery procedures in the How To menu section.
You can change the min and max length fields in the template for the screen. Ex: templates/default/billers/edit.tpl or create.tpl. However, this should be done as an extension so that it isn’t lost when you update. Extension info can be found in the Extension section on the left.
However, the intent of this size if to support the ISO 3166-1 Alpha 3 code for countries. Which might be added as a validation in the future.
In the si_sql_patchmanager table, what is the greatest value of the sql_patch_ref field? It should be 335 and the sql_statement should contain,
INSERT INTO
si_system_defaults(name ,value ,domain_id ,extension_id ) VALUES ('invoice_display_days', 0, 1, 1);If so, then the invoice_display_days row should be the last item in the si_system_defaults table. Make sure you are looking at all the records in the file. Default is to display 25 record but this one is the 44th row. You can sort the table by the name field to make the entries in alpha order.
Also, did you download the most current si version? The version # should be 2020.4.5. Click on the About option in the top menu line to see the version or get it from the config/config.ini file.
Thanks for the appreciation. Please update to the latest version and see if the problem remains. If so, I can then work it.
Modified si_system_defaults access functions to force an integer value returned by functions that require int type return values. This is now available in v2020.4.5.
Verify that the invoice_display_days value is numeric in the si_system_defaults table. If it is and you continue to get this failure, download the new version and see if that helps.
Recent Comments