Search options (Page 1 of 2)

Thank you for the confirmation apmuthu, just as I hoped for. That leaves me happy with your modification that I've applied.

I'll stick around to see the answers to this question.

And with that, is it reversible once updated to v2.4.8 or are the relating fields in the existing DB trimmed to 50 characters?

For the record, to fix the headers I modify file "../reporting/includes/header2.inc"

Original (Lines 182-189)

        // Line headers
        $this->row = $iline5 - $this->lineHeight - 1;
        $this->Font('bold');
        $count = count($this->headers);
        $this->cols[$count] = $right - 3;
        for ($i = 0; $i < $count; $i++)
            $this->TextCol($i, $i + 1, $this->headers[$i], -2);
        $this->Font();

Modified - add line 185 (Lines 182-190)

        // Line headers
        $this->row = $iline5 - $this->lineHeight - 1;
        $this->Font('bold');
        $this->headers = array(_("Item Description"),'', _("Quantity"),_("Unit"), _("Price"), _("Discount %"), _("Total"));
        $count = count($this->headers);
        $this->cols[$count] = $right - 3;
        for ($i = 0; $i < $count; $i++)
            $this->TextCol($i, $i + 1, $this->headers[$i], -2);
        $this->Font();

I agree that modifying file "../reporting/includes/doctext.inc" would be preferable, but that has a lot of consequences for a many other reports.

TLDR; Time to pop the champagne!

What did I do?
===Trial 6===
6.1) Made a fresh DB dump from my v2.3.26 production
6.2) Did a clean install of v2.3.26
6.3) Created USA DEMO DB v2.3.26
6.4) Compared DBs and adjusted my version, even reorganised columns (probably not required). Had to adjust a handful (secondary) keys. Imported my adjusted DB and thoroughly confirmed working
6.5) Imported my adjusted DB into v.2.4.7 with applied Braath Wate changes and upgraded my DB
6.6) Compared USA DEMO DB v2.4.7 with my DB to make it 100% tickety-boo
6.7) Made a copy of my DB and went nuts on everything I could think of, comparing (with v2.3.26), adding entries and so on.
6.8) Finally Braath's last comment made sense (make sure that "Include in tax register" is checked)

Still journal entries on closed booking years will make discrepancies on tax reports of those relative timespans. A theoretically and minor issue, as it has zero operational impact. All other balances and reports have a 100% historical match with my v2.3.26. With that I now fully grasp Braath his last comment and have seen the outcome. This works during regular accounting and future journal entries.

6.9) I've backed up my v2.3.26 production environment, updated my php to v7.3 and am running v2.4.7-Braath now

I have a two minor things. One is regarding a invoice-report and I will probably open a new topic for that, if I can't figure it out. The other one might be answered here straight away. It seems like I have two obsolete tables in my DB, knowing;
    `0_company`
    `0_sys_types`
A quick search on the forum shows that `x_sys_types`indeed became obsolete. However, for `x_company` I can't seem to find any details at first sight (however, looking at the content of the table I'm happy to bin it).
Can someone confirm I can delete both tables?

Ps. As can been seen in this Trial 6, I've completely skipped the Dutch COA that was created by Apmuthu in this topic. It shows quite some discrepancies with the empty USA COA. Other than the differences between 'char' and 'varchar' (which will probably not cause any harm at all), it shows a couple 'KEY'-differences which might have severe impact (way out of my league). In example on tables;
    - `0_bom`
    - `0_crm_contacts`
    - `0_cust_allocations`
    - `0_debtor_trans_details`
    - `0_loc_stock`
    - `0_sales_orders`
    - `0_supp_allocations`
    - `0_tax_types`
Just to let you guys know, as you are the frontaccount guru's. I do appreciate all efforts made to help me, including the creation of the custom made Dutch COA. Thank you!

Finally, to all: Thank you so much for all effort in general and help to me especially. Awesome community!

Okay gents, I had some time to waste.

TLDR; I'm not out of the woods yet.

What did I do?
===Trial 5===
5.1) Started with a clean install of v2.4.7
5.2) Applied file changes from the @Braath Wate branch v2.4.6
5.3) Grabbed converted DB from Trial 1
5.4) Applies DB change from the @Braath Wate branch v2.4.6
5.5) Ticked the "Setup->Company Setup->Tax Bank Payments and Deposits" box
5.6) Compared several report (especially tax related) between this installation and my production v2.3.6

It looks very very promising. There is only one thing not taken into account, which IMHO needs to be. My accountant generally makes some journal entries at the end of the booking year to cross the t's and dot the i's (most entries concerns partly private use of company goods). Quite often this implies a small rectification of tax. In v2.3.26 this was correctly reflected in the Tax Inquiry. It is not reflected at all in v2.4.x and/or @Braath Wate branch.

Even though I can't figure out why v2.4 has changed big time on the tax part (other people have accountant and do journal entries, right?), I thought it would be a relative minor issue for now as I only have journal entries once a year. So I carried on to see how all was working.

I probably missed it before, but it turns out that the conversion of my DB from v2.3.6 to 2.4.x is not that good after all. I lost access to all my customers. After digging into the DB, and comparing it to my v2.3.6 DB, I noticed two or three major issues;

A - in table `0_cust_branch, column `br_address`is stripped to something like 60 characters or so, losing the majority of the second half of the adresses

B - Table `0_debtors_master` turned out to be completely empty, as in 'no data entries'

I've tried to restore/repair things manually, a bit tricky though as some columns were moved around and so. I gain various results, but I'm running out of time for today. I'm thinking of doing a new conversion of v2.3.6 to v2.4.x and meanwhile keep an close eye on this.

However, I stumbled on another significant difference between both DBs. Not sure if it is related. Not even sure if it will cause an issue, but I find it very odd.

C - The last two columns of table `0_gl_trans` (known as respectively `person_type_id` and `person_id') are transformed into NULL for the big majority (like 90 to 95%) of my entries.

As said, I plan on doing another DB upgrade from v2.3.6 to v2.4.x. However, any tips are more than welcome.

Awesome @itronics, much appreciated!

Great job Stefan, thank you.

Bit disappointing that it is (still) not (yet) included in the downloader *hint*hint*

Does this mean, I can do a new upgrade of the software and apply updated COA from the repository? That is awesome Apmuthu, thanks!
Now, in my understanding there is still something going on with rep709 which might or might not be part of my initially issue. I will keep a close eye on this topic.

Woow, lots of comments! Thank you for that and your encouraging words. I would love to stay, I prefer open source, I love FA. In generally I try to contribute to OS communities. I've spent quite some time with the FA DB when I started 8 years ago, mainly to try to import exports from my bank account. From that time I know the FA DB is complex for an 'outsider', because of the nature of proper accounting and accounting rules. Even more as I have to trust it for my company, it has to be correct, it is not a kindergarten.

I know you guys are willing to help me, but I don't have enough faith in myself, I can not oversee the implications of what I'm doing in the database. As the error is easily re-produced (take current FA, load the 'official' dutch COA from the repository, do some accounting and check if the tax report matches) I was hoping for some support (read: fix) from the core community who knows what they're talking about. I fully understand if this is too much from me to expect, there is no blaming in here. But I've tried and drowning (I hate to admit, but it's true).

As said in my previous post, I'm not gone yet, but I do realise I can't stick with old version forever (with risk of not being able to update at all in a couple major versions from now). In the upcoming days I will work my way trough recent comments.

Much appreciated guys, really!

(edited typo's)

Sorry for my late reply, work picked up.
I'll start digging in to it. I have to travel quite a lot in the upcoming weeks and will do some trial and error on a local LAMPP.

I'll get back to you, but it might take some time. But I do appreciate your help a lot!

Hi Poncho,

Just completed another test with a clean install of v2.4.6
Default company has an empty (no demo data) USA COA
Added a new company, assigning the Dutch COA

Exported the DB, but have no clue where to look. I was hoping for some community support on this, a FA DB guru who knows in which corner to start looking.

Hi Poncho1234,

Thank you for your reply. And that makes perfect sense. I had a quick look in the DB with phpMyAdmin, but seems far from easy to compare COA's. Is there an easier way to compare them?

The 'System and General GL Setup' seems alright compared with older versions and compared with USA demo data.