@database "GetPayed guide" @author "Thomas Graff Thøger" @remark "$VER: GetPayed Guide 1.1 (24. May 1998)" @remark "Created with GoldED 4.4.1 (24.5.98)" @index INDEX @node MAIN "Velkommen" @{FG shine}GetPayed V1.1 Manual@{FG text} @{i}GetPayed ©1997-1998 by TigerSoft@{ui} @{"Legals " link Legals} Disclaimer and stuff... @{"Introduction " link Introduction} What's the program all about? @{"System requirements" link Requirements} What does it take to run GetPayed? @{"About MUI " link AboutMUI} GetPayed uses MUI. @{"Starting GetPayed " link StartGP} How to start GetPayed... @{"The project window " link WI_Project} Description of a project @{"The GetPayed menus " link PRJ_Menu} Description of the menus @{"ARexx commands " link RX_Main} GetPayed has an extensive ARexx support @{"Contact address " link Contact} How to contact TigerSoft @{"The future " link Future} The future of GetPayed @endnode @node Legals "Legals" GetPayed has been written and programed by Thomas Graff Thøger and has been released by TigerSoft into the ever growing pool of Shareware programs. Despite its status as a Shareware program all rights to the program and all of its accompanying files are reserved by Thoms Graff Thøger. Also, GetPayed must not be sold for a price higher than that of the expenses for copying and distributing the program without a written permission from Thomas Graff Thøger. Any Amiga magazine or any private person wanting to distribute this program on a magazine coverdisk, PD disks or collections such as Aminet and FredFish are free to do so as long as GetPayed is distributed in in its full form with all the originally included files, and as long as the above pricing limitation is being followed. Should you want to support the ShareWare concept, the registration fee for GetPayed is 100 Dkr, or what equals 100DKr in foreign currency (if sending cash only notes are accepted - only they can be exchanged). Payment can be done using eurocheque, postal money order or cash (which is not recommended - the money might get lost in mail!) Registrations must be send to this @{"address" link Contact}. DOCUMENTATION DISCLAIMER TIGERSOFT AND THOMAS GRAFF THØGER MAKES NO WARRENTIES, EITHER EXPRESSED OR IMPLIED, WITH RESPECT TO THE INFORMATION DESCRIBED HEREIN, ITS QUALITY, PERFORMANCE, MERCHANTABILITY, OR FITNESS FOR ANY PERTICULAR PURPOSE. SUCH INFORMATION IS PROVIDED ON AN "AS IS" BASIS. THE ENTIRE RISK AS TO THEIR QUALITY AND PERFORMANCE IS WITH THE USER. SHOULD THE INFORMATION PROVE DEFECTIVE, THE USER (AND NOT THE CREATOR, TIGERSOFT, THEIR DISTRIBUTORS, NOR THEIR RETAILERS) ASSUMES THE ENTIRE COST OF ALL NECESSARY DAMAGES. IN NO EVENT WILL TIGERSOFT BE LIABLE FOR DIRECT, INDIRECT, INCIDENTIAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT IN THE INFORMATION EVEN IF IT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THIS DISCLAIMER IS VALID FOR ALL TEXTFILES DISTRIBUTED, BOTH THE MANUAL FILES AND ANY OTHER INFORMATION DISTRIBUTED ALONGSIDE GETPAYED. PROGRAM DISCLAIMER TIGERSOFT AND THOMAS GRAFF THØGER MAKES NO WARRENTIES, EITHER EXPRESSED OR IMPLIED, WITH RESPECT TO THE PROGRAM GETPAYED, ITS QUALITY, PERFORMANCE, MERCHANTABILITY, OR FITNESS FOR ANY PERTICULAR PURPOSE. THIS PROGRAM IS PROVIDED ON AN "AS IS" BASIS. THE ENTIRE RISK AS TO ITS QUALITY AND PERFORMANCE IS WITH THE USER. SHOULD THE PROGRAM PROVE DEFECTIVE, THE USER (AND NOT THE CREATOR, TIGERSOFT, THEIR DISTRIBUTORS, NOR THEIR RETAILERS) ASSUMES THE ENTIRE COST OF ALL NECESSARY DAMAGES. IN NO EVENT WILL TIGERSOFT BE LIABLE FOR DIRECT INDIRECT, INCIDENTIAL, OR CONSEQENTIAL DAMAGES RESULTING FROM ANY DEFECT IN THE PROGRAM EVEN IF IT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. That being said, TigerSoft will appreciate any information regarding faulty operation of GetPayed, incorrect information in written documentations or the like. TigerSoft can be contacted using @{"this" link CONTACT} address. @endnode @node Introduction "Introduction" To say it like it is: GetPayed is a program for making payroll calculations! By entering information about when you've been working, the you've started the work, the time you've stopped the work and the duration of any breaks held during the working period GetPayed will calculate a full payroll calculation to let you easyly figure out how much you're entitled to be paid. The calculations themselves are based on a set of programable rules. I this way GetPayed is not directed towards a specific agreement, rather directed towards flexibility in its methods of payroll calculation. Once the workdata has been entered into GetPayed and the payment rules has been created, payroll calculations can be performed. The result of on or more payroll calculations is a payment report. In a payment report it is specified for each payment rule how much work has been done, the payment rate and the payment for the rule. After each payroll calculation a subtotal for the calculation is printed, and at the end of the payment report a total for the entire report is summed up. From GetPayed a payment report can be exported in various fileformats, and can thus be inserted into a wordprocessor where the final touch can be put on a payment report before it is printed on paper. The make GetPayed as flexible as possible the program has a builtin API (application programmers interface) opening up the possibility of adding new fileformats and rule types. By adding new fileformats GetPayed can be made to export payment reports and workdata directly to e.g. your wordprocessor. @endnode @node Requirements "System requirements" To use GetPayed your computer system must at least meet these minimum requirements: · Kickstart 3.x · MUI V3.3+ · Listree.mcc V17.x MUI custom class by Klaus Melchior · reqtools.library V38 @endnode @node AboutMUI "About MUI" This application uses MUI - MagicUserInterface (c) Copyright 1993-98 by Stefan Stuntz MUI is a system to generate and maintain graphical user interfaces. With the aid of a preferences program, the user of an application has the ability to customize the outfit according to his personal taste. MUI is distributed as shareware. To obtain a complete package containing lots of examples and more information about registration please look for a file called "muiXXusr.lha" (XX means the latest version number) on your local bulletin boards or on public domain disks. If you want to register directly, feel free to send DM 30.- or US$ 20.- to Stefan Stuntz Eduard-Spranger-Straße 7 80935 München GERMANY Support and online registration is available at http://www.sasg.com/ @endnode @node StartGP "Starting GetPayed" GetPayed can be run from both Workbench and CLI/Shell. When started from a CLI/Shell any parameters are given as arguments to the program name in the standard CLI way. If GetPayed is started from Workbench the exact same parameters can be used, only they need to be set in the GetPayed icon as tooltypes. To do so select the icon of GetPayed and choose the "Icon/Information..." item in the Workbench menus. These are the parameters understood by GetPayed: @{"HELPFILE " link TT_HelpFile} What is the filename of the AmigaGuide documentation? @{"PORTNAME " link TT_Portname} Default basename for ARexx ports @{"PRJPATH " link TT_PrjPath} The path for project files @{"REPPATH " link TT_RepPath} The path for report files @{"RULEPATH " link TT_RulePath} The path for rule files @{"AREXXPATH" link TT_ARexxPath} The path for ARexx scripts @endnode @node TT_PrjPath "ToolType: PRJPATH" @{b}ToolType:@{ub} PRJPATH @{b}Usage@{ub} PRJPATH= @{b}Description@{ub} Using this tooltype you can set the default path for project files. @endnode @node TT_RepPath "ToolType: REPPATH" @{b}ToolType:@{ub} REPPATH @{b}Usage@{ub} REPPATH= @{b}Description@{ub} Using this tooltype you can set the default path for payment report files. @endnode @node TT_RulePath "ToolType: RULEPATH" @{b}ToolType:@{ub} RULEPATH @{b}Usage@{ub} RULEPATH= @{b}Description@{ub} Using this tooltype you can set the default path for payment rule files. @endnode @node TT_ARexxPath "ToolType: AREXXPATH" @{b}ToolType:@{ub} AREXXPATH @{b}Usage@{ub} AREXXPATH= @{b}Description@{ub} Using this tooltype you can set the default ARexx script path. @endnode @node TT_HelpFile "ToolType: HELPFILE" @{b}ToolType:@{ub} HELPFILE @{b}Usage@{ub} HELPFILE= @{b}Description@{ub} With the HELPFILE tooltype it is possible to choose which AmigaGuide file will be used for online help in GetPayed. Normally GetPayed will use the AmigaGuide file "PROGDIR:docs/getpayed.guide" for online help. @endnode @node TT_Portname "ToolType: PORTNAME" @{b}ToolType:@{ub} PORTNAME @{b}Usage@{ub} PORTNAME= @{b}Description@{ub} The PORTNAME tooltype is used to change the default basename for ARexx ports opened by GetPayed. Normally a GetPayed project will have an ARexx port with the portname "GETPAYED." where is an ID number for making the various ARexx portsnames unique. By giving another basename all projects will instead open with an ARexx port named "." where is the name given using the PORTNAME tooltype. @endnode @node Contact "Contact address" Should you run into problems with GetPayed, should the ugly head of a bug show up, if you have any comments or ideas or if you want to register as a GetPayed user please contact TigerSoft in one of the following ways: @{b}Snail mail@{ub} TigerSoft Thomas Graff Thøger Dyrehavevej 4 3400 Hillerød Denmark @{b}E-Mail@{ub} INet: tigersoft@get2net.dk FidoNet: 2:236/332.34 @{b}The Web@{ub} www: hjem.get2net.dk/graff/tigersoft/ Even if you don't want to register as a user, but uses GetPayed anyway I'd still like to hear from you. It's always nice to know if anybody is using my program at all. @endnode @node Future "The future of GetPayed" @{b}The future of GetPayed@{ub} As things are at the moment I'm not sure if GetPayed has a future. Since the last version of the program about a year has passed and I have not heard a single word from other people about my program. If this is due to people disliking the program, or because they don't care to drop a line I don't know. But that, and the fact that I now have a job with one salery which makes my own payment calculations farely simple, does that I propably wont do anymore version of GetPayed. If you are happy with GetPayed and want a continued development then please @{"contact me" link Contact}, so I have some arguments for continued developments. My own ideas for improvements are · Extending the payment report system so comments can be inserted by payment rules. This could be used to implement warning reports if e.g. some part of an aggreement has been broken. · Better ARexx script support, so ARexx scripts can be inserted as menu items in the "User" menu. · More programs to aid in development of IO and rule extensions. · More fileformats (e.g. FinalWriter and WordWorth) · More ruletypes (your ideas please). @endnode @node WI_Project "The project window" @{b}The project window@{ub} Every project in GetPayed is represented by a project window. It is in this window that all normal operations regarding the project is done. The project window is split into two main parts - a button panel and the project data area. The @{"button panel" link PRJ_ButtonPanel} contains buttons for the most used functions such as loading and saving, clearing and opening new projects. The project data area is made up of two pages between which you can flick using two register pages. These two pages are the workdata page, and the report page. On the @{"workdata page" link PRJ_WorkdataPage} you edit your workdata, so GetPayed has something to base its payment calculations on. The @{"report page" link PRJ_ReportPage}, on the other hand, is the place where you issue payroll calculations and build your payment report. From the project's settings menu you have access to three more windows belonging to the project. That is the @{"rule editor" link WI_PayRuleEditor}, the @{"project fileformat" link WI_PrjExtSelector} selector and the @{"report fileformat" link WI_RepExtSelector} selector. The first window is for editing the payment rules used when doing payroll calculations. The latter two are used to select which filformat to use when saving projects or payment reports. @endnode @node PRJ_ButtonPanel "The button panel" @{b}The button panel@{ub} At the top of each project window there is a button panel. This panel gives easy access to some of the regularly used functions of GetPayed. These functions are @{"New " link BT_NewPrj} Create a new project @{"Clear..." link BT_ClearPrj} Clear (part of) the project data @{"Open... " link BT_OpenPrj} Load a project file into a new project window @{"Hent... " link BT_LoadPrj} Load a project file into the project window @{"Save " link BT_SavePrj} Save the project in a file @{"Year " link STR_Year} The year the project is representing @endnode @node BT_NewPrj "Button panel: New" @{b}Button panel: New@{ub} With this button you can open a new project. If GetPayed can't open a new project you will be informed through a requester. This will, however, only occur if you are running low on memory. @endnode @node BT_ClearPrj "Button panel: Clear..." @{b}Button panel: Clear...@{ub} The purpose of this button is to give easy access to erasing data from a project. When the button is selected you will be asked which data to erase. There are two possibilities: To erase the entire project or to erase only the currently active month on the @{"workdata page" link PRJ_WorkdataPage}. Ofcourse there is also the possibility of aborting the erase. If you choose to erase the entire project then all the workdata in the project will be erased without further warnings. The payment report on the report page will, however, not be erased. It is thus possible to create a payment report using workdata from more than one project. If you choose only to erase the currently active month it will only be the workdata in the month currently active on the @{"workdata page" link PRJ_WorkdataPage} which will be erased. @endnode @node BT_SavePrj "Button panel: Save" @{b}Button panel: Save@{ub} This button gives easy access to saving a project. If the project already has a filename it will be saved using that. Otherwise a filerequester will be opened prompting you for a filename. If a file with the filename you choose in the filerequester already exists you will be asked for confirmation before GetPayed overwrites the file. @endnode @node BT_OpenPrj "Button panel: Open..." @{b}Button panel: Open...@{ub} With this button you can load a project file into a new project. Once selected, a filerequester will ask you for the projectfile to open. A new project will be opened into which the projectfile will be read. The current project will therefore not be affected by this operation. @endnode @node BT_LoadPrj "Button panel: Load..." @{b}Button panel: Load...@{ub} With this button you can read a projectfile into the current project. The read project will overwrite any existing data in the current project. Therefore you will be asked to confirm the read if the current project is not saved. This operation does @{i}not@{ui} affect the current @{"payment report" link PRJ_ReportPage}. The payment report will remain untouched to allow for payment reports based on multiple projects. @endnode @node STR_Year "Button panel: Year" @{b}Button panel: Year@{ub} In this field you enter the year that the workdata describes. A project in GetPayed only describes one single year from January to December. In this field you have to give the precise year in which the work described by the workdata was carried out. The year must be given in full - that is "1998" instead of just "98" (which would be interpreted as the year 0098!) It is of utmost importance that the project year equals the year the work was carried out in. If the year is wrong, so will the payroll calculations be! This is due to GetPayed calculating which week and weekday a workdata entry describes. This data is found from the year and workdata date. So if the year is wrong GetPayed will think the work was done on another weekday, and thus calculate the payroll with the wrong extra-payments. @endnode @node PRJ_WorkdataPage "The workdata page" @{b}The workdata page@{ub} Th workdata page is the place where all your workdata is added to the project. It is the workdata added here which forms the basis for all payroll calculations. The page consists of a series of datapages, one for each month in the year, each showing the workdata you have added for that specific month. The month datapage which is shown is referred to in this document as the @{i}currently active month@{ui}. A row of textfields for @{"entering new workdata" link STR_DayData} is found underneath the datapages. Along with them you will also find buttons for modifying the workdata contents of a month: @{"Add day " link BT_AddDay} @{"Apply day" link BT_ApplyDay} @{"Kill day " link BT_KillDay} @endnode @node STR_DayData "Workdata page: Workdata fields" @{b}Workdata page: Workdata fields@{ub} When creating a new workdata entry in the active month you first type in the day data in these fields. You then select the @{"Add day" link BT_AddDay} button to actually create an entry from the data. The fields to fill in are... @{i}@{b}Date @{ub}@{ui} The daynumber of the day of the month the work was caried out on. If the work was done on the 10th in the active month this field should hold 10. @{i}@{b}Start @{ub}@{ui} This is the time of day when you started working. Hours and minute count must be sepparated by a colon. If no colon is typed the entire number will be interpreted as an hour count. If the work was initiated a quarter past ten, then the starttime will have to be entered as 10:15. @{i}@{b}Stop @{ub}@{ui} This is the time of day when you stoped working. Again, hour and minute count must be sepparated by a colon. If the work was ended af half past eight in the evening this field should hold the value 19:30. @{i}@{b}Pause @{ub}@{ui} Here you enter the total duration of all the breaks you've had during the day. This duration is also entered in hours and minutes, and again hours and minutes must be sepparated by a colon. If you had a total of 45 minutes break then you should enter the valiue 0:45, or just :45. @{i}@{b}Comments @{ub}@{ui} In this field you can put your own notes about the workdata entry. @endnode @node BT_AddDay "Workdata page: Add day" @{b}Workdata page: Add day@{ub} This button creates a new workdata entry in the active month of the project. The workdata to add must be entered into the @{"workdata fields" link STR_DayData} before selecting this button. Thise fields are placed just above the button. Before a new workdata entry is created GetPayed will check the workdata to catch any obvious mistakes in the data right away. If any contradictions are found in the data you will be informed about it. In such a case the workdata will not be added to the project. Contradicting workdata could forinstance be that the work is stoped before it was started, or that the duration of breaks is longer than the time interval between the start and stop times. @endnode @node BT_ApplyDay "Workdata page: Apply day" @{b}Workdata page: Apply day@{ub} This button modifies a workdata entry in the active month of the project. The workdata entry selected in the active month is the entry wich will be affected by the modifications. If no entry is selected in the active month this button will not be selectable. What this button do, is to change to contents of the selected entry to match that of the @{"workdata fields" link STR_DayData}. Just like when selecting @{"Add day" link BT_AddDay} the contents of the workdata fields will be checkes for errors before the workdata entry is modified. @endnode @node BT_KillDay "Workdata page: Kill day" @{b}Workdata page: Kill day@{ub} Using this button you can delete all selected workdata entries in the active month of the project. Ofcourse you will be asked for confirmation before anything is deleted from the project. @endnode @node PRJ_ReportPage "The report page" @{b}The report page@{ub} The report page is the place where you create payment reports. Here you issue new payroll calculations, and here you see the results. At the top of the page you can see the payment report of the project, and below you can see the total payment for the entire payment report. On the bottom half of the page you will find the controls for generating new payroll calculations. With these you set the @{"range" link STR_CalcRange} over which to create a payroll calculation. Amongst the controls you will also find a button panel enabling you to @{"issue a payroll calculation" link BT_Report}, @{"issue a new report" link BT_NewReport} and to @{"load" link BT_LoadReport} and @{"save" link BT_SaveReport} the current payment report. Furthermore you can also @{"load a new set of payment rules" link BT_SelRules}, which is a shortcut to the load function found in the @{"payment rule editor" link WI_PayRuleEditor}. @endnode @node STR_CalcRange "Report page: Calculation range" @{b}Report page: Calculation range@{ub} Here you specify which period of the year yo want to generate a payroll calculation in. The period can be set in either weeknumbers or monthnumbers. @{i}@{b}Calculate @{ub}@{ui} This field controls which timeunit the calculation range is specified in. You can either choose weeks or months as timeunit. @{i}@{b}From @{ub}@{ui} This field holds the number of the first week/month to include in the calculation range. January is indicated by the value 1 (the 1st month of the year). Week 1 of the calendar year is also indicated by the value 1. When using weeknumbers for specifying the calculation range you must be aware of the following: The first fays of a year might not necessarily be in week 1. They might be positioned in week 52 of the previous year! To make sure that all days in the beginnig of the year is included you should specify a week number of 0. @{i}@{b}To @{ub}@{ui} Here you set the number of the last week/month to include in the payroll calculation. As before January is indicated by a 1, and the first calendar week is indicated by a 1 as well. When using weeknumbers for the calculation range you must be aware of the following complications: The last couple of days in a year might not be in week 52. They might be in week 1 of the next year! To make sure all days at the end of the year is included you must set the To weeknumber to 53. @endnode @node BT_SelRules "Report page: Load rules" @{b}Report page: Load rules@{ub} This button is a shortcut to load a new set of payment rules into the project. The new rules will completely replace the old ones, and will be used in all new payroll calculations. In case the old payment rules has not been saved you will be asked to confirm before the rules are discarded. @endnode @node BT_NewReport "Report page: New report" @{b}Report page: New report@{ub} With this button you issue a new payroll calculation. The result of the calculation will @{i}replace@{ui} the old payment report! The period over which the payroll calculation is performed is taken from the @{"calculation range" link STR_CalcRange} controls. @endnode @node BT_Report "Report page: Report" @{b}Report page: Report@{ub} This button issues a new payroll calculation. The result of the calculation will be appended to the bottom of an already existing payment report. The calculation will be based on work during the period set with the @{"calculation range" link STR_CalcRange} controls. @endnode @node BT_LoadReport "Report page: Load..." @{b}Report page: Load...@{ub} With this button a previously saved payment report can be loaded into the project for further editing. The loaded report will replace the existing payment report. One thing to remember, though - you can only load a payment report if the report was saved in a fileformat for which you have an IO extension which can actually load payment reports. @{b}Just because an IO extension can save payment reports it does not mean that it also load reports! See the documentation for the IO extension to find out if it supports both loading and saving. @{ub} @endnode @node BT_SaveReport "Report page: Save..." @{b}Report page: Save...@{ub} THis button is used for saving the current payment report. The report will be saved using the fileformat selected in the @{"report fileformat selector" link WI_RepExtSelector}. Be adviced that just because an IO extension can save a payment report don't necessarily mean that it can also load reports! Some extension can maybe only read, while others maybe only will write. See the documentation for the individual IO extensions for more information on the extension's capabilities. @{b}If you want to be able to add more payroll calculations to your payment report at a later time you must save the report using a fileformat which can later be read into GetPayed again.@{ub} @endnode @node WI_PrjExtSelector "The project fileformat selector" @{b}The project fileformat selector@{ub} In this window you control the installed fileformats, also named IO extensions. These extensions are used for reading and writing projects using various fileformats. When reading a project GetPayed will automatically find the fileformat to use. If no suitable fileformat exists the file can't be loaded, and GetPayed will inform you of the error. When writing a project things are a bit different. The project will simply be written using the fileformat selected in this window. @{i}@{b}The fileformat list @{ub}@{ui} In the window there is a list of all installed fileformats which can handle project I/O. When double-clicking on a fileformat with the mouse you select the fileformat to be use whenever the project is written. @{i}@{b}The active fileformat @{ub}@{ui} This textfield, placed below the fileformat list, shows the name of the curently selected fileformat. The field will be ghosted if the fileformat marked in the fileformat list cannot write projects. This is only to indicate that it is not possible to choose the marked fileformat as the project write-fileformat, the fileformat actually named in the textfield will still be used for writing projects with. @{i}@{b}Fileformat preferences @{ub}@{ui} Next to the textfield you will see a button. This button opens the preferences program for the fileformat marked in the fileformat list. The preferences program will vary from fileformat to fileformat, so read the documentation for the fileformat to learn about its preferences program. If the button is ghosted the fileformat has no preferences program. At the time being only one of the fileformats distributed with GetPayed has a preferences program. This is the @{"text fileformat extension" link IOExt_Text}. @endnode @node WI_RepExtSelector "The report fileformat selector" @{b}The report fileformat selector@{ub} In this window you control the installed fileformats, also named IO extensions. These extensions are used for reading and writing payment reports using various fileformats. When reading a report GetPayed will automatically find the fileformat to use. If no suitable fileformat exists the file can't be loaded, and GetPayed will inform you of the error. When writing a report things are a bit different. The report will simply be written using the fileformat selected in this window. @{i}@{b}The fileformat list @{ub}@{ui} In the window there is a list of all installed fileformats which can handle report I/O. When double-clicking on a fileformat with the mouse you select the fileformat to be use whenever a report is written. @{i}@{b}The active fileformat @{ub}@{ui} This textfield, placed below the fileformat list, shows the name of the curently selected fileformat. The field will be ghosted if the fileformat marked in the fileformat list cannot write reports. This is only to indicate that it is not possible to choose the marked fileformat as the report write-fileformat, the fileformat actually named in the textfield will still be used for writing reports with. @{i}@{b}Fileformat preferences @{ub}@{ui} Next to the textfield you will see a button. This button opens the preferences program for the fileformat marked in the fileformat list. The preferences program will vary from fileformat to fileformat, so read the documentation for the fileformat to learn about its preferences program. If the button is ghosted the fileformat has no preferences program. At the time being only one of the fileformats distributed with GetPayed has a preferences program. This is the @{"text fileformat extension" link IOExt_Text}. @endnode @node IOExt_Text "The text fileformat extension" @{b}The text fileformat extension@{ub} This IO extension adds the possibility to save payment reports and the project's workdata as plain text. Be aware that this IO extension is @{b}not@{ub} able to read the files it writes! To make the fileformat as flexible as possible the output format is higly configurable. The configuration is changed from the preferences window. @{i}@{b}The preferences window @{ub}@{ui} The prefernces window has been split into three pages. One regarding @{"project" link IOExt_Text_WorkdataPage} writing, one regarding @{"payment report" link IOExt_TextReportPage} writing, and one page with @{"general" link IOExt_Text_GeneralPage} settings. @endnode @node IOExt_Text_WorkDataPage "Project preferences" @{b}Project preferences@{ub} This page contains settings regarding the writing of workdata from a project. @{i}@{b}Main header @{ub}@{ui} In this field you enter the text to be used as a header for the entire workdata file. @{"Codes" link IOExt_Text_ProjectCodes}: \t, \n %y @{i}@{b}Footer@{ub}@{ui} Here you type the text to be written at the bottom of the workdata file. @{"Codes" link IOExt_Text_ProjectCodes}: \t, \n %y @{i}@{b}Month header@{ub}@{ui} The text entered here will be used as header text for every month in the project, and printed before the workdata entries from the month. @{"Codes" link IOExt_Text_ProjectCodes}: \t, \n %i, %m, %M, %y @{i}@{b}Day entry@{ub}@{ui} In this field the text for describing a single workdata entry can be typed. @{"Codes" link IOExt_Text_ProjectCodes}: \t, \n %i, %m, %M, %w, %d, %D, %o, %n, %N, %f, %F, %t, %T, %p. %P, %c, %y @endnode @node IOExt_Text_ProjectCodes "Workdata codes" @{b}Workdata codes@{ub} \t Tabulator. \n Newline. %i The number of the current month. %m Abbreviated monthname of the current month. %M Full monthname of the current month. %w Weeknumber of the current week. %d Monthday number of the current workday entyr (1 = The 1st in the month). %D Weekday number of the current workday entry (1 = Monday). %o Yearday number of the current workday entry (1 = The 1st day of the year). %n Abbreviated weekday name of the current workday entry. %N Full weekday name of the current workday entry. %f Hour count of the beginning of work for the current workday entry. %F Minute count for the beginning af work... %t Hour count of the end of work for the current workday entry. %T Minute count for the end af work... %p Hour count of the total duration of breaks for the current workday entry. %P Minute count of the total duration of breaks... %c The comment for the curent workday entry. %y The year the project represents. @endnode @node IOExt_Text_ReportPage "Payment report preferences" @{b}Payment report preferences@{ub} On this page all the preferences regarding payment report writing is placed. @{i}@{b}Main header@{ub} @{ui} This text will be inserted at the top of the finished payment retport file. The %y code will insert the year of the project form which the payment report is being saved. @{"Codes" link IOExt_Text_ReportCodes}: \t, \n %y @{i}@{b}Footer@{ub}@{ui} This text will be inserted at the very bottom of the payment report file. @{"Codes" link IOExt_Text_ReportCodes}: \t, \n %s @{i}@{b}Subheader@{ub}@{ui} The text in this field will be inserted as a subheader before every payroll calculation featured in the payment report. @{"Codes" link IOExt_Text_ReportCodes}: \t, \n %f, %F, %t, %T, %u, %y @{i}@{b}Rule entry{ub}@{ui} This text will be inserted for every payment rule that was used for the calculation of the payroll. @{"Codes" link IOExt_Text_ReportCodes}: \t, \n %n, %r, %d, %s, %f, %F, %t, %T, %u, %y @{i}@{b}Text entry@{ub}@{ui} This text will be inserted for every textline entry in the payment report. The text from the payment report is not automatically inserted in the fle. For maximum flexibility you have to indicate where to put the text from the report using the %n code. If nothing else but the text from the payment report is wanted, simply type "%n" in this field. @{"Codes" link IOExt_Text_ReportCodes}: \t, \n %n, %f, %F, %t, %T, %u, %y @{i}@{b}Total entry@{ub}@{ui} This text will be inserted after every payroll calculation in the report. @{"Codes" link IOExt_Text_ReportCodes}: \t, \n %s, %u, %y @{i}@{b}Week@{ub}@{ui} This is the text used for insertion at a %u code if the payroll calculation has been made with a calculation range given in weeks. This textfield is implemented to allow localizatin of the word "week". @{"Codes" link IOExt_Text_ReportCodes}: None allowed @{i}@{b}Monht@{ub}@{ui} This is the text used for insertion at a %u code if the payroll calculation has been made with a calculation range given in months. This textfield is implemented to allow localization of the word "month". @{"Codes" link IOExt_Text_ReportCodes}: None allowed @endnode @node IOExt_Text_ReportCodes "Payment report codes" @{b}Payment report codes@{ub} \t Tabulator. \n Newline. %n The name of the report entry. E.g. the name of a payment rule, the text from a text entry, and so on. %r The payment rate of a payment rule. %d The total usage duration of a payment rule. %s The total payment for a payment rule or the entire payment report (depending on which entry type we're talking about). %f The starting point of a payroll calculation. This is a number - either a week-, or monthnumber (both with 1 as the first number). %F As %f, with one addition: If the payroll calculation range is given in months the name of the month will be inserted instead of the month number. %t As %f, only this is the end point of the payroll calculation. %T As %F, only this is the end point of the payroll calculation. %y The year (of a project) from which the payroll calculation comes. %u The unit of a calculation range. This is either "week" or "month". Well, actually it is the text which is entered in the preferences program as being the "week" or "month" text. @endnode @node IOExt_Text_GeneralPage "General preferences" @{b}General preferences@{ub} This page contains general settings used when both writing payment reports and project workdata. @{i}@{b}Locale@{ub}@{ui} Her you type the path and filename of a locale file made with the AmigaOS' Locale preferences program. If a locale filename has been set it will be used for obtaining general data localized to the country and language chosen in the file. In this way decimal point and month/weekday names are dependant on which country/language chosen. If no locale filename is given the system default locale information will be used. @endnode @node PRJ_Menu "The menu" GetPayed's menu Choose your menu item... @{FG shine}Project@{FG text} @{FG shine}Report@{FG text} @{FG shine}Settings@{FG text} @{FG shine}User@{FG text} @{" New " link MN_Prj_New} @{" Load... " link MN_Rep_Load} @{" Payment rules... " link MN_Set_EditRules} @{" Run ARexx... " link MN_User_RunARexx} @{" Clear " link MN_Prj_Clear} @{" -----------" link MN_Barlabel} @{" -----------------" link MN_Barlabel} @{" Open... " link MN_Prj_Open} @{" Save... " link MN_Rep_Save} @{" Project saver... " link MN_Set_PrjSaver} @{" Load... " link MN_Prj_Load} @{" -----------" link MN_Barlabel} @{" Report saver... " link MN_Set_RepSaver} @{" -------------" link MN_Barlabel} @{" Report " link MN_Rep_Report} @{" -----------------" link MN_Barlabel} @{" Save " link MN_Prj_Save} @{" New report " link MN_Rep_NewReport} @{" MUI... " link MN_Set_MUI} @{" Save as... " link MN_Prj_SaveAs} @{" -----------------" link MN_Barlabel} @{" -------------" link MN_Barlabel} @{" Load... " link MN_Set_Load} @{" Close project" link MN_Prj_Close} @{" Save... " link MN_Set_Save} @{" -------------" link MN_Barlabel} @{" Save default " link MN_Set_SaveDefault} @{" About... " link MN_Prj_About} @{" About MUI... " link MN_Prj_AboutMUI} @{" -------------" link MN_Barlabel} @{" Quit " link MN_Prj_Quit} @endnode @node MN_Barlabel "Menu: Sepparator" @{b}Menu: Sepparator@{ub} This menu item does nothing. It is only in the menu to make it easier to get an overview of the funktions. @endnode @node MN_Prj_New "Project menu: New" @{b}Project menu: New@{ub} When this menu item is selected a new empty project will be opened. The created project will have the default preferences - the preferences last saved with the @{"Preferences/Save default" link MN_Set_SaveDefault} menu item. If GetPayed cannot open a new project you will be informed hereof. This will, however, only occur if you are running low on memory. @endnode @node MN_Prj_Clear "Project menu: Clear" @{b}Project menu: Clear@{ub} With this menu item it is possible to clear all workdata in a project. The payment report of the project will remain intact. This is also the case with the payment rules defined for the project. If the project has been modified since it was last saved you will be asked to confirm the clear. @endnode @node MN_Prj_Open "Project menu: Open" @{b}Project menu: Open@{ub} With this menu item you can load a project from disk. The projectfile will be loaded into a new project. When this menu item is selected you will be asked for the project file to open through a standard filerequester. Once a file has been selected GetPayed will start reading it into the new project. If the project file contains information about payment rules then the rules will be read into the project as well. @endnode @node MN_Prj_Load "Project menu: Load" @{b}Project menu: Load@{ub} This menu item lets you read a projectfile into an existing GetPayed project. The contents of the projectfile will replace the existing workdata. Once selected, a filerequester will open, asking you for a file to load. If the existing project contents has not been saved you will be asked to confirm the action. Once a file has been selected GetPayed will start reading it into the new project. If the project file contains information about payment rules then the rules will be read into the project as well. @endnode @node MN_Prj_Save "Project menu: Save" @{b}Project menu: Save@{ub} With this menu item you save your project to disk. If the project already has a filename it will be saved using that name. Else a filerequester will open asking you for a filename to use. If the filename you specify already exist you will be asked to confirm before GetPayed overwrites anything. @endnode @node MN_Prj_SaveAs "Project menu: Save as" @{b}Project menu: Save as@{ub} This menu item lets you save a project using a different filename. Once the menu item is selected you will be asked for a filename to use for the project. Should a file already exist with the filename you specify GetPayed will ask you for confirmation before it overwrites anything. @endnode @node MN_Prj_Close "Project menu: Close project" @{b}Project menu: Close project@{ub} Choosing this menu item will close the current project. If the project has not been saved you will be asked to confirm the project closing. This menu item offers the same functionality as the window close symbol. @endnode @node MN_Prj_About "Project menu: About" @{b}Project menu: About@{ub} This menu item will open a window with information about GetPayed. @endnode @node MN_Prj_AboutMUI "Project menu: About MUI" @{b}Project menu: About MUI@{ub} Choose this menu item if you want to know more about MUI. @endnode @node MN_Prj_Quit "Project menu: Quit" @{b}Project menu: Quit@{ub} When you choose this menu item GetPayed will terminate. You will be asked to confirm the closing of all existing projects not saved. Should you decline to one of the confirmations GetPayed will cancel the termination and return to normal program execution. @endnode @node MN_Rep_Load "Report menu: Load" @{b}Report menu: Load@{ub} With this menu item you can read a payment report into the project. When you select this menu item you will be prompted for a filename of the payment report to read. Any existing payment report existing in the project will be cleared before the new report is loaded. @endnode @node MN_Rep_Save "Rapport menu: Save" @{b}Report menu: Save@{ub} With this menu item the payment report of a project can be saved. When you select the menu item a filerequester will open prompting you for the filename to use for saving the payment report. The payment report will be saved using the currently selected report fileformat, selected using the @{"report fileformat selector" link WI_RepExtSelector.}. @{b}Note: @{ub} It is @{b}not@{ub} all repport fileformats which can @{i}both@{ui} read and write payment reports. So make sure you choose a fileformat suitable to your needs. @endnode @node MN_Rep_Report "Report menu: Report" @{b}Report menu: Report@{ub} When this menu item is selected GetPayed will carry out a payroll calculation. The calculation result will be appended to the project payment report. The calculation is based upon the calculation range currently set in the report @{"control fields" link BT_CalcRange}. @endnode @node MN_Rep_NewReport "Report menu: New report" @{b}Report menu: New report@{ub} With this menu item you issue a new payroll calculation. The result of the calculation will replace any existing payment report in the project. The calculation is based upon the calculation range currently set in the report @{"control fields" link BT_CalcRange}. @endnode @node MN_Set_EditRules "Preferences menu: Payment rules" @{b}Preferences menu: Payment rules@{ub} This menu item will open the payment rule editor. The payment rule editor is the place where you define all the payment rules, used when doing payroll calculations, and their dependicies. See the description of the @{"payment rule window" link WI_PayRuleEditor} for further information. @endnode @node MN_Set_PrjSaver "Preferences menu: Project saver" @{b}Preferences menu: Project saver@{ub} This menu item opens the @{"project fileformat selector" link WI_PrjExtSelector}. Here you can select the fileformat to use when saving projects. @endnode @node MN_Set_RepSaver "Preferences menu: Report saver" @{b}Preferences menu: Report saver@{ub} This menu item opens the @{"report fileformat selector" link WI_RepExtSelector}. Here you can select which fileformat to use when writing payment reports. @endnode @node MN_Set_MUI "Preferences menu: MUI" @{b}preferences menu: MUI@{ub} When you select this menu item the MUI preferences window will open. The MUI preferences window lets you change many aspects of the GetPayed userinterface design, e.g. the window backdrops, button colors, font styles etc. See the MUI documentation for further information. @endnode @node MN_Set_Load "Preferences menu: Load..." @{b}Preferences menu: Load...@{ub} With this menu item you can read a new set of preferences to use in the project instead of the current preferences. Once the menu item is selected you will be asked for the filename of the preferences file to open. A preferences file also holds the settings from all the fileformat extensions. @endnode @node MN_Set_Save "Preferences menu: Save..." @{b}Preferences menu: Save...@{ub} This menu item will let you write the current preferences to disk. Once selected you will be asked for a filename for the preferences file. A preferences file holds the prefences from all extensions as well as the GetPayed specific ones. The MUI settings will, however not be stored. The MUI settings is sololy handled from the @{"MUI preferences window" link MN_Set_MUI}. @endnode @node MN_Set_SaveDefault "preferences menu: Save default" @{b}Prefernces menu: Save deafult@{ub} Selecting this menu item will save the current project prefences as the default project prefernces. This means that in the future whenever GetPayed opens a new project it will have these settings @endnode @node MN_User_RunARexx "User menu: Run ARexx..." @{b}User menu: Run ARexx...@{ub} Choosing this menu item you can start an ARexx script from GetPayed. When selected, a file requester will open asking you for the ARexx script to run. @{b}For this menu item to work the command "run" must be available in your system. This usually implies having it in the "SYS:c" drawer. @{ub} See the ARexx user manual for more information on ARexx. The manual is delivered with the AmigaOS. @{b}Note@{ub} All ARexx scripts run through this menu item will get the portname of the project as argument. It is thus possible for an ARexx script to find out from which project it was run. Use a snip of code like this to get the portname: Parse UPPER ARG portname if Left( portname, 1 ) = '"' then do /* Strip leading " */ portname = Right( portname, Length( portname ) - 1 ) end if Right( portname, 1 ) = '"' then do /* Strip trailing " */ portname = Left( portname, Length( portname ) - 1 ) end You will now have the portname of the project in the portname variable. Remember to use ADDRESS VALUE instead of ADDRESS when addressing the port using the variable. @endnode @node WI_PayRuleEditor "The payment rule editor" @{b}The payment rule editor@{ub} The payment rule window is the place where you create all the payment rules which will be used for calculating payrolls. The window is split into three pages, each dealing with a sepparate step in defining the payment rules (the @{"payment rules" link GR_PayRules}, the @{"payment procedures" link GR_PayProc} and the @{"payment program" link GR_PayProg}), and a small button panel allowing you to @{"load" link BT_LoadRules} and @{"save" link BT_SaveRules} payment rules. @endnode @node BT_LoadRules "Payment rule editor: Load rules..." @{b}Payment rule editor: Load rules...@{ub} With this button you can load a new set of payment rules into the project. Any old payment rules in the project will be replaced with the new ones. You will be presented with a filerequester in which you must select the payment rules file to load. If the current payment rules have not been saved you will be asked to confirm the loading. @endnode @node BT_SaveRules "Payment rule editor: Save rules as..." @{b}Payment rule editor: Save rules as...@{ub} This button lets you save the current payment rules to disk. Once selected a filerequester will prompt you for a filename for the rules file. If a file should exist with the filename you type in you will be asked to confirm overwriting of the old file. @endnode @node GR_PayRules "Payment rule editor: The payment rule page" @{b}The payment rule page @{ub} On this page in the payment rule editor you create and modify all the basic payment rules which is needed to form payment procedures, and, in the end, the payment program. On the left side of the page there is a list of all available payment rule types. On the right side is a list of all the actually created payment rules. To create a new payment rule you double click on a rule type in the left list. Alternatively you can select a rule type in the left list and then press the @{"Add rule" link BT_PR_AddRule} button. All new rules are named "Unnamed". You are therefore adviced to change the name of the new rule the moment you have created it to avoid confusion. Renaming a rule is done by first selecting it, and then changing the contents of the textfield below the payment rule list. Between the two lists there is a section of buttons. These are used to modify the payment rules in the payment rule list: @{"Add rule " link BT_PR_AddRule} @{"Del rule " link BT_PR_DelRule} @{"Edit rule " link BT_PR_EditRule} @{"Rule limit" link WI_PayNodeLimit} @endnode @node BT_PR_AddRule "Rules page: Add rule" @{b}Rules page: Add rule@{ub} When this button is pressed a new payment rule will be created. The type of rule created depends on the rule type selected in the list of rule types. Instead of pressing this button to make a new rule you can simply double click on a rule type. @endnode @node BT_PR_DelRule "Rules page: Del rule" @{b}Rules page: Del rule@{ub} When this button is pressed the rules marked in the payment rule list will be deleted. Before the rules are deleted you will be asked for a confirmation. @endnode @node BT_PR_EditRule "Rules page: Edit rule" @{b}Rules page: Edit rule@{ub} When this button is selected the settings window for the selected payment rule will be opened. In this window you can set all the rule specific settings. The exact contents of this window depends on the type of rule selected. As it is possible for 3rd party developers to add their own rule types to GetPayed it is not possible to describe the various settings windows here. You will have to read the documentation which accompanied the rule type. Along with GetPayed TigerSoft has distributed some basic payment rule types, which you can read about @{"here" link StdRules}. @endnode @node WI_PayNodeLimit "Rule limiting window" @{b}Rule limiting window@{ub} Using the controls of this window it is possible to alter the range of time in which a payment rule or procedure is valid (is able to participate in payment calculations, that is). The limiting can be made by limiting usage of the rule/procedure to only certain weekdays, a maximum number of uses within a given time limit, or to a certain date of the year. It is also possible to do a combination of the three, which makes it possible to limit the usage of a rule/procedure to e.g. the 8th of May, if that date is a Tuesday. The limiting has, appropriately, been split into three groups, each corresponding to a limiting method: @{"Weekdays " link GR_WeekdaysLimit} @{"Usage limiting" link GR_UsageLimit} @{"Specific date " link GR_SpecificDateLimit} @endnode @node GR_WeekdaysLimit "Limiting window: Weekdays" @{b}Limiting window: Weekdays@{ub} In this group you decide which days of the week the payment rule/procedure can participate in payroll calculations. For each day of the week there is a checkmark field. If this field is checked the rule/procedure will participate in payroll calculations on that particular weekday. @endnode @node GR_UsageLimit "Limiting window: Usage limiting" @{b}Limiting window: Usage limiting@{ub} This group of controls handle the usage limiting of a payment rule or payment procedure. The usage limiting is a little more complex than the two other limiting methods, and is thus a little more dificult to get to grips with. The basic idea of usage limiting is to limit a rule/procedure to only be able to be used a maximum of X times during a given time interval. In this version of GetPayed the time interval can be given in either weeks or months. @{b}Limit usage@{ub} In the top of the group of controls you will find this checkmark field. If this field is checked usage limiting is activated for the rule/procedure. @{b}to max@{ub} In this field you have to enter the maximum number of times the rule/ procedure can be used within the time interval. @{b}times per@{ub} Her you insert the number of time units you want the time interval to consist of. @{b}@{ub} Here you choose the time unit which "@{i}times per @{ui}" is given in. In this version you can choose between to units - weeks or months. In case you are wondering about the strange names of the fields, then there is a logical explanation. The fields has been named to let the entire group be readable as a sentence. If you read through the controls you will get a sentence saying "Limit usage (Yes/No) to max times per ". By the way, one thing to note about the time unit is, that while the rule/procedure is limited to X uses in Y time units the internal usage count stored by GetPayed is updated on a 1 time unit basis. OK, an example: You have a rule which is limited to be used max. 4 times in 2 weeks. During calculation of the first two weeks GetPayed will limit the usage when the rule has been used 4 times. After the first two weeks GetPayed will forget about any usage in the first week, and thus only remember the number of uses in the 2nd week of calculation. Now the current week will be used by GetPayed as the 2nd week of the limiting interval, and GetPayed will thus step through the calculation range with a stepsize of one time unit. @endnode @node GR_SpecificDateLimit "Limiting window: Specific date" @{b}Limiting window: Specific date@{ub} In this groups you will find controls to limit a payment rule/procedure to only be usable on one specific date in the year. @{b}Specific date@{ub} This is a checkmark field. If checked the rule/procedure is limited to only being usable on the specified date. @{b}Month@{ub} Here you set the month of the specific date. @{b}Day@{ub} Here you set the day of month for the specific date. @endnode @node GR_PayProc "Payment rule editor: The payment procedure page" @{b}Payment rule editor: The payment procedure page@{ub} This page of the payment rule editor is dedicated to creating payment procedures. A payment procedure is a combination of payment rules which can be used in the payment program. By using payment procedures it is possible to create complex combinations of payment rules and then use them in the payment program, instead of having to create the same complex combination multiple times in the payment program Further more you can specify a payment procedure to be treated as one single unit. Using this feature all payment rules in the payment procedure will be reported as one entry in a payment report, using the name of the procedure. On the left side of the payment procedure page you will find a list of all the created payment rules. These can be inserted into the current payment procedure where they can then be sorted to give the desired functinality. On the right side of the page the current payment procedure is shown. It is visualized using a @{"tree of payment rules" link CL_RuleTree}. The setup of the rules in the tree can be modified by draging and droping the payment rules within the tree structure. Above the payment procedure rule tree the name of the name of the current payment procedure is shown. Changing the name in this field will change the name of the payment procedure. To the rigth of the name field is a small button. Pressing this button will open a list of all existing payment procedures. Double clicking on a payment procedure in this list will make it the current payment procedure. Below the list of payment procedures there are two buttons. One, @{i}New@{ui}, for creating a new payment procedure, and one, @{i}Delete@{ui}, which deletes the payment procedure current selected in the list (@{i}not @{ui}the current procedure). Below the payment procedure rule tree is a checkmark field named @{i}Simple rule@{ui}. If this field has been checked then the payment rule selected in the payment procedure rule tree is marked as being a simple rule. A simple rule is a rule which have no sublist (failure list) of payment rules. Therefore GetPayed will never try to branch into the rule's failure list even if the rule did not apply to a workdata entry during payment calculations. This feature must be used each time you insert a payment rule which should not control the course of a payment calculation. Between the two lists you will find a column of buttons. These buttons are used to add the selected payment rule to the current payment procedure, deleting the selected payment rule in the payment procedure tree and to open the @{"limiting window" link WI_PayNodeLimit} for the payment procedure. Below the buttons is a checkmark field named Unified. If this field is checked the payment procedure is treated as being unified when it is reported after a payroll calculation. When a payment procedure is unified all payment rules in the procedure will be reported using a single entry in the payment report under the name of the payment procedure. In a unified procedure all payment rules will get the same payment rate. The used payment rate is taken from the first payment rule in the procedure. @endnode @node GR_PayProg "Payment rule editor: Payment program page" @{b}Payment rule editor: Payment program page@{ub} On this page you create the final payment rule program. The payment program is the setup of payment rules and procedures which are used when doing payroll calculations. On the left side is two smaller pages, Procedures and rules. These pages contains lists of the payment procedures and rules which you've created. It is using these you build the final payment program. On the right side is a @{"payment rule tree" link CL_RuleTree} describing the payment program. By choosing a payment procedure or rule in one of the left lists and press the @{i}Add@{ui} button it will be inserted into the payment program. After inserting items in the payment program tree you can sort them by draging and droping the items with the mouse. Between the procedure/rule lists and the payment program tree there are two buttons. These are used for adding the selected payment rule/procedure to the payment program (@{i}Add@{ui}), or deleting the selected entry in the payment program (@{i}Delete@{ui}). Underneath the payment program rule tree there is a checkmark field named Simple entry. If this field is checked the payment rule/procedure selected in the payment program tree is marked as being a simple entry. What this means is, that GetPayed never will enter its failure branch when doing payment calculations (see @{"payment rule tree description" link CL_RuleTree}). A simple entry is a rule/procedure which have no sublist (failure list) of payment rules/procedures. Therefore GetPayed will never try to branch into the its failure list even if it did not apply to a workdata entry during payment calculations. This feature must be used each time you insert a payment rule/procedure which should not control the course of a payment calculation. @endnode @node CL_RuleTree "Payment rule tree" @{b}Payment rule tree @{ub} Payment rule trees are the backbone of the GetPayed payment rules editor userinterface. They are used to visualized the structure of a payment procedure or of the payment program. @{b}An overview@{ub} The best describe a payment rule tree (from now on a payrule tree) we have to define some things first. Any entry in a payrule tree (be it a procedure or rule) has two lists (or branches) of entries beneath itself. The one branch, the success branch, is visually going straight down vertically on the screen. The other branch, the failure branch, is the one going one level into the visual tree structure. When GetPayed performs payroll calculations each and every working day (each workdata entry, that is) will be testet against the payment program, and will as such be testet against all payment procedures and rules which it encounters on its way. If it, when a workdata entry is testet against a payment rule, shows up that the payrule will contribute to the total payment for this particular workdata entry the test is seen as a success, and GetPayed will continue the payroll calculation along the success branch of the payment rule. If it shows up that the payment rule does not add to the total payment for the workdata entry the test is seen as a failure, and GetPayed will continue the payroll calculation along the failure branch of the rule. One execption to this is if the rule has been marked as a simple rule. In such a case GetPayed will continue the calculation along the success branch irrespective of the test result. When a workdata entry is testet against a payment procedure the result of the test will be the result of the last test against a payment rule done in the procedure. If the test is a success the test against the procedure is a success, is it a failure the test against the procedure will return failure. One note to make here is, that a simple rule always tests as the real test result, even though GetPayed always continues through the success branch. @{b}Sorting a payrule tree@{ub} The result of a payroll calculation is, as should be evident from the above discussion, very dependant on the positions of individual rules or procedures in the payrule tree. It is therefore necessary to sort the entries in the rule tree to get the wanted relations between them. Sorting the entries is done by drag and drop using the mouse. First you select the rule/procedure to move in the tree, and then you drag it (still holding down the mouse button) to where you want it to be placed, and finally you release the mouse button. If an entry(1) is droped onto another entry(2) the just droped entry(1) will be inserted into the failure branch of entry(2). An entry can, for obvious reasons, not be droped on itself - how on earth should it be able to place itself in its own failure branch?? ;-) To increase the easy of use any entry in a payrule tree can have its failure branch either hidden or shown. To hide/show the failure branch of an entry you simply double click on it with the mouse. @endnode @node StdRules "Standard rule types" @{b}Standard rules@{ub} To make it possible to actually create any payment rules a couple of simple rule types are delivered along with GetPayed: @{b}Time range in a day@{ub} This rule type is the only real basic rule type. It is used for creating a basic rule saying "between this and that time the salary is this". Using the @{"limiting window" link WI_PayNodeLimit} you can then limit the usage of the rule to specific weekdays and so on. This rule type has a @{"settings window" link WI_RDayEditor} in which you set up the rule as you want it. @{b}True@{ub} This rule type has been created to be able to control the flow of the payment program when using payment procedure. Normally the result of a payment procedure is the result of the last payment rule used in the procedure. If this result is not the wanted procedure result you can force the procedure to returna logic true result by placing a rule of this type at the end of the branch in the procedure. @{b}False@{ub} Using this rule type the result of a payment procedure can be forced to be false. A rule of this type only affects the branch of the procedure in which it is placed (and then only if it is the last rule on the branch!). This works just like the @{i}True@{ui} rule type, only it returns false. @endnode @node WI_RDayEditor "Time range in a day" @{b}"Time range in a day" settings window@{ub} This settings window is used for configuring a "time range in a day" rule to meet your needs. @{b}From@{ub} Here you set the hour and minute from which the rule will be active. @{b}To@{ub} Here you set the hour and minute until which the rule will be active. If this is earlier than the @{i}From@{ui} time the rule will never become active. Furthermore you may end up with an error message from GetPayed during payroll calculations. @{b}Payment rate@{ub} Here you type in the payment rate for the rule. This must be set in payment per hour work. @{b}OK@{ub} With this button you accept the settings, and close the settings window. @{b}Cancel@{ub} With this button you close the settings window without keeping the changes you may have made to the rule settings. @endnode @node RX_Main "ARexx commands" The ARex port in GetPayed supports the following commands: @{FG shine}Standard commands (Amiga Style Guide compliant)@{FG text} @{"ACTIVATE " link RX_CMD_Activate} @{"ACTIVATEWINDOW" link RX_CMD_ActivateWindow} @{"CHANGEWINDOW " link RX_CMD_ChangeWindow} @{"CLEAR " link RX_CMD_Clear} @{"CLOSE " link RX_CMD_Close} @{"DEACTIVATE " link RX_CMD_Deactivate} @{"ERASE " link RX_CMD_Erase} @{"LOCKGUI " link RX_CMD_LockGUI} @{"MOVEWINDOW " link RX_CMD_MoveWindow} @{"NEW " link RX_CMD_New} @{"OPEN " link RX_CMD_Open} @{"QUIT " link RX_CMD_Quit} @{"REQUEST " link RX_CMD_Request} @{"REQUESTFILE " link RX_CMD_RequestFile} @{"SAVE " link RX_CMD_Save} @{"SAVEAS " link RX_CMD_SaveAs} @{"SIZEWINDOW " link RX_CMD_SizeWindow} @{"UNLOCKGUI " link RX_CMD_UnlockGUI} @{"UNZOOMWINDOW " link RX_CMD_UnzoomWindow} @{"WINDOWTOBACK " link RX_CMD_WindowToBack} @{"WINDOWTOFRONT " link RX_CMD_WindowToFront} @{"ZOOMWINDOW " link RX_CMD_ZoomWindow} @{FG shine}GetPayed specific commands@{FG text} @{"ADDDAY " link RX_CMD_AddDay} @{"CALCFROM " link RX_CMD_CalcFrom} @{"CALCTO " link RX_CMD_CalcTo} @{"CALCUNIT " link RX_CMD_CalcUnit} @{"CURDAY " link RX_CMD_CurDay} @{"DAYS " link RX_CMD_Days} @{"DELDAY " link RX_CMD_DelDay} @{"GETDAY " link RX_CMD_GetDay} @{"GETFILE " link RX_CMD_GetFile} @{"GETPATH " link RX_CMD_GetPath} @{"IOEXTENSION " link RX_CMD_IoExtension} @{"MARK " link RX_CMD_Mark} @{"MONTH " link RX_CMD_Month} @{"OPENPREFS " link RX_CMD_OpenPrefs} @{"OPENREPORT " link RX_CMD_OpenReport} @{"PAYMENT " link RX_CMD_Payment} @{"REPORT " link RX_CMD_Report} @{"SAVEPREFS " link RX_CMD_SavePrefs} @{"SAVEPREFSAS " link RX_CMD_SavePrefsAs} @{"SAVEREPORT " link RX_CMD_SaveReport} @{"SAVEREPORTAS" link RX_CMD_SaveReportAs} @{"SETFILE " link RX_CMD_SetFile} @{"SETPATH " link RX_CMD_SetPath} @{"UNMARK " link RX_CMD_Unmark} @{"VERSION " link RX_CMD_Version} @{"YEAR " link RX_CMD_Year} @endnode @node RX_CMD_Activate "ARexx command: ACTIVATE" @{b}ARexx command:@{ub} ACTIVATE @{b}Arguments@{ub} none @{b}Description@{ub} The ACTIVATE command will undo the effect of a @{"DEACTIVATE" link RX_CMD_Deactivate} command. If GetPayed was iconified when the ACTIVATE command is received it will uniconify itself, alas open its graphical user interface again. @{b}Note@{ub} This command works on GetPayed as a whole. That is, all projects will be uniconified nomatter which project receives the command. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_ACtivateWindow "ARexx command: ACTIVATEWINDOW" @{b}ARexx command:@{ub} ACTIVATEWINDOW @{b}Arguments@{ub} none @{b}Description@{ub} By sending this command to a project you will activate its window. The effect of this equals pressing in the window with the mouse to select it. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_Clear "ARexx command: CLEAR" @{b}ARexx command:@{ub} CLEAR @{b}Arguments@{ub} MONTH/S,FORCE/S @{b}Description@{ub} Using this command all workdata in a project or a month of the project can be erased. If you do not specify the MONTH keyword this command will work on all months of the project, effectively clearing all workdata. MONTH Signals that only the workdata entires of the current month is to be deleted. FORCE Forces the deletion through. If not FORCE is given the user will be asked for permission to delete the workdata entries. @{b}Note@{ub} This command will neither erase the payment rules nor the payment report. @{b}Returnvalue@{ub} RC = 5 if the user aborted deletion. @endnode @node RX_CMD_Close "ARexx command: CLOSE" @{b}ARexx command:@{ub} CLOSE @{b}Arguments@{ub} FORCE/S @{b}Description@{ub} This command closes a project. The CLOSE command equals selecting the window close button with the mouse. FORCE This argument forces the closing of the project. When given the project will be closed without further notice - even though the has not been saved! If FORCE is not set the user will be asked permission to close the project. Use this argument sparingly as the user may loose his data. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_Deactivate "ARexx command: DEACTIVATE" @{b}ARexx command:@{ub} DEACTIVATE @{b}Arguments@{ub} none @{b}Description@{ub} This command will put GetPayed into iconified state. When iconified GetPayed closes its graphic user interface and puts an icon on the Workbench screen. To uniconify GetPayed either double click the icon on the workbench screen or send an @{"ACTIVATE" link RX_CMD_Activate} command to a GetPayed project. @{b}Note@{ub} This command works globally on GetPayed. When this command is received all projects are iconified regardless of which project received the command. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_Erase "ARexx command: ERASE" @{b}ARexx command:@{ub} ERASE @{b}Arguments@{ub} MONTH/N,ALL/S,FORCE/S @{b}Description@{ub} This command erases marked workdata entries from a month in a project. If the ALL argument is set this command will erase the marked workdata entries from all months in the project. MONTH The number of a month in which to delete marked workdata entries. The month number is a number between 1 and 12, with 1=January. ALL Delete marked workdata in all months of the project. FORCE If set the marked workdata will be deleted without further notice. If not given the user will be asked to confirm the action. If noeither MONTH nor ALL is given this command will only delete marked workdata entries in the current month. @{b}Note@{ub} You can only set either MONTH or ALL, but not both. @{b}Returnvalue@{ub} RC = 5 if the user canceled the erase. RC = 10 if the month number was out of range 1 to 12 (both included). @endnode @node RX_CMD_LockGUI "ARexx command: LOCKGUI" @{b}ARexx command:@{ub} LOCKGUI @{b}Arguments@{ub} LOCAL/S @{b}Description@{ub} This command locks the graphic user interface (GUI) of GetPayed. It can be used to avoid user interferrence while an ARexx script is working with the project. A locked GUI can be unlocked with the @{"UNLOCKGUI" link RX_CMD_UnlockGUI} command. LOCAL If this argument is given only the GUI of the project receiving the command will be locked. @{b}Note@{ub} As long as there are locked projects GetPayed cannot quit! The LOCKGUI/@{"UNLOCKGUI" link RX_CMD_UnlockGUI} commands are not recursive. Therefore a single UNLOCKGUI command will unlock the GUI nomatter how many times you may have sent a LOCKGUI command. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_MoveWindow "ARexx command: MOVEWINDOW" @{b}ARexx command:@{ub} MOVEWINDOW @{b}Arguments@{ub} LEFTEDGE/N,TOPEDGE/N @{b}Description@{ub} With this command you can move the main window of a project to the specified screen position. LEFTEDGE This is the screen coordinate of the left edge of the project window. Omit this argument or set it to -1 to avoid horizontal movement. TOPEDGE This is the screen coordinate of the right edge of the project window. Omit this argument or set it to -1 to avoid vertical movement. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_ChangeWindow "ARexx command: CHANGEWINDOW" @{b}ARexx command:@{ub} CHANGEWINDOW @{b}Arguments@{ub} LEFTEDGE/N,TOPEDGE/N,WIDTH/N,HEIGHT/N @{b}Description@{ub} Using this command you can both move and resize the main window of a GetPayed project. This command has the same functionality as calling both @{"MOVEWINDOW" link RX_CMD_MoveWindow} and @{"SIZEWINDOW" link RX_CMD_SizeWindow} in turn. Kommandoen svarer til at udføre både @{"MOVEWINDOW" link RX_CMD_MoveWindow} og @{"SIZEWINDOW" link RX_CMD_SizeWindow} kommandoerne efter hinanden. LEFTEDGE This is the screen coordinate of the left edge of the project window. Omit this argument or set it to -1 to avoid horizontal movement. TOPEDGE This is the screen coordinate of the right edge of the project window. Omit this argument or set it to -1 to avoid vertical movement. WIDTH This is the new width of the window. Omit this argument or set it to -1 to avoid horizontal resize of the window. HEIGHT This is the new height of the window. Omit this argument or set it to -1 to avoid vertical resize of the window. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_New "ARexx command: NEW" @{b}ARexx command:@{ub} NEW @{b}Arguments@{ub} PORTNAME/K @{b}Description@{ub} This command opens a new GetPayed project. PORTNAME This parameter is used to specify a name for the ARexx port in the project. If no PORTNAME is given or a port with the specified name already exists GetPayed will generate a portname. @{b}Note@{ub} When this command return you cannot be sure that the project has actually been created. You will have to wait for the project to open its ARexx port. This can be done with the DOS command WaitForPort: ... /* Create a new project with the ARexx port name "NEWPROJECT" */ 'NEW PORTNAME="NEWPROJECT"' /* Get the actual name of the ARexx port */ prjName = RESULT /* Wait for the project to be opened */ if ~Show( 'p', prjName ) then do Address COMMAND "WaitForPort" prjName end /* Make sure WaitForPort didn't just time out */ if ~Show( 'p', prjName ) then do Say "Project couldn't open :-(" end /* You now have access to the project ARexx port */ ... Also note that this command may well return an error code 0 (no error) even though the project couldn't be created. This is due to the interval workings of GetPayed: Project creation is enqueued as "create project" requests. So the project is actually not yet created when the ARexx command returns. This problem has also been overcome in the above example ARexx script. @{b}Returnvalue@{ub} RESULT has the actual name of the ARexx port for the project. RC = 10 if GetPayed couldn't initiate project creation. @endnode @node RX_CMD_Open "ARexx command: OPEN" @{b}ARexx command:@{ub} OPEN @{b}Arguments@{ub} FILENAME/K,FORCE/S @{b}Description@{ub} This command loads a project file into a project. Any already present workdata in the project will be deleted before the new data is read from file. FILENAME The filename of the project file to load. If no filename is given GetPayed will open a filerequester and let the user pick a file from there. FORCE With this argument you can force the load through. When specified the user will not be asked for a confirmation if the current project contents has not been saved. @{b}Returnvalue@{ub} RC = 5 if the user cancels the file- or confirmation requester. RC = 10 if GetPayed couldn't open the project file. This error will also be returned if the path part or file part of a filename given with the FILENAME argument is more than 107 characters long @endnode @node RX_CMD_Quit "ARexx command: QUIT" @{b}ARexx command:@{ub} QUIT @{b}Arguments@{ub} FORCE/S @{b}Description@{ub} This ARexx command informs GetPayed to terminate. All projects will be closed and GetPayed will terminate. The user will be asked to confirm the closing of all projects which has not been saved. FORCE Force the termination. When specified the user will not be asked for permission before closing any unsaved projects. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_Request "ARexx command: REQUEST" @{b}ARexx command:@{ub} REQUEST @{b}Arguments@{ub} TITLE/K,PROMPT/K/A,GADS/K @{b}Description@{ub} With this command you can prompt the user through a requester. Until the user reacts to the requester GetPayed will be locked, and thus not react to any input, be it from the GUI or from ARexx. This command will not return until the user has responded to the requester TITLE The titel to be showm in the requester window. PROMPT The requester body text. GADS The gadget titles for the requester. The format of the gadget titles is the same as that for ReqTools requesters. That is, every gadget title is sepparated by a vertical bar ('|'). If a letter in the gadget title is preceeded by an underscore that letter will be used as a keyboard shortcut for the gadget. @{b}Example@{ub} Let's make a requester with three gadgets named "OK", "Wait" and "Cancel". The body text should be "What do I do?" and the title of the window should be "Wake up!" To show the requester the following ARex command should be sent to a GetPayed project: 'REQUEST TITLE="Wake up!" PROMPT="What do I do?" GADS="_OK|_Wait|_Cancel"' Ofcourse the command should be on one line - that was not possible here due to the width of the line. In this example 'O', 'W' and 'C' will be used as keyboard shortcuts for the three gadgets because to the underscores in the GADS argument. @{b}Returnvalue@{ub} RESULT returns the number of the gadget chosen by the user. Numbering is, from left to right, 1, 2, 3, ..., 0. RC = 10 if the requester could not be opened. @endnode @node RX_CMD_RequestFile "ARexx command: REQUESTFILE" @{b}ARexx command:@{ub} REQUESTFILE @{b}Arguments@{ub} TITLE/K,PATH/K,FILE/K @{b}Description@{ub} This command opens up a file requester. TITLE The window title of the requester. PATH The default path for the filerequester. FILE The default filename for the filerequester. @{b}Returnvalue@{ub} RESULT the complete path and filename of the selected file. RC = 5 if the user canceled the requester, or did not chose a file. RC = 10 if GetPayed couldn't return the path and filename of the chosen file. This will only occur in low memory situations. @endnode @node RX_CMD_Save "ARexx command: SAVE" @{b}ARexx command:@{ub} SAVE @{b}Arguments@{ub} none @{b}Description@{ub} With this command you can save a project to a file. If the project already has a filename it will be saved using that name. Otherwise a filerequester will open prompting the user for a filename. If a file with the filename entered in the filerequester already exists the user will be asked if the existing file should be overwritten. @{b}Returnvalue@{ub} RC = 5 if the user cancel the filerequester RC = 10 if the project could not be saved for some reason. @endnode @node RX_CMD_SaveAs "ARexx command: SAVEAS" @{b}ARexx command:@{ub} SAVEAS @{b}Arguments@{ub} NAME/K @{b}Description@{ub} using this command a project can be written to a file using a new filename. If no filename is given a filerequester will be opened to ask the user for a filename. The user will always be asked for confirmation before any existing files are overwritten. NAME The path and filename with which to save the project. @{b}Returnvalue@{ub} RC = 5 if the user canceled the filerequester. RC = 10 if GetPayed couldn't save the file for som reason. This error will also be returned if the given path or filename part of the NAME argument is longer than 107 characters. @endnode @node RX_CMD_SizeWindow "ARexx command: SIZEWINDOW" @{b}ARexx command:@{ub} SIZEWINDOW @{b}Arguments@{ub} WIDTH/N,HEIGHT/N @{b}Description@{ub} This command lets you change the size of a project's main window. WIDTH This is the new width of the window. Omit this argument or set it to -1 to avoid horizontal resize of the window. HEIGHT This is the new height of the window. Omit this argument or set it to -1 to avoid vertical resize of the window. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_UnlockGUI "ARexx command: UNLOCKGUI" @{b}ARexx command:@{ub} UNLOCKGUI @{b}Arguments@{ub} LOCAL/S @{b}Description@{ub} This command unlocks the graphical user interface of GetPayed. It thus cancels the effect of a @{"LOCKGUI" link RX_CMD_LockGUI} command. LOCAL If this argument is set only the project which received the command will have its GUI unlocked. @{b}Note@{ub} The LOCKGUI/@{"UNLOCKGUI" link RX_CMD_UnlockGUI} commands are not recursive. Therefore a single UNLOCKGUI command will unlock the GUI nomatter how many times you may have sent a LOCKGUI command. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_UnzoomWindow "ARexx command: UNZOOMWINDOW" @{b}ARexx command:@{ub} UNZOOMWINDOW @{b}Arguments@{ub} none @{b}Description@{ub} This command resets a project's main window to its original position and size (as opposed to @{"ZOOMWINDOW" link RX_CMD_ZoomWindow}). The effect os this command equals pressing the window zoom button with the mouse. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_WindowToBack "ARexx command: WINDOWTOBACK" @{b}ARexx command:@{ub} WINDOWTOBACK @{b}Arguments@{ub} none @{b}Description@{ub} This command moves a project's window behind all other windows on screen. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_WindowToFront "ARexx command: WINDOWTOFRONT" @{b}ARexx command:@{ub} WINDOWTOFRONT @{b}Arguments@{ub} none @{b}Description@{ub} With this command you can move a project's window in front of all other windows on the screen. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_ZoomWindow "ARexx command: ZOOMWINDOW" @{b}ARexx command:@{ub} ZOOMWINDOW @{b}Arguments@{ub} none @{b}Description@{ub} Using this command you can put a window into its zoomed size and position. This command has the same effect as pressing the window zoom button. To unzoom the window at a later point use the @{"UNZOOMWINDOW" link RX_CMD_UnzoomWindow} command. @{b}Returnvalue@{ub} none @endnode @node RX_CMD_AddDay "ARexx command: ADDDAY" @{b}ARexx command:@{ub} ADDDAY @{b}Arguments@{ub} QUIET/S,MONTH/N/K,DATE/N/K/A,START/K/A,STOP/K/A,PAUSE/K/A,COMMENT/F @{b}Description@{ub} This command enables you to add workdata entries to a project from ARexx. QUIET Normally a requester will open with an error message if the given workdata are invalid. By giving this keyword the requester will be suppresed, and instead a more informative error code is returned in the RC variable. MONTH The number of the month into which the workdata entry should be placed. MONTH=1 will place the entry in January. If no month is specified the entry will be inserted in the current month of the project. DATE This is the day of the month on which the work was done. START This is the time of the day when the work was begun. STOP This is the time of day when the work was ended. PAUSE The total duration of all breaks held during the work period. COMMENT Any comment you may wish to add for the entry. @{b}Note@{ub} START, STOP and PAUSE must be set in "HH:MM" format. That is, first the hour count (in 24 hour format), then a colon and the minute count at the end. @{b}Returnvalue@{ub} @{i}Non-QUIET: @{ui} RC = 10 if the workdata was invalid. @{i}QUIET:@{ui} RC = 11 if the date is invalid. 12 if the starttime was invalid. 13 if the stoptime was invalid. 14 if the pause duration was invalid. 15 if the duration of pause was longer than the timeinterval between the start and stop time. @endnode @node RX_CMD_CalcFrom "ARexx command: CALCFROM" @{b}ARexx command:@{ub} CALCFROM @{b}Arguments@{ub} FROM/N @{b}Description@{ub} With this command you set the startpoint for payroll calculations. If you do not specify a new startpoint this command will return the current start point without doing any modifications. The unit of the startpoint is obtained with the @{"CALCUNIT" link RX_CMD_CalcUnit} command, and is currently either week- or month numbers. FROM The startpoint for payroll calculations. @{b}Returnvalue@{ub} RESULT holds the startpoint for payroll calculations. @endnode @node RX_CMD_CalcTo "ARexx command: CALCTO" @{b}ARexx command:@{ub} CALCTO @{b}Arguments@{ub} TO/N @{b}Description@{ub} This command enables you to change the endpoint for payroll calculations. If no endpoint is specified this command will return the current endpoint without modifying it. The unit of the endpoint is obtained using the @{"CALCUNIT" link RX_CMD_CalcUNit} command, and can be either week- or month numbers. TO The endpoint for payroll calculations. @{b}Returnvalue@{ub} RESULT holds the endpoint for payroll calculations. @endnode @node RX_CMD_CalcUnit "ARexx command: CALCUNIT" @{b}ARexx command:@{ub} CALCUNIT @{b}Arguments@{ub} WEEKS/S,MONTHS/S @{b}Description@{ub} Using this command you can set or obtain the time unit used for specifying the payroll calculation range. If you do not specify a time unit then this command will only return the currently selected time unit. WEEKS Start- and endpoints are specified using week numbers. Week number 0 corresponds to any days of week 52 of previous year which are positioned in the year the project represents. Week number 1 corresponds to week 1 of the year. ... Week number 52 corresponds to week 52 of the year. Week number 53 corresponds to any days of next year's week 1 which are positioned in the year the project represents. MONTHS Start- and endpoints are given using month numbers. Month number 1 corresponds to January. ... Month number 12 corresponds to December. @{b}Note@{ub} Only one of the keywords WEEKS and MONTHS may be specified at a time. @{b}Returnvalue@{ub} RESULT holds the time unit for payroll calculation start- end endpoints. 0 = Unit is weeks. 1 = Unit is months. @endnode @node RX_CMD_CurDay "ARexx command: CURDAY" @{b}ARexx command:@{ub} CURDAY @{b}Arguments@{ub} MONTH/N/K,DATE/N/K,ENTRY/N/K @{b}Description@{ub} Using this command you can control which workdata entry in a month will be the active entry. The active entry is the entry which is selected in the graphical userinterface. If neither a DATE nor an ENTRY argument is given this command will return the index number of the currently active entry in the specified month. MONTH The month to select the active entry in. Each month can have its own active entry. If no month is specifyed this command will work on the currently active month. Month number 1 corresponds to January. DATE The daynumber of the month which should be made the active entry. Daynumber 1 corresponds to the first day of the month. ENTRY Index number into the list of workdata entries for the specified month of the entry to make the active one. If the index number is greater than the number of entries in the month the last entry in the month will be made the active one. An entry number of 0 will deselect any active entry. @{b}Note@{ub} DATE and ENTRY cannot be used at the same time. If, on the other hand, none of them is given the active entry will not change. @{b}Returnvalue@{ub} RESULT holds the index number of the currently active entry in the specified month. RC = 5 if the given daynumber does not exist in the month. 10 if the given month number was out of range 1-12. @endnode @node RX_CMD_Days "ARexx command: DAYS" @{b}ARexx command:@{ub} DAYS @{b}Arguments@{ub} MONTH/N/K @{b}Description@{ub} This command returns the number of workdata entries currently existing in the specified month. MONTH The month for which to obtain number of entries. If not specified the number of entries for the current month will be returned. @{b}Returnvalue@{ub} RESULT holds the number of workdata entries in the month. RC = 10 if the given month number was out of range 1-12. @endnode @node RX_CMD_DelDay "ARexx command: DELDAY" @{b}ARexx command:@{ub} DELDAY @{b}Arguments@{ub} MONTH/N/K,DATE/N/K,ENTRY/N/K,FORCE/S @{b}Description@{ub} Using this command you can delete workdara entries from a project. MONTH The month from which to delete workdata entries. If not specified you will delete entries from the current month. Monthnumber 1 corresponds to January. DATE The daynumber of the enry to delete. ENTRY An index into the list workdata entries of the entry to delete. FORCE When specified the user will not be asked to confirm the delete. @{b}Note@{ub} If neither DATE nor ENTRY is given the currently active entry of the month will be deleted. @{b}Returnvalue@{ub} RC = 5 if user canceled the delete. = 10 if the month number was out of range 1-12. @endnode @node RX_CMD_GetDay "ARexx command: GETDAY" @{b}ARexx command:@{ub} GETDAY @{b}Arguments@{ub} MONTH/N/K,DATE/N/K,ENTRY/N/K,STEM/K @{b}Description@{ub} With this command you can transfer a workdata entry from a project into an ARexx script. The entry can be transfered to the RESULT variable, but can also be transfered to a variable of your own choice using the STEM argument. The workdata is placed into the variable using so called compound variables. These are named using the base variable name (also called the stem variable) followed by the compound variable name. The compound names accessible after a call to GETDAY is .DATE The day of month the work was done. .START Time of day when the work was begun. .STOP Time of day when the work was finished. .PAUSE Total duration of break sduring the work time. .COMMENT A comment for the workdata entry. The day of month can thus be obtained by using the terminology RESULT.DATE (assuming that the stem variable is RESULT). If the stem variable was chosen to be DATA then DATA.DATE would access the day of month. MONTH The month of the project from which to read an entry. If no month is specified the current month will be used. Month number 1 corresponds to January. DATE Day of month for the entry to obtain. DATE=1 corresponds to the first day of the month. ENTRY Index number of the entry in the month to be obtained. The first entry has index number 1. STEM The name of the ARexx variable to return the workdate entry in. If no STEM is specified the entry will be transfered in the RESULT variable. See above for the compound names and their contents. @{b}Example@{ub} Lets write a small script that obtains the first workdata entry in January and writes it to the screen: /* GetPayed GETDAY command test */ Address GETPAYED.1 /* Access the 1st GetPayed project */ Options RESULTS /* We want to get result values from GetPayed */ 'GETDAY MONTH=1 ENTRY=1' /* Obtain first entry in january */ if RC=0 then do /* Only write to screen if all went OK */ Say "Start time :" RESULT.START /* Write workdata */ Say "Stop time :" RESULT.STOP Say "Pause duration :" RESULT.PAUSE Say "Comment :" RESULT.COMMENT end else if RC=5 then do /* No entries in January */ Say "No entries in January!" end else do /* Month number is OK (1=January) - must be out of memory */ Say "Not enough memory to transfer data!" end @{b}Note@{ub} The ENTRY and DATE arguments are mutually exclusive. Either you access the workdata entry by index number or by day number. If neither ENTRY nor DATE is specified this command works on the active entry of the specified month (if any). @{b}Returnvalue@{ub} RESULT holds the index number of the returned workdata entry. RC = 5 if the specified day of month did not exist, the index number was greater than the number of entries in the month, or if neither an index number nor a day of month was specified and there were no active entry in the month. = 10 if the specified month was out of range 1-12, or GetPayed couldn't allocate the memory needed to return the workdata. @endnode @node RX_CMD_IoExtension "ARexx command: IOEXTENSION" @{b}ARexx command:@{ub} IOEXTENSION @{b}Arguments@{ub} PROJECT/S,REPORT/S,NAME @{b}Description@{ub} With this command you choose the fileformat used for saving the project and its payment reports with. If no IO extension name is specified this command will only return the name of the IO extension currently selected. PROJECT Specify this keyword when you want to change the fileformat used for saving the project. REPORT Specify this keyword when you want to change the fileformat used for saving payment reports. NAME The basename of the IO extension to be used. The basename is merely the filename of the extension library without its filename extension (no ".io"). If you for instance wish to use the IO extension "getpayed.io" you set NAME to "getpayed". Basenames are not case sensitive. @{b}Note@{ub} It is only possible to set either the project fileformat or the report fileformat. You cannot set both in one call. @{b}Returnvalue@{ub} RESULT holds the basename of the current IO extension. RC = 10 if the specified IO extension was not found, or the IO extension did not support saving of files. In both cases the specified IO extension was not selected for use. @endnode @node RX_CMD_Mark "ARexx command: MARK" @{b}ARexx command:@{ub} MARK @{b}Arguments@{ub} MONTH/N,FROM/N,TO/N,DATES/S @{b}Description@{ub} using this command you can mark a range of workdata entries in a month. All entries bewteen the FROM and TO arguments will be marked. MONTH The month in which to mark workdata entries. I fno month is specified entries will be marked in the current month. FROM The first entry to be marked. TO The last entry to be marked. DATES With this keyword you specify that the FROM and TO arguments contain month day numbers. If this keyword is not given then the FROM and TO arguments will be interpreted as index numbers into the list of workdata entries. @{b}Note@{ub} If DATES is given the FROM and TO arguments will be treated as month day numbers. Even though the specified dates do not exist in the list of workdata entries all entries with dates between those specified will be marked. Also note that this command will not unmark any entries already marked. It is therefore possible to do more advanced selection by sending more than one MARK command. @{b}Returnvalue@{ub} RC = 5 if there were no entries between the FROM and TO arguments when these are specified as day numbers (via the DATES keyword). = 10 if the specified month was out of range 1-12. = 11 if the FROM argument was greater than the TO argument. @endnode @node RX_CMD_Month "ARexx command: MONTH" @{b}ARexx command:@{ub} MONTH @{b}Arguments@{ub} MONTH/N @{b}Description@{ub} This command is used for selecting the current month. The functionality of this command equals selecting a month page in the project using the mouse. If no month number is specified this command will only return the number of the current month. MONTH The month to make the current month of the project. @{b}Returnvalue@{ub} RESULT holds the number of the currently active month, with January represented by the value 1. RC = 10 if the specified month was out of range 1-12. @endnode @node RX_CMD_OpenPrefs "ARexx command: OPENPREFS" @{b}ARexx command:@{ub} OPENPREFS @{b}Arguments@{ub} FILENAME/K,FORCE/S @{b}Description@{ub} This command loads a new set of preferences into a project. If the old preferences has not been saved the user will be asked to confirm the operation. FILENAME The full path and filename of the preferences file to load. If not specified a filerequester will open prompting the user for a preferences file. FORCE If this keyword is given the user will not be asked for a confirmation if the current preferences has not been saved. @{b}Returnvalue@{ub} RC = 5 if user canceled the confirmation- or filerequester. 10 if the preferences fil could not be loaded. This error is also returned if the filename or path is longer than 107 characters. @endnode @node RX_CMD_OpenReport "ARexx command: OPENREPORT" @{b}ARexx command:@{ub} OPENREPORT @{b}Arguments@{ub} FILENAME/K,FORCE/S @{b}Description@{ub} using this command you can read a payment report into the project. If the current payment report has not been saved the user will be asked to confirm the action. FILENAME The full file- and pathname of the payment report to load. If not specified a filerequester will open asking the user for a report file to open. FORCE When specified the user will not be asked to confirm the loading even though the current report has not ben saved. @{b}Returnvalue@{ub} RC = 5 if the user canceled the file- or confirmation requester. 10 if the report file oculd not be loaded. This error is also returned if the filename or path is longer than 107 characters. @endnode @node RX_CMD_Payment "ARexx command: PAYMENT" @{b}ARexx command:@{ub} PAYMENT @{b}Arguments@{ub} none @{b}Description@{ub} This command is used to obtain the sum of the current payment report. The result from this command can be used immidiately for calculations in ARexx. @{b}Returnvalue@{ub} RESULT holds the sum of the current payment report. RC = 10 if GetPayed couldn't return the sum. This will only happen in extreme low memory situations. @endnode @node RX_CMD_Report "ARexx command: REPORT" @{b}ARexx command:@{ub} REPORT @{b}Arguments@{ub} NEW/S,QUIET/S @{b}Description@{ub} Use this command to issue a payroll calculation. The start and stop points for the calculation are the points set using the CALCFROM and CALCTO commands, or the limits set by the user in the project GUI (depending on which was done most recently). NEW Give this keyword if you want the result of this payroll calculation to effectively replace the current payment report. QUIET Use this keyword to suppress any error reports from GetPayed. @{b}Returnvalue@{ub} RC = 10 if an error occured during the payroll calculation. @endnode @node RX_CMD_SavePrefs "ARexx command: SAVEPREFS" @{b}ARexx command:@{ub} SAVEPREFS @{b}Arguments@{ub} DEFAULT/S @{b}Description@{ub} With this command you can save the current preferences to a file. If the preferences already has a filename they will be saved using that. If not, a filerequester will open asking the user for a filename. DEFAULT If this keyword is given then the preferences will be saved as default preferences for GetPayed. What this mean is, that the next time GetPayed is started, and each new project created, will use these settings. @{b}Returnvalue@{ub} RC = 5 if the user canceled the save. = 10 if the preferences couldn't be saved for some reason. @endnode @node RX_CMD_SavePrefsAs "ARexx command: SAVEPREFSAS" @{b}ARexx command:@{ub} SAVEPREFSAS @{b}Arguments@{ub} NAME/K @{b}Description@{ub} Using this command it is possible to save the preferences to a file. If no filename is specified the user will be asked for a filename through a filerequester. If a file exists with the specified file the user will be asked to confirm overwriting of the existing file. NAME The file and pathname to use for writing the preferences. @{b}Returnvalue@{ub} RC = 5 if the user canceled the save. = 10 if the preferences couldn't be saved. This error is also returned if the file or path specified with NAME was more than 107 characters long. @endnode @node RX_CMD_SaveReport "ARexx command: SAVEREPORT" @{b}ARexx command:@{ub} SAVEREPORT @{b}Arguments@{ub} none @{b}Description@{ub} THis command will write the payment report of a project to a file. If the payment report already has a filename it will be saved using that. Otherwise a filerequester will open asking the user for a filename. @{b}Returnvalue@{ub} RC = 5 if the user canceled the save. = 10 if the payment report could not be saved for some reason. @endnode @node RX_CMD_SaveReportAs "ARexx command: SAVEREPORTAS" @{b}ARexx command:@{ub} SAVEREPORTAS @{b}Arguments@{ub} NAME/K @{b}Description@{ub} This command will write a payment report to a file. If no name is specified the user will be prompted for one through a filerequester. If a file with the specified name already exist the user will be asked to confirm overwriting of the existing file. NAME The path and filename to save the payment report with. @{b}Returnvalue@{ub} RC = 5 if the user calceled the save. = 10 if the payment report for some reason couldn't be saved. This error is also returned if the file or path specified with NAME was more than 107 characters long. @endnode @node RX_CMD_Unmark "ARexx command: UNMARK" @{b}ARexx command:@{ub} UNMARK @{b}Arguments@{ub} MONTH/N @{b}Description@{ub} This command will unmark all marked workdata entries in a project. If you specify a month number then only the entries in this month will be unmarked. MONTH Month number of the month to unmark entries in. Month numbers must be in range 1 (January) to 12 (December). @{b}Returnvalue@{ub} RC = 10 if the month number was out of range 1-12. @endnode @node RX_CMD_Version "ARexx command: VERSION" @{b}ARexx command:@{ub} VERSION @{b}Arguments@{ub} none @{b}Description@{ub} This command returns the version of the GetPayed program. At this time you will propably not find any real use for this command. But in future version of GetPayed more ARexx commands may well be defined. You can then use this version number to see if the ARexx commands you intend to use are actually supported by the GetPayed version running. @{b}Returnvalue@{ub} RESULT holds the GetPayed version, in the format ".". @endnode @node RX_CMD_Year "ARexx command: YEAR" @{b}ARexx command:@{ub} YEAR @{b}Arguments@{ub} YEAR/N @{b}Description@{ub} Using this command you can obtain or modify the year the project represents. If you do not specify a year number this command will do nothing more than return the year that the project is currently set to represent. YEAR The year you want the project to represent. THis must be a full four digit year, like "1998". Do not use two digit year numbers, like "97", as this will be interpreted as the year "0097"! @{b}Returnvalue@{ub} RESULT holds the year the project currently represents. If you are changing the year with this command then RESULT will return the same value as you gave as argument. RC = 10 if GetPayed couldn't change the year the project represents, or if the current year could not be returned. Both cases only occur in extreme low memory situations. @endnode @node RX_CMD_GetPath "ARexx command: GETPATH" @{b}ARexx command:@{ub} GETPATH @{b}Arguments@{ub} PROJECT/S,REPORT/S,RULES/S,SETTINGS/S @{b}Description@{ub} Using this command you can obtain the current path from a project. The paths are those accessed on last read or write of the specified file type. PROJECT If specified you will get the path where the current project was loaded from, or written to. REPORT If specified you will get the path where the current payment report was loaded from, or written to. RULES If specified you will get the path where the current payment rules were loaded from, or written to. SETTINGS If specified you will get the path where the current project settings was loaded from, or written to. @{b}Note@{ub} Only one path string can be returned at a time! @{b}Returnvalue@{ub} RESULT holds the path string for the specified file type. RC = 10 if GetPayed couldn't return the path string. This will only happen in low memory situations. @endnode @node RX_CMD_GetFile "ARexx command: GETFILE" @{b}ARexx command:@{ub} GETFILE @{b}Arguments@{ub} PROJECT/S,REPORT/S,RULES/S,SETTINGS/S @{b}Description@{ub} Using this command you can obtain the current filenames from a project. The filenames are those used on last read or write of the specified file type. PROJECT If specified you will get the filename of the project. REPORT If specified you will get the filename of the current payment report. RULES If specified you will get the filename of the current payment rules. SETTINGS If specified you will get the filename where the project's settings. This will be an empty string if project is using the default settings! @{b}Note@{ub} Only one filename string can be returned at a time! @{b}Returnvalue@{ub} RESULT holds the filename string for the specified file type. RC = 10 if GetPayed couldn't return the filename string. This will only happen in low memory situations. @endnode @node RX_CMD_SetPath "ARexx command: SETPATH" @{b}ARexx command:@{ub} SETPATH @{b}Arguments@{ub} PROJECT/K,REPORT/K,RULES/K,SETTINGS/K @{b}Description@{ub} Using this command you can set the path of various files used in the project. The path will be used on next save of the files, or will be the default path next time a filerequester opens. PROJECT If specified you will set the path of the project's file. REPORT If specified you will set the path of the payment report. RULES If specified you will set the path of the payment rules. SETTINGS If specified you will set the path of the project settings. @{b}Note@{ub} Think before you use this command. You can cause great confusion to the user, and perhaps damage his files! @{b}Returnvalue@{ub} none RC = 10 if at least one of the strings where longer than 107 characters long. @endnode @node RX_CMD_SetFile "ARexx command: SETFILE" @{b}ARexx command:@{ub} SETFILE @{b}Arguments@{ub} PROJECT/K,REPORT/K,RULES/K,SETTINGS/K @{b}Description@{ub} Using this command you can set the filename of various files used in the project. The filename will be used on next save of the files, or will be the default filename next time a filerequester opens. PROJECT If specified you will set the filename of the project's file. REPORT If specified you will set the filename of the payment report. RULES If specified you will set the filename of the payment rules. SETTINGS If specified you will set the filename of the project settings. @{b}Note@{ub} Think before you use this command. You can cause great confusion to the user, and perhaps damage his files! @{b}Returnvalue@{ub} none RC = 10 if at least one of the strings where longer than 107 characters long. @endnode @node RX_CMD_ "ARexx command: " @{b}ARexx command:@{ub} @{b}Arguments@{ub} @{b}Description@{ub} @{b}Returnvalue@{ub} @endnode