Layout problems with Reference fields on transaction forms

In version, the Reference field is overly wide. The Due date field is also misaligned. For example, on a sales invoice:

This problem also occurs on all other transaction types where a Reference field is used except:

  • Receipts
  • Purchase Invoices
  • Debit Notes
  • Goods Receipts
  • Inventory Transfers
  • Inventory Write-Offs
  • Production Orders
  • Payslips
  • Depreciation Entries
  • Amortization Entries
  • Journal Entries

I am not saying that this is not an issue or bug that you experience because you show evidence. However, I can not replicate this on Ubuntu 20.04 Server Edition and on MacOS. Maybe it has to do with your browser?

No, this was on the desktop edition under macOS. There have been other layout issues recently that were hard to replicate and seemed to be operating system specific. (These were not discussed on the public forum, but in moderator-to-system-administrator communications.)

Are you saying this issue is visible on Sales Invoice form but on Purchase Invoice form it’s good? Or that the issue is on Payments form but not on Receipts form? Are you sure the exclusion list if complete? Which forms are actually affected?

I’ll try to figure it out what’s different even though can’t reproduce the issue.

My original bug description misled you because form defaults in the test business used varied from tab to tab. As I was verifying the results of my earlier tests, I discovered the real trigger.

The problem occurs whenever the checkbox for Automatic is checked in the Reference field. If the box is unchecked, the field reverts to normal size. And if a reference number has been entered, it displays at normal size, regardless of how the reference was set. In other words, it is the presence of the checked box that causes the behavior. For example, a receipt without the check:

Screen Shot 2022-06-12 at 4.27.26 PM

and with the check:

As far as I can tell, the behavior is consistent across all tabs with the Reference field.

OK that makes more sense.

Should be fixed in the latest version (22.6.20)