ppmt

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 56 total)
  • Author
    Posts
  • in reply to: Best way to modify the layout of SI #1481
    ppmt
    Participant

    This would be a start definitely but I understand if that is not a priority.

    I have no idea what kind of massive effort it would require but may be have a configuration where you could select what and in which order to display various filed would be a good idea?

    Again I can see that it it is not a priority

    in reply to: Best way to modify the layout of SI #1478
    ppmt
    Participant

    I have thought about it after each upgrade but I hitting a wall with my other user (wife) who got used to the way I “designed” it.

    Is there a way to make it so that the description field is always displayed rather than hidden by default?

    If I can convince her it for sure would make my life easier.

    My next tasks will be to redo the template as it doesn’t seem to be compatible with the new version anymore.

    Thanks for your time

    in reply to: Best way to modify the layout of SI #1473
    ppmt
    Participant

    I attached a zip file instead

    Attachments:
    in reply to: Best way to modify the layout of SI #1472
    ppmt
    Participant

    Hello,
    I have attached a tar.gz from the custom/default_templates/invoices

    There are from the version I am still using until I adapt to master-2020

    Version is:

    version.update_date = 20181012
    version.name				    	= 2018.1.3

    Yes very old….

    in reply to: new line in invoices not fully populated #709
    ppmt
    Participant

    Hi Richard,

    In case you missed it 🙂

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #701
    ppmt
    Participant

    The “old” method makes more sense. It is not often that you need to go back through your old invoices.

    I am sure Richard had his reason to change it

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #699
    ppmt
    Participant

    yes that is indeed a lot but I am not sure that anything can be done on the database side. I mean Mysql/Mariadb are very efficient database that can handle much more request that 4440 query.

    I would think it is the processing of these queries that takes a lot of time

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #697
    ppmt
    Participant

    I have about 200 invoices I think. It can be a bit slow as well but since I am only testing it at the moment it is not on the fastest machine. It takes about 10 seconds for me to load the invoices pages

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #694
    ppmt
    Participant

    Richard seems to be away at the moment. He is really the one that would be able to help you.

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #692
    ppmt
    Participant

    No PDF export does work for me. The issue I had was my templates would not display properly with things all over the place.
    I found that mpdf which Richard is using has some limitation with some CSS attributes.

    Once knows the templates can be adapted

    On my side I am using a bit of strange config.

    I have a docker container running:

    – linux Alpine rev 3.10.2
    – PHP 7.3.9 with PHP-FPM
    – Nginx 1.16.1

    in another container I have Mariadb (rev 10 I think)

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #690
    ppmt
    Participant

    Glad you got it sorted.

    For the PDF I feel for you. It is not as easy as one would think to export to PDF. I have been struggling myself with its limitations.

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #681
    ppmt
    Participant

    for the php.log file what does the custom.config.php contains? Here is mine

    debug.level                                     = All
    debug.error_reporting                           = E_ERROR
    
    phpSettings.date.timezone                       = Europe/London
    phpSettings.display_startup_errors  = 1
    phpSettings.display_errors                      = 1
    phpSettings.log_errors                          = 1
    phpSettings.error_log                           = tmp/log/php.log
    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #674
    ppmt
    Participant

    well if all of them are really set to 0 then you have a different issue than I did. I would still check the sqlbackup file to be sure.

    And are you sure you don’t have a php.log file in your tmp/log directory?

    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #670
    ppmt
    Participant

    Is that all your product listed there? If you are like me then only a few were loaded..

    I would suggest to check the sqlbackup file (it should be a text file) to make sure that the field default_tax_id_2 is really set to either null or 0 for all product.

    • This reply was modified 5 years, 1 month ago by ppmt.
    in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #667
    ppmt
    Participant

    can you check the database dump file you have (the one you imported) and check that the table si_products.

    If the field default_tax_id_2 is set to “” (empty) then it is the reason it was failing for me. The solution is to update the file to set the empty field to null and the reimport the database and restart the upgrade.

Viewing 15 posts - 16 through 30 (of 56 total)