That is odd because there is a tjeph01. You would think they would be able to easily link the table to the report through an inner join

GwG said:

You would think they would be able to easily link the table to the report through an inner join

Yes, should be easy enough to add another case to the code that checks whether it's in the current, prior, or next year - if the date is before the first fiscal period in tCompany, they've only to look up the prior fiscal years' records in tacthdat to see all the fiscal year JE table suffix as nHistSet, and check compatibility by reading the software versions as nVersion before building the query string that fetches the invoice data.

On the invoice data entry screen, the program used to look up all year's journal entries from the ITRec lookup tables but eventually they figured out that they did not always match the real journal entries, so they stopped it. I agree, a bit of extra linking and they can still do it but that would have taken extra work at a time when they were probably trying to get it fixed quickly.

I can't help wondering if would have been less work, overall, to have re-designed the new-journal-table-every-year into a having a fiscal year field in a single Journal entry table.  It would certainly make year-end spanning financial reports, or perhaps changing a year end, soooo much easier.

Richard S. Ridings said:

that would have taken extra work at a time when they were probably trying to get it fixed quickly.

That's understandable, however there should be a long-term plan.  A Shop-Vac is OK as an emergency response for a flooded basement. The long term plan should be more robust.

Randy,

Right now to go back and change many things at that low a level may be a lot of work as those tables are integrated into all or almost all SQL statements that involve the journal entries and all other accessory tables that hold things related to those journal entries, just to put in the new field. That would be a massive rewrite and massive QA testing and we know there is no beta program anymore...

While we (you and I and the others that do custom work) may see these things based on the inside workings of the database, the vast majority of users do not see it and don't really care. I find even my software can do with some improvements in the SQL after I go back and look at it at a later time. Users just want it to work. So I believe Sage changed the programming to reflect the correct journal entries for the last two years and force users to go direct to the journal entry reports for older stuff.

I can't speak for the designers, programmers or especially the people pulling the strings and making the decisions in Atlanta and the UK but from what I have seen over the years, the "long-term plan" keeps changing. I think that is why we keep seeing so many partially implemented features that never seem finished (eg. posting 12 months of future rent cheques in the Payables module - you can do it for payroll cheques because, you know, even without proper payroll tables that haven't been thought of yet, my employees need their Jan/18 payroll today, so I can post that cheque now without affecting my 2017 payroll calculations, but luckily my landlord will still rent to me even if I don't send him the money dated in advance unless I hand-write the cheques, etc.).

Spanning fiscal year reports is something I am doing again today but depending on the language, is easier when writing for a specific database because there are a known number of fiscal years that are to be reported. When writing for unknown databases, that's the fun.

Richard S. Ridings said:

I think that is why we keep seeing so many partially implemented features that never seem finished

As another example, the 'Invoice No', 'Project' and 'Items Stored at' fields are stuck at their 15-charactor 1983 DOS work-through-the-keyhole size on the invoice screens.  

Why?  

Is it because that's wide enough for the date field??  (and couldn't someone have the imagination to make that a little wider, maybe displaying 'Thursday, Feb 16, 2017' as an additional aid to correct data entry?

Look at the Statistics tab in a customer record, why include Sales Tax in 'Year-t0-Date Sales?  Why not show both tax included and not?   "we don't have the historical information to display" was a legitimate excuse for 1991 and 1992, but that was a quarter of a century ago.

 - On a (Quantum) Purchase Invoice screen, if I insert a row from Edit | Insert:

From any column on the first row, the cursor goes to the Item Number (first) column on the second line.

From any column on other rows, the cursor goes up to the Sales Tax (last) column on the row above, and my keystrokes go to //sage50/dev/null.

Except, sometimes the cursor ends up in the 'supplier item indicator icon' field. (one column to the left from the Item Number).  Same destination for the keystrokes though.

 - On the Inventory Adjustment screen:

I can enter an item number, tab over to the quantity field, then:

Shift-tab will go back to the item number. (good)

Down-arrow will move to the next (blank) row, EXCEPT:

When the screen is more-or-less full, it will just stay on the same row and scroll the list so I type over the last entry.  More wasted time and keystrokes.

For anyone trying heads-down data entry, the 2008-on interface is like an irritating gauntlet of practical jokes.  The interface looks pretty from a distance, but every day of data entry is a close-up view of another 40 miles of bad road.  And don't get me started on the sadistic choice of an 8 point narrow proportional data entry font.

All that said, free SDK so I guess it's time for me to nut up or shut up.

Richard S. Ridings said:

Spanning fiscal year reports is something I am doing again today but depending on the language, is easier when writing for a specific database

Even with a specific company file / situation, I couldn't get a Union query to work with more than 2 tables.   (and joining two union queries also didn't work, nice try Randy!). 

While duct-taping a temporary table together, I just couldn't understand why... more than one table?  Especially since it's been at least 10 years since they went 99 years of history?   Several years after they sort-of, almost went to 3 years of data entry availability by allowing G/L entries and paycheques? 

I agree that it would be a semi-gargantuan task and a massive rewrite.  But technical debt can't be ignored forever either. 

Randy,

If I recall correctly, during beta the year the Vendor-specific inventory was released, whenever you maximised the Purchase Invoice screen, the left Vendor Item association field would proportionally widen out as well without the ability to change the width. We had the programmers fix that before release. I don't add rows much so I don't see the other issues you are referring to.

I wasn't trying to get you started on anything because I know what it's like when I get going on this stuff. I was trying to address why it appears the program is still under construction in various parts. I can understand to some degree based on the control head office in Atlanta has taken on but it leaves the programmers here with little time to fix things. I am starting to believe that head office thinks "New Features" = "New Sales and keep old sales coming" without any regard to the fact that fully implementing a feature so we talk about it, not complain about it, will help drive word of mouth and people will start using it again instead of getting frustrated and churn somewhere else.

I sent you an email off forum.