Preliminary 2018 payroll tax changes and 2017 year end

As another calendar year end approaches, some preliminary payroll related information is outlined below:

2017

There are no W-2 nor 1099-MISC changes for 2017. It is not too late to order W-2/W-3 and other tax forms from Dynamic Systems.

We plan to have W-2/W-3 federal and state e-filing testing phases completed within the next few days, and that option will again be available for Advanced Accounting 7i users.

(Postscript:  our annual W-2/W-3 federal/state e-filing interface testing was completed successfully on Dec. 27, 2017.)

2018

Social security including OASDI rates and limits:

The new social security wage maximum for 2018 is $128,400 (not $128,700 per some initial reports). The 6.2% and 1.45% rates remain unchanged.

See:

https://www.ssa.gov/policy/docs/quickfacts/prog_highlights/index.html

FUTA:

There are no FUTA changes:  the wage limit remains at $7,000 with a net rate for most employers of 0.6%.  The quarterly deposit threshold of $500 also remains the same.

California and Virgin Islands were both expected to have increased FUTA taxes for 2017, resulting in an additional 2.1% tax increase over the normal 0.6% net rate.

SUTA:

Many states will have SUTA wage base increases.  SUTA rates typically vary based on experience.  You should have hopefully received notification of your state's new wage base and your new rate if it applies.  Those changes need to be implemented in the Advanced Accounting software after your final 2017 payrolls are processed and before your first 2018 payroll (see recommendations).

Federal income tax withholding:

The IRS initially indicated on Dec. 13, 2017 that payroll withholding guidance for the coming year would necessarily be delayed and that taxpayers would not begin to start seeing any changes until early February. In short, Congress waited far too late in the year for anyone to expect a smooth transition into the beginning of a new year. On Dec. 26 the IRS updated their prior statement to indicate basically the same thing, that guidance was forthcoming in January and that they were "encouraging" employers and payroll service providers to implement those changes in February. While there were some other reports indicating that form W-4 might change, the IRS is now clarifying that no W-4 changes are expected.

See:

https://www.irs.gov/newsroom/irs-statement-withholding-for-2018

Accordingly, end users should not yet fret about making federal tax withholding changes:  use the same tables that are already in place for your upcoming January 2018 payrolls.

State income tax withholding:

Because many state income tax withholding formulas are in part based on federal amounts withheld, we expect to see more states than usual making state withholding tax changes in 2018.  In fact, we are already aware of ten (10) states that have published withholding tax tables effective January 1, 2018, plus Washington, D.C.   Since we expect even more to follow, it is premature to put out any updated tax tables just yet so we plan to wait to update those tables and also provide any required program updates once the federal changes become fully implemented and related "guidance" is provided. Most jurisdictions have implementing language that indicate end users are to implement tax table changes "as soon as practical."   We believe the unusual current circumstances justify delaying implementing changes until all of the new rules are fully known and at a time when changes can be smoothly implemented on both a state and federal basis.  Income tax withholding is after all a game of rough estimation.  If you have, however, received a formal notification of a state income tax withholding change, see our recommendations below.

Recommendations

Remember that year end routines and payroll year end processing are different and mostly not connected: they are only connected in that your year end routine needs to be run before you will be able to process payroll checks into the new year but ONLY if your fiscal year is based on the calendar year.

Use the PR option G "Clear employees/process W-2s later option.  This MUST be done before you start processing 2018 payroll checks.  Order forms that you expect to need now.  You do not, however, need to rush and print your W-2's before your first 2018 payroll as long as you use this option.

Enter the new social security tax wage limit in SY option D either before your first 2018 payroll or by sometime in January.

Make any required SUTA changes that go into effect on January 1 based on notices you may have received from your state in SY option D before your first 2018 payroll.

Withhold federal income taxes in January 2018 based on the same tables you are currently using.

Implement state withholding income tax changes in PR option K if you have received a specific notification from your state that clearly indicate the changes are effective January 1, 2018.

Watch our year end payroll update link for more information and which will be updated for new developments:

http://www.addsuminc.com/advyearend.html

New credit card interface now available for Advanced Accounting

A new fully integrated credit card option is now available for Advanced Accounting.  This new update replaces the previous interface that has long existed in the software and involves a new company that we have partnered with that we believe will, in addition to providing more competitive discounts rate and fees, also provide better sales and end user support.

Background:

We first added a credit card interface to Advanced Accounting 5.1 in the year 2000. That interface worked with an off the shelf credit card processing package called PCAuthorize, and for its era, worked well.   As additional regulations and changes in technology evolved, however, the generic card authorizing packages such as PCAuthorize, ICVerify, PC Charge and others began to vanish.  These products were either acquired (PCAuthorize was purchased by the maker of ICVerify) and/or have since had end of life cycle announcements and have been discontinued.

By mid-2006, we had developed a replacement for our PCAuthorize interface, integrating with X-Charge.  That interface was initially available for Advanced Accounting 6.1, but there was also a version for Advanced Accounting 5.1 and another legacy program. Since 2006, the X-Charge interface has remained actively in use. An equivalent interface was also made available for Advanced Accounting 7i.   

Because of a continuous change in corporate ownership of the X-Charge product and other changes including the fact that the X-Charge product is nearing obsolescence, we have over the past several years been analyzing various alternatives.  X-Charge will still be supported for Advanced Accounting 7i users who are currently using it, but new users of Advanced Accounting 7i (and for future releases and updates in the Advanced Accounting series) will instead want to use the new interface that we have now developed working with ChargeItPro and which is now available.

Unlike the early 5.1 interface that relied on an external call to an executable (one that we developed in another language), neither the X-Charge interface nor now the ChargeItPro interfaces rely on having to call any executable files which tend to be blocked and in general can create processing delays. The ChargeItPro interface, largely developed last month, makes completely internally native calls written in the same underlying language upon which the accounting software runs, and using newer techniques that we have developed over the past year.

Advantages of the new interface:

In addition to providing more responsive sales and support and better rates and fees, the new interface supports a wealth of external devices for those users who are swiping cards including support for EMV, and for processing debit cards (without having to process them as credit cards; debit cards in that respect were not supported in the prior interface).  And, as a result of making a tighter integration, we are also now providing a new integrated card/non-check return option which previously did not exist (and which can even be used by users in future releases who aren't necessarily using the integrated interface).    The new interface also records every transaction in a new transaction database in part so that the same card can be used again (in a completely PCI compliant way; the new interface is fully PCI DSS compliant).   Every transaction is also saved in the ChargeItPro web portal.

But I'm already processing credit cards on a standalone basis through another provider.  Why use an integrated approach?

The benefits of an integrated approach are huge and involve savings of time and expense that can be overlooked in making a full analysis.  An integrated approach leads to fewer errors, faster processing and overall better workflow.  It eliminates the double entries that have to be made when cards are processed "outside" of the accounting system.  And processing cards outside of the accounting system leads to not only extra work but also security concerns.   In short, to best meet PCI compliance responsibilities as well as to implement "best practices" in terms of financial and internal accounting controls, integrated credit card processing represents the optimal solution.
 
More information is available (with more to be added soon) at:

http://www.addsuminc.com/advcreditcard.html 

Feel free to contact us at any time for more information by calling us at 800-648-6258, by sending us an e-mail, or by chatting with us on our web site.

Minimize to taskbar and WinForm changes with TAS Premier r12

Background detail leading to today's TAS Premier 7i release 12

Since the first release of the graphical versions of the TAS language going back to at least 2001, minimized forms loaded by the runtime engine including the main form of the initial main menu program would appear in the lower left hand corner of the Windows desktop with just a portion of the form caption and the restore, maximize and close buttons.  The application itself remained in the taskbar, but clicking that button on/off it would reveal the minimize form in the lower left hand corner, but nothing more. Further, if additional forms were loaded from the main menu program or via a program that the main menu called (in the TAS environment typically via a "CHAIN" command), each minimized form would "stack" themselves horizontally from left to right. The main menu form or these other "child-like" forms could be restored by clicking on the desired form in the lower left hand corner of the screen.  This location remained constant regardless of where the user might have positioned their Windows taskbar.

Example of main window form's minimize button

The behavior described above is obviously not typical Windows behavior; but, it is also not an idiosyncracy or intentional implementation of form minimization within the TAS programming environment.  Rather, it relates to the underlying development language where this is a potential default behavior.  This is then complicated by the modular nature of the TAS language, where forms that are loaded are not necessarily child forms tied to a single application.  In the Delphi language which TAS was ported to from its assembly language beginnings by Business Tools, Inc., the taskbar button belongs to a special application window and not the main form of the application, and only it by default has a special Windows extended style that is applied to it.  Subsequently created forms do not have this style (nor is there a form property on the designed form to give it that style).   Absent applying this style and hiding the main application window and more, subsequently loaded forms do not minimize to the task bar (and are also not detectable by cycling through running programs, e.g. ALT-TAB).   Nothing in the modern TAS runtime engines is trying to minimize forms to the lower left hand portion of the screen.

With TAS Premier 7i rel. 8 that we released in April of 2013, in attempting to resolve some issues involving RUN programs (one of two different types of programs that the runtime engine can process), we were able to successfully make mounted screens (which actually are Windows forms) minimize to the task bar using extended Windows style API calls.   However in trying to do that with the GUI-type RWN programs which load graphical screens (DFM's), we ran into some issues and decided to leave the handling for those alone.

The problem:  Win 10 font display customization

In the past several months, however, a new issue has surfaced (and initially reported by two of our accounting software users) relating to customizing Windows 10 font display size whereby if the main menu form of the main menu program is minimized, the resized lower left hand corner form simply vanishes; and worse, it cannot be retrieved by clicking on the taskbar icon or in any other fashion.

Windows 10 at the standard non-customized 96 DPI (100%) setting: note that when minimized, the small resized form appearing at lower left

Changing the font size in Windows 10:

Windows 10: changing the font size to 125% (120 dpi)

Now running the main menu of Advanced Accounting in its tool bar mode: 

Windows 10 Adv tool bar mode after font change

Now minimize the menu above:

Windows 10 at 125% (i.e. 120 dpi) of standard font size:  minimize the initial program form and it disappears (lower left hand corner of screen is blank); and it can't be brought back by clicking on the taskbar icon, nor via ALT-TAB or the equivalent

Curiously, users have been able to change their font DPI settings in Windows for some time and when increasing them in those prior Windows versions, this minimization issue did not present itself:  the forms were still resized to the same expected, albeit unusual, location.

Windows 7 Pro custom DPI settings:  increasing font sizes did not create minimization issues. Nor did similar setting changes impact XP Pro.

The solution

Because this new problem meant that the application would become stuck in memory without the end user being able to regain access if they minimized a main menu form, we concluded that we had to come up with a workaround.  Revisiting changes that we made in 2013 for RUN style forms, and after experimenting with numerous other options and making some other beneficial changes to the runtime, the answer was to apply extended Windows styles which not only solved the custom DPI settings issue in Windows 10, but also caused forms to minimize to the task bar. In doing this, however, the expected form order (i.e. the Z-order) was changed.  In short, forms were often appearing behind other forms and these could include lookups, modal forms, print dialog boxes, many types of system messages, and more.  The only solution to that was to ensure that new forms that are dynamically created in the runtime environment were "top most" in order to maintain Z-order.  

Forms appearing behind forms is a problem that users can experience with many different types of Windows applications.  We've even seen it happen with Javascript "alert" message boxes appearing behind a browser window.  When this happens, a program may appear to be "stuck" or "frozen" when in fact cascading or tiling one's windows (right click on the blank portion of the taskbar) will reveal the hidden window and enable end user control of the application.

And while this solution worked, it meant we had to track down every different type of message (over six different types with different internal calls) to try to ensure that they came up over any given form that they might be called from.  And this was one of the reasons why we had not made this change in 2013.   But after a significant effort, that has been accomplished.

With release 12 installed into an Advanced Accounting installation:

Windows 10 with TAS Premier 7i rel. runtime with Advanced Accounting 8 main menu minimized

Windows 10 with TAS Premier 7i rel. 12 runtime with the main menu and three other programs/form minimized called from the main menu via a standard chain command

Windows 10 with TAS Premier 7i rel. 12 runtime with the main menu minimized plus a second runtime minimized called from the first via chain command with a "newruntime" option

It is interesting how different Window operating systems will minimize forms differently belonging to the same application.  As indicated with the Win 10 examples above they remain in the same "group" (the same thing will happen if you run say five instances of NOTEPAD and they will all be grouped together via single taskbar button).    

Windows 7 is somewhat similar, but different:

Windows 7 Pro with TAS Premier 7i rel 12 with the main form and three programs called by a standard chain and a fourth via a newruntime from Advanced Accounting

And in XP Pro, form minimization occurs yet differently.  Each option minimizes to the taskbar separately rather than grouped together:

XP Pro and TAS Premier rel. 12 runtime with Advanced Accounting, main program and three programs/forms minimized via standard chain commands with taskbar docked to right side of screen

The remaining obstacle

A new obstacle now that will remain is that despite the fact that programs should now minimize to the taskbar on any operating system that is in available and regardless of font settings, if a user launches another program or clicks on something that is running in their taskbar, they will have to minimize a running TAS RWN style program to allow the other application to come up on top.  We would have preferred to have these work like RUN forms do, but it isn't something that at least for now can work any other way.

Since TAS applications typically are critical accounting/financial solutions, keeping many of the programs as "top most" isn't completely illogical, but it also isn't something that we had intended to do: it was just the only solution to the problem.

Because of potential conflicts that could arise in calling other executables or simply in certain circumstances within the runtime environment, we also recognized that we had to provide some programmatic control to override the new "top most" behavior that a programmer could utilize when necessary.  And so a new function exists in release 12 by the same name as the Windows API function call that it makes:  SetWindowPos.   And the nice thing about it is that it can change the Z-order of the form and make it instead top, no[t] top most, bottom or top most after the form has been created.  While some situations may still represent a challenge, with also now the SetWindowPos() availability, most challenges this behavior causes should be capable of being overcome.

To allow the main menu program to still allow other third party programs to load on top of it, we recommend placing a function call to SetWindowPos() in the "OnDisplayScreen" (aka "OnShow") label of the main menu form since it does not need to be "top most" (but it will be by default be created that way starting with release 12).  There are several open file type dialogs that were not practical for us to force to be top most, and so function calls to get_file(), get_run_prg(), and dual_list_exec() will need to be reviewed within any application that uses them to add SetWindowPos() calls before and after their use.  Any use of exec and the TShellEXE will also need to be reviewed and tested.  See the help documentation for more information.  For the most part, relatively few changes should be required.

TAS Premier 7i release 12 published today

So release 12 is being published today with the extended "WinForm" styles as mentioned above, and it will also be the basis for the next major release of Advanced Accounting.  In addition to the SetWindowPos() function, it also includes a manifest embedded version targeted for various Microsoft operating systems including Windows 10, support for a "reply to" option in the TAS email function, a new "Page Style" band in the report designer, improvements to maintain database and other utilities including changes to issues relating to the extended form style change.  

More information:

TAS Premier 7i updates for existing installations

TAS Premier 7i download for new installations

This file is currently not available for use on this computer

An accounting software end user today experienced the message "This file is currently not available for use on this computer" when trying to click on existing icons on two client PC's trying to launch tp7runtime.exe via a previously established network share and both using UNC paths.  The software in the installed ("gateway") PC in this workgroup still worked as expected.

The user had not made any changes other than to install an Adobe Flash Player update on one of the two client PC's.   No doubt however these PC's received recent Microsoft (and last week was a bad week for those that led to numerous problems, more than usual) and anti-virus updates (which can suddenly change settings, block ports, etc.).

All three of the PC's were Windows 7 Professional.   The network had already been established as a "public network" and naturally everything had been working without any problem until this morning.  The user had already tried re-booting the PC's on the network to see if that would resolve the problem.  It did not.

Remotely viewing one of the client PC's that could not load the software as well as the gateway PC, we noticed that the icon that launches the software that in this situation had been previously set to "Run as administrator" now had that check box grayed out.   And in trying for troubleshooting purposes to setup a new icon, Windows returned the same "file is currently not available for use" message.   In navigating the available computers to set that icon, it showed the gateway PC's computer name twice which was very odd.   We did make sure that the UAC was not getting in the way.

A net view of the gateway PC that had also been mapped as a drive letter for some reason indicated something interesting in the comments:  [Offline share].   In trying to delete the drive map, Windows responded that files were in use but viewing the gateway PC where that drive was mapped, in fact there were no open files in the shared folder.  

While we could also navigate to and view all of the files in the shared folder (and could also see the files at CMD prompt via a DIR of the UNC path), when we tried to inspect a text (INI) file by opening it in Notepad, we received the same response:

We made some minor changes to some of the network settings on both PC's, and tried to stop and start various network services on the gateway PC; the issue remained.   While the sharing and file privileges all appeared to be correct on the gateway PC, we decided to stop sharing the folder and then re-share it after first disconnecting from the offline share (after also turning off the option to share files offline which seemed to have no effect).   That was completed and we re-added "Everyone" with read/write privileges.  In doing this, Norton Internet Security installed on the gateway PC came up with a prompt indicating that because it was a public network, certain Windows services were blocked. We decided to go ahead and allow Network Discovery, File and Printer Sharing and Remote Procedure Call and Remote Procedure Call (and so they were added to the NIS exception list) which seemed logical in that it had already been established as a public network.    

Re-testing, the client PC's were then able to once again launch the tp7runtime.exe application.

There have been other reports of this issue that have involved very different solutions.

Inserting special characters into data input fields

Recently an accounting software user asked us how to insert special characters or symbols such as the copyright and trademark related symbols into data entry fields such as inventory descriptions.

In Windows-based systems (including Advanced Accounting), there are several ways do to this.

(1) Direct data input method:

Special characters or symbols can be entered directly into string (aka alphanumeric) fields provided that you know what the symbol or character is (more on that below).  Examples:

™  (trademark superscript) Alt-0153

®  (trademark registration) Alt-0174

©  (copyright symbol)  Alt-0169

(Proper usage of these symbols is beyond the context of this post but generally: use trademarks as verbs rather than nouns whenever possible; do not use the trademark registration symbol unless the mark is actually officially registered with the USPTO; and the copyright symbol should always be followed the year and the copyright owner and not used by itself nor without the year.) 

Detailed steps to insert a special character or symbols into a data entry field:

• Press your keyboard's Num Lock key and/or make sure the Num Lock key is on;
• Press and hold one of the ALT keys (with your left hand;
• With your right hand and using ONLY the numeric key pad portion of your keyboard (and not the keys across the top), enter the four digit code (must be preceded by a zero);
• Let go of the ALT key.

Example of the ™ symbol entered into an Advanced Accounting 7i description field

You could also enter a special symbol into the message line or a sales order or purchase order or into any word-wrapped note (memo field) in the system.

But how do you determine what the code is for the desired symbol or character?

There are on-line lists and other references for these codes, but the simplest way perhaps is to lookup the code using the Character Map option provided in all Windows operating systems.

Windows 10 Character Map after clicking on  © symbol

So in the example above, clicking on the copyright symbol provides the ALT code for that symbol.

 (2) Copy/paste method:

For more or less any source you and also copy/paste in characters.

From the Windows Character Map, an example follows:

Windows 10 Character Map clicking on the ® symbol and clicking on Select

After clicking on the desired character or symbol then click on Select and then Copy and the character is available to be pasted (CTRL-V) into the desired data input field.

Regardless of the font chosen, the font will be 'converted' to the font that has been specified for that entry object on the underlying Windows data entry form. So the font will not necessarily be rendered in the same font as the source from which it was copied.  In Advanced Accounting, the default font is Arial and that is the font therefore that the special character or object would be rendered in after pasting it into the desired field.

Word processing programs typically have similar options from which special character or symbols can be copied and then pasted.  

Microsoft Office:
https://support.office.com/en-us/article/Insert-a-symbol-or-special-character-81e64967-74c0-4fd9-814a-3aa867d4cfce

OpenOffice:

https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/Writer_Guide/Special_characters



Additional information for TAS Premier 7i  programmers:

End users can utilize the direct entry method with a number of different objects including:

TTASENTER, TTASComboEnter, TASMemo, TMemo, TListBox and TTASDataGrid cells that are string-based.

Further, the direct data input (ALT) method will even work with label and button captions and data grid headers in the Screen editor (as well as with label captions and objects linked to data or that have TStrings properties in the Report designer) should you need to use a special character or symbol as a caption or header.

Form emulation with the TAS Premier Report Designer

Included with the TAS Premier development system is an integrated report designer that is based on a subset of features provided by the Digital Metaphors ReportBuilder software product.

The designer is intended to be used with program code that loads and provides the data pipeline to the report.   While not intended to be a report writer, the report setup nonetheless to a significant degree also "drives" the report.

While the designer can be launched and used as an end user tool to edit RTM layouts if provided for programs running within TAS runtime environment (in order to make basic changes for example), changes must be made with care to avoid making edits that change group fields or named objects or that add subreports or use fields related to files that are not opened in the program that the RTM was originally intended for.   Related fields may also not necessarily be available if added to the report depending on whether the underlying program code is making those related finds.   Edits could easily be made that would then cause a given report not to function at all.

While the report designer is most often used to provide traditional reports, it can also be used to include images and to accomplish form emulation including "fill in the blank" type forms.  And some objects can be used to emulate forms directly rather than via scanned images.

A brief discussion of the approach can be found here, which is further discussed below:

https://www.digital-metaphors.com/products/report_design/form_emulation.html 

There are different considerations in the report design depending on whether the form you wish to emulate is a single page or whether there are multiple pages (like various federal payroll tax forms).  It is also important to know whether or not there will be multiple records that need to be found in detail section within a single page.

Single page forms:  the simplest approach is to put everything in a detail band that is sized to the height of the page, eliminating all other report sections.    In this design, each record (or values accumulated into memory via temporary variables) is associated with a single form page.

If a variable number of records are required to complete the form, a different approach is required that involves use of a Page Style report band.  A Page Style band is like a Title,  Summary, Header, Detail or Footer band but was something not available in prior releases of TAS Professional and TAS Premier. 

Starting with release 12 of TAS Premier 7i that will be made available later this year, a Page Style band will be supported in the report designer as shown below.

Page Style band in rel. 12 of TAS Premier 7i

Page Style bands can also be used to add watermarks to invoices and other documents.  The Page Style band generates behind all of the other bands of a report.


Multi-page: similar considerations apply except that with multi-page forms, the page height bands, whether Detail or Page Style, each page needs to be separated into subreports.  The main layout page might have nothing more than a detail band with two or more subreports each of which might print a full height page.  Driving the report, in the simplest approach, just one record (or a single set of memory variables), might trigger the printing of both pages.  

For more details, see the detailed example at the end.

The possibilities for form emulation are almost endless.


Miscellaneous tips and comments:

Images:   A compromise between image size and printer overhead might be taken into consideration, however, we have used fairly large scanned forms in the 4 to 8 meg range and have not seen much of a performance difference.  The sharper the scan, the better the printer output quality.   We have found that bitmap (BMP) image files work very well for most forms.   Note that when using an image to take up basically the entire height/width of a page, it is best to first apply these properties to the image object: 

Uncheck Center
Check MaintainAspectRatio
Check Stretch

Next place the TppImage object in the upper left hand corner of the Detail or Page Style band you will be using.  Then with your mouse, pull the image down to the bottom of the band and then to the right.   

To optimally size the image, you may use digital editing software tools before bringing it into an RTM. For form emulation, you will want to use a TppImage (see Image object below) rather than a TppDBImage (not shown below).

Manually creating your own forms using shape objects:   Using the Shape and Line tools, you can create boxes and lines to mimic many types of forms.  You can even create "graybar" regions that alternate in the body.  (See example below.)

Forcing regions to fall behind Shape and Line objects requires a few steps. It is important to first uncheck the On Print Control Flag.  (Normally regions need "on print" control so it depends on what you are trying to accomplish.)   For a blank area on the form that will not be populated with any field values, turn it off or else it will not appear on the report output.  Also:

Blank out the default Caption name
Under Brush then Color choose a light gray color or create your own grayscale or other color
Under Pen, in the Style drop down, choose the "blank" (empty) style which is the sixth item down.

Region properties

Gray region example

After placing the region on top of a Shape object:

Right click on the region and choose Send to Back
Next choose (with a mouse left click) the Shape object and then right click on the same object and choose Send to Front, and finally right click again and choose Send to Back

The region will now be "behind" the Shape object as shown below:

Manually created form using Shape, Line, Region and Label objects.  The six regions above are all behind the shape and line objects.

Report previews:   when viewing the report in a preview, included image quality isn't the same as when the document is printed to a printer (or to a PDF) due to the way that images are rendered to the screen.  Don't worry if the report form doesn't look as sharp in the preview as expected.

Multi-page example

Two subreports on the main report designer page/tab with a detail band only. Add additional subreports if your form is more than two pages long.

The detail band of the main report page should be set to a dynamic print height.

Since the main report page is considered to be tag 1 by default, the first subreport is tag 2.  The tags are important and are referred to in program code.

The second report is tag 3 and also, note that subreport 2 must shift relative to the first subreport (otherwise it would print on top of the first subreport).  So, the ShiftRelative Property for the second subreport is a critical property.

Clicking on the first subreport tab.  The subreport for a form only would have only a detail band (or instead only a Page Style band).

Assuming a full page form, set the print height to be static and the height to take up the entire page. The height indicated is assuming a 0.5" bottom margin and 0.25" top margin so the subreport height is set to 10.25".

Clicking on the second subreport tab.  It too would only have a detail band.

As with the first subreport, set the print height to be static and the overall height to take up the full size of the page.

The TAS program code (placed in the Program editor and compiled) to generate the example above might look something like this (note how little code is required to setup and output the report and generate a print preview):

Note this is a simplistic example with no selection screen - normally there would be a #winform compiler directive followed by the screen name at the top of the program.

#forcerwn
#winreport MultiPageFormEmulation

//define fields and open files which is this example 
//would have to occur in the implied start label

start:

setup_report_buff rb_num 1 reportname 'MultiPageFormEmulation'
setup_report_buff rb_num 2 link_to 1
setup_report_buff rb_num 3 link_to 1


output_report_data rb_num 1

//now setup typically a SCAN data structure with desired logic
//to provide whatever data is desired to appear on the forms


//scan structure
   //rb_num 2 corresponds to the subreport1 tag
   output_report_data rb_num 2   //rb_num 3 corresponds to the subreport2 tag
   output_report_data rb_num 3
//ends

//output the report
print_report use_printer
quit
ret