The Accounts Receivable system invokes the generation of Progress Claims (that include a full progress summary) and Sundry Invoices.
We remind users that we avoid the use of the terms Debtors and Creditors and use Accounts Receivable and Accounts Payable. As a result of the one-sided ledger, all Accounts Received are treated as '-' values while Accounts Payable are considered '+' values.
The Accounts Receivable system is similar in application to the Accounts Payable. Before a "C" (credit) order can be raised, the customer must be registered by code in "15. Customer Master Maintenance" i.e.the same procedure as a supplier in Accounts Payable.
This would have normally been done to raise a project and is separate from any registration in Accounts Payable. The system tracks costs and revenues, storing the commitment and received values (as opposed invoiced value) in a special type of order called a "C" order (Accounts Receivable or Credit Order).
A project will have an income "C" order located in Allocation 1000 Project Income which is updated by progress claim processing.
The "C" order is raised usually for the total value of the project, i.e. the full contract amount. This "C" order is always raised in Allocation 1000 Project Income, and appears as a -ve amount in "Committed". The cumulative value of cash receipts will appear in the approved column as -ve.
However, for development of a block of units for end user sales, there would be a "C" order for each sale (in Allocation 1000) generated by the Credit Order or Sundry Invoice Entry procedure.
All income in Allocation 1000 is regarded as Project Income, while "C" orders allocated to other Allocations are treated as reducing Project costs and do not affect Project income.
This approach enables cost recoveries, i.e. sale of demolition material to be directly credited to the cost allocation to reflect the net cost on an allocation summary.
In overhead accounts, any allocation may be utilised to reflect both Income and Expense transactions.
The Accounts Receivable system is an open item approach with each transaction (Invoice and Receipt) given a folio number.
Note: Charges for Val 1 (Transport) Val 2 (Sales Tax/VAT) Val 3 (Deposits) are debited to the project and credited to the overhead project when the invoice is raised.
Because Project Management may take many forms, each contract and its relevant client documents need to be closely considered. If in doubt, contact your Muli Representative.
________________________________________________________________________
DD/MMM/YY HH:MM AMENU Accounts Receivable VN/SERIAL USER mulixx
1. Progress Claim Lump Sum
2. Progress Claim Cost Based
3. Sundry Invoice Creation
4. Sundry Invoice Maint/Print
5. Credit Order Creation
6. Credit Order Amendment
7. Credit Amendment Print
8. Cash Receipts Entry
9. Accounts Receivable Report
10. Allocations Receivable Report
11. Cash Receipts Report
12. A/R Sundries Sub-Menu
13. A/R Management Report
14. Accounts Receivable Statements
15. Customer Master Maintenance
16. Customer Master Report
Enter Selection Number __
________________________________________________________________________
The progress claim procedure allows the development and printing of Progress claims as a worksheet, without updating the Accounts Receivable, allowing the operator to develop a document which may be agreed with the client before committing to Accounts Receivable. (Non commitment is achieved by defaulting over the question "do you wish to update this claim after printing?")
The concept is one of managing the client to ensure that at the end of the project he has not run out of money and variation disputation does not erupt. Thus the claim is a full contractual summary including all Variations as well as traditional claim information.
Prior to a claim being processed, a break up for the original contract value must be entered through 6.03 Claim Data Entry.
___________________________________________________________________________
DD/MMM/YY HH:MM AMENU Lump Sum Progress Claim VN/SERIAL USER mulixx
Project
Address
Customer
Address
Claim Number
Order Number
Order Description
Claim Date
Due Date
Project Number ______
______________________________________________________________________________
This screen confirms the correct project number has been keyed in and allows a specific claim date to be inserted. Default is today's date.
______________________________________________________________________________
DD/MM/YY HH:MM AMENU Claim Data Maintenance VN/SERIAL USER mulixx
PROJECT # 520001 COMMUNITY FACILITY CLAIM # 0003 DATE 21/03/84
CLAIMS ORIG LST MTH LAST WORK TO
DESCRIPTION CONTRACT $ CLAIM ENTRY DATE $
1 FOOTINGS 10,000.00 1,000.00 2,000.00 2,000.00
2 LOCK UP 10,000.00 0.00 0.00 1,000.00
3 COMPLETION 10,000.00 0.00 0.00 0.00
ORIGINAL VAL 30,000.00 1,000.00 2,000.00 3,000.00
ORIGINAL CONTRACT VALUE NOT EQUAL CLAIMS AMOUNT - CR TO CONTINUE
________________________________________________________________________________
The Item description entered in Progress Claim Data. Prior entry in Lump Sum Data Maintenance.
The value entered through the Progress Claim Data Maintenance.
NOTE: When the total value entered in Data Maintenance does not equal the original contract value as entered in the Project Master, then a warning is printed on the screen.
The value entered on the last progress claim used to update accounts receivable.
The value that was entered in the last work session.
The value entered in this work session, i.e. the value wished to be claimed against the original contract value on the right - cannot exceed that value.
____________________________________________________________________________
DD/MMM/YY HH:MM AMENU Lump Sum Progress Claim VN/SERIAL USER mulixx
PROJECT # 520001 COMMUNITY FACILITY CLAIM # 0003 DATE 21/03/84
R & F - POST CONTRACT ADJ BALLPARK SUBMIT APPROVED L/MTH CLM WRK TO DTE
DESCRIPTION
1 R & F MAY 1983 1530.00 1530.00 1530.00
2 R & F JUNE 1238.00 1238.00 1238.00
3 R & F JULY 1102.00 0.00 1102.00
R&F TO COMPLETE ............
RISE & FALL TOTAL 0 1102.00 2768.00 2768.00 3870.00
____________________________________________________________________________
With all variations, both Rise and Fall and Normal, three classes of variation are shown:
However, only the far right hand status is shown on this report. Values shown in this area may only be changed through the Variation controls 2.06.
A value can be claimed in the Work to Date Valuation, although the variation status is Ballpark, submitted or approved.
Allows the operator to make allowance for Rise and Fall to the end of the project as this is a legitimate cost that should be included in any contractual summary of final forecast cost.
The variations are then displayed for entry of current value of Rise and Fall claimed.
Contingency to END allows the entry of a contingency figure for variations to complete the project if this is applicable.
________________________________________________________________________________
DD/MMM/YY HH:MM AMENU Progress Claim Maintenance VN/SERIAL USER mulixx
VARIATION - POST CONT' ADJ BALLPARK SUBMIT APPROVED L/MTH CLM WRK TO DTE
DESCRIPTION
1 ROCK IN FOOTINGS 1530.00 1530.00 0.00
2 UPGRADE GYMNASIUM FLOOR 9832.00 9832.00 0.00
3 CHANGE IN ROOF SPECIFI 2000.00- 2000.00 0.00
4 P.C. ADJ ON QUARRY FIL 2000.00 2000.00 0.00
5 P.C. ADJ ON BRONZE TAP 1500.00 1500.00 0.00
CONTINGENCY TO END 500.00
VARIATIONS TOTAL
CHANGE FIELD# ..
_______________________________________________________________________________
A claim summary is then displayed on the screen to allow operator validation.
________________________________________________________________________________
DD/MMM/YY HH:MM AMENU Progress Claim Maintenance VN/SERIAL USER mulixx
ORIGINAL CONTRACT VALUE 131,111.11 VALUE OF WORK TO DATE 80,642.00
APPROVED VARIATIONS 15,630.00 RETENTION 4,000.00
ADJUSTED CONTRACT VALUE 146,741.11 LESS PREVIOUS CLAIMS 20,710.00
SUBMITTED VARIATIONS 3,958.00- CLAIMS THIS PERIOD 55,932.00
BALLPARK VARIATIONS 540.00- ADJMNT ON PREV PAYMNT 710.00
FINAL FORECAST COST 142,243.11 ----TOTAL NOW DUE---- 56,642.00
________________________________________________________________________________
______________________________________________________________________________
DD/MMM/YY HH:MM AMENU Progress Claim Maintenance VN/SERIAL USER mulixx
UPDATE ACCOUNTS RECEIVABLE (N)
______________________________________________________________________________
Once the Accounts Receivable is upgraded, then no further adjustments may be carried out on this claim.
NOTE:
If the project is lump sum based, then a breakup of the price is agreed with the client to be the basis for progress claims. This is seldom the same as the internal budgeting as margins and over- heads are spread over the trades along with adjustments to accomodate variations and cash flow.
___________________________________________________________________________
DD/MMM/YY HH:MM AMENU Claim Data Maintenance VN/SERIAL USER mulixx
DEL CHG ADD
1. Project Number
2. Reference
3. Description
4. Claim Value
5. Last Month Claim
Project Number _____
___________________________________________________________________________
Entry Procedure for loading the desired Progress Claim breakup into the system.
NOTE: The only system check is that the total of all items entered = original contract value.
The number of the project to be entered.
Prefix must be "C" (for contract) the following number is the line order for printing sequentially.
NOTE: Stepping the number by 5 allows future insertion.
Description that will appear in the progress claim, i.e. Excavation, Demolisher, Concretor. Does not have to relate to the internal system.
The value placed on that component of the works in terms of the Progress Claim.
Value of the last progress claim if a claim has already been processed. Default over if first claim has not been processed.
The cost based progress claim allows the development and printing of a claim based on cost and predicted outcome which is more in tune with the requirement of construction management projects.
While only one cost element (approved and accrued) is available to guide the maintenance of Claimed field in the presentation copy there are four user definable columns that may be utilised.
This process uses the trades summary file from which the project cost report is printed. Like the Cost Report, the operator should ensure the values are current by doing a bulk file update if the final forecast is not current.
This approach allows the claim information to be fully substantiated using the existing accounting inputs and reports.
________________________________________________________________________________
DD/MM/YY HH:MM AMENU COST BASED PROGRESS CLAIM VN/SERIAL USR DATA
Your Company Name
Project xxxxxx XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Order C23456
ALLOC. Description QA Approved+Accrued Previous This Claim %
--------------------------------------------------------------------------------
3600 CONCRETER 385,213.00 254,000.00 385,213.00 .68
4200 BRICKLAYER 103,897.00 24,230.00 103,897.00 .24
4400 STRUCTURAL STEEL 489,522.00 230,000.00 489,552.00 .80
4600 FRAMING TIMBER 63,122.00 5,231.00 63,122.00 .63
4800 ROOFER 6,124.00 0.00 6,123.00 .20
5200 DOORS JAMBS HARDWARE 0.00 0.00 0.00 .0
-------------------------------------------------------------------------------
2,485,231.00
Forward Page Backward Page Retention Print End
Total Retention Net
Value of work Claimed 1,214,389 0.00 1,214,389
Value previously claimed 680,358 680,358
------------------------------------------------
Value this Claim 534,389 534,389
________________________________________________________________________________
Before proceeding with data input, the program requests the field to be used for calculating the % which is, by default, the final forecast cost.
While the printed version may have only one summary line for Preliminaries at data input time a value must be placed against each Work Code.
The forward and backward arrows allow the user to move up or down the screen and change the claimed value against each Work Code. The resultant total is then displayed in the bottom summary.
The operator may change the current retention value by pressing "R".
Once the values claimed are satisfactory the operator presses "P" to proceed to the printing program.
________________________________________________________________________________
DD/MM/YY HH:MM AMENU COST BASED PROGRESS CLAIM VN/SERIAL USR DATA
Your Company Name
There are 4 User allocatable columns on the claim form which
a. Original Budget
1. Column 1 b. Adjusted Budget b. Adjusted Budget
2. Column 2 c. Committed c. Committed
3. Column 3 i. Final Forecast cost e. Approved
4. Column 4 k. Last claim f. Retention
Column 5 This Claim g. Accrual
6. Value to be used for % j. h. Approved+Accrued
i. Provisions
7. Preliminaries Consolidated j. Final forecast
8. Design Consolidated k. Last Claim
9. Marketing Consolidated
10. Land Consolidated
11. Margins Consolidated
Please Enter Selection Number _________
________________________________________________________________________________
After printing the operator is asked if they wish to:
________________________________________________________________________________
DD/MM/YY HH:MM AMENU COMPONENT INSTRUCTION VN/SERIAL USR DATA
Your Company Name
A invoice transaction is then entered into Accounts Receivable and
the Claim Previous data is updated ready for the next claim.
Please Enter Selection Number _________
________________________________________________________________________________
The progress claim always interfaces with allocation 1000 in the project, the Sundry Invoice is used to record all other incomes and may interface with any allocation in any project and overheads (including Alloc. 1000).
From an accounting perspective all postings of Cash Receipts to allocation greater than 1000 are treated as "-" Project Expense, not Project Income thus.
If it costs $15,000 to demolish the building but the demolition goods were sold off for $3,000 then this would be shown as cost code $12,000 expense.
Note: This is not the case in minor works projects.
The transaction will appear in the system as a 'C' (or Credit Order) Accounts Receivable Order.
NOTE:
Posting of the Control Accounts only occurs when the received is reconciled with the original Invoice either:
0136 PROV.A/R.1 Value 1 Usually Transport costs.
0137 PROV.A/R.2 Value 2 Usually Sales Tax
0138 PROV.A/R.3 Value 3 Usually deposits
(or payment discounts)
VALUE 4 Always RetentionsEarly applications had Allowance 0139. This is now redundant as when the system requires the current Retention Value, it is obtained by summarising the ARTRAN file.
Retention on Accounts Receivable is not recognised in General Ledger at point of Project Prepayment figure.
The use of these overhead project accounts may be varied by users, except for retentions, as this field is required for Progress Claim.
____________________________________________________________________
DD/MMM/YY HH:MM AMENU Sundry Invoice VN/SERIAL USER mulixx
1. Customer Code
2. Project Number
3. Folio Number
4. Allocation Number
5. Order Number
6. Invoice Number
7. Invoice Date
8. Due Date
9. Description
10. Invoice Amount
11. Delivery
12. Sales Tax
13. Deposit
14. Retention Amount
15. Text Type
Customer Code _____
____________________________________________________________________
The Control Code in Customer Master file may also enter the "C" order number at this stage, and the system will default the down to and including order details.
Project to be credited.
System Generated Folio No.
Allocation to be credited.
If no order number is entered, then the system will ask if you want to create an order. If you respond by 'Y' or default, then a further sub-section appears to allow the direct creation of the order in the system.
No printed copy of the order is created although an order number is allocated.
Allows a docket book or default sequential number to be inserted. If no number given then the system will default the next available Invoice number.
Date of Invoice default is todays date.
The date money expected to be received. (This utilised within the cash flow system). Will default to 5th day of the month after next.
Short description of what the Invoice is for will appear on Statement and accounts Receivable summary.
Value of Invoice to be credited to the order does not include the values 1-3 which are posted to the Overhead Project Control Accounts. (Retentions are controlled separately).
The format of Text Type to be used for the hard copy. Text would have been previously entered through the "Order Notes Maintenance 3.08". May be defaulted through to take standard format. 21 lines will then appear on the screen for text manipulation. If default value taken, then a blank screen will appear allowing free format input.
This program directly chained from Sundry Invoice Entry to print a previously entered invoice.
Any invoice with text created may be printed up until the system has been cleaned by the system Administrator with Menu 19.
The Muli system requires an Income/Credit Order to exist to allocate Progress Claims, invoices and record payment. Where the project has multiple income sources, such as direct sales of own development units. Each sale has to be individually recorded.
This formal writing of a Credit Order may be bypassed and written as part of Sundry Invoice Entry procedure, for invoices only.
_________________________________________________________________________
DD/MMM/YY HH:MM AMENU Credit Order Creation VN/SERIAL USER mulixx
1. Customer Code
2. Project
3. Allocation
Customer Code _____
_________________________________________________________________________
(The Customer Code registered under Customer Master Maintenance as opposed Supplier Maintenance).
The person on which the credit order is to be raised. If for a small transaction for which the money has been received *SUND could be used.
The project which is to receive the income.
The allocation which is to be credited if an income item, such as Sale of Unit in Multi Unit Development or other project income item it would be allocation 1000, if Sale of Scrap in demolition, it would go to allocation 2200. Remember income to Alloc. 1000 is treated as Project Income, while all other credits are treated as reduction in Project Costs.
The value allowed in the budget to be recovered by this trans- action. Generally contract value for which the Credit Order is being raised.
NOTE: Order test procedure to be followed as set out in Section 4 - Order Creation.
As with Accounts Payable, a Credit Order may be adjusted to represent the current situation. Not as critical as with Accounts Payable, as the value of the Credit Order does not hamper processing, only Final Forecasting.
____________________________________________________________________________
DD/MMM/YY HH:MM AMENU Credit Order Amendment VN/SERIAL USER mulixx
Credit Order No. Previous Amendment This Amendment
1. Customer
2. Project
3. Allocation
Credit Order Number _____
____________________________________________________________________________
. A listing of the accounts payable transaction file in either a summary or detailed format by all, group or individual customers.
________________________________________________________________________________
DD/MMM/YY HH:MM AMENU Accounts Receivable Report VN/SERIAL USER mulixx
1. Starting Customer
2. Ending Customer
3. Include Reconcile Items? (N)
Required for total retention
4. Start Date?
5. Cut Off Date?
6. Inv. or Due Date? (I)
7. Detail or Summary? (D)
8. Show Aging? (N)
9. Aging Date?
10. Payment Type "I,P,B"
11. Total Each Order
STARTING ACCOUNT
DEFAULT ALL ..
________________________________________________________________________________
The customer code of the client you wish to start with.
Yes or No response as to whether or not reconciled (on bank statement) payments should appear in the report or not.
The date you wish the payments and invoices to appear from e.g. If you only want payments & invoices for Dec. 1985, then start date 1/12/85, ending date 31/12/85 (or cut off date).
Default to start and cut off dates will give the full report.
Whether or not you require invoices or progress claims to appear at submitted date or only when they are due for pay- ment (generally invoice).
Detail will give you each invoice and payment. Summary will summarise for each client the amount outstanding (generally data).
The system if required, after each client outstanding will give the break up amounts of outstanding in 30 day, 60 day and 90 day periods. Ageing based on calendar months.
The date you want the ageing to show from.
If 'Y', then prints subtotal for each order.
EXAMPLE FOR 6.12
_____________________________________________________________________________
DD/MMM/YY HH:MM AMENU Accounts Receivable Recon. VN/SERIAL USER mulixx
Customer Code
Customer Code _____
_____________________________________________________________________________
Accounts Receivable Reconciliation is the process by which you reconcile payments made against invoices or progress claims.
In this program the system will run each invoice/claim and payment for the customer selected, and ask if this has been reconciled (paid) or not. Respond 'Y' - yes; 'N' - no. The net value of Invoices and receipts must be equal or reconciliation will not occur.
________________________________________________________________________________
DD/MMM/YY HH:MM AMENU Accounts Receivable Statements VN/SERIAL USER mulixx
1. Starting Customer Code
2. Ending Customer Code
3. Starting Date
4. Ending Date
5. Include Description
6. Company Number
Starting Customer Code (All) _____
________________________________________________________________________________
The Accounts Receivable statement program will give you a printed copy of the A/R reconciliation situation.
Customer code for the customer you wish a report on.
The period for which the report is to cover.
If you want the description entered with the Invoices to print as well.
The company under which the A/R reconciliation report is to be produced. Default ALV.
The creation and maintenance of customer code and claim file details. Before a new project or income source may be processed, the customer details have to be loaded into the Customer Master File.
________________________________________________________________________________
DD/MMM/YY HH:MM AMENU Customer Master Maintenance VN/SERIAL USER mulixx
DEL CHG ADD
1. Customer Number
2. Title
3. Short Name
4. Address
5.
6.
7. Pickup Address
8.
9. Contact
10.
11. Phone Number
12. Fax Number
13. Aus.Co.No ###
Customer Number _____
__________________________________________________________________
A five digit Customer Code which may be allocated as per the suppliers file where large repeat customer base is encountered or using the last 5 digits of the Project No. 1 where there is little repeat business.
Rules for creating the Customer Codes are the same as for Suppliers.
NOTE: The marketing database is interfaced and uses a 6 digit code
The full contractual name of the company you are contracting with, i.e. the name and company address which will appear on correspondence.
The name to be used within the system.
3 address lines that will appear on all correspondence.
The courier address; if as above, leave blank (Default).
Recoding contacts that will appear on Customer file listing.
Phone and/or Telex/Minerva contact numbers will also appear on Customer file listings.
The total value of invoices processed to date. Open as '0'.
This record may be cleared on periodical basis (i.e. each year) so that current transaction saving may be maintained (0 to begin with).
Total received to date (0 to begin with).
Total received this period (0 to begin with).
The values processed through overhead project options as defined, set at 0 to start.
The customers in a summary format including customer #, names, phone #, and contacts.
______________________________________________________________________________
DD/MMM/YY HH:MM AMENU Customer Master Report VN/SERIAL USER mulixx
1. Starting Customer Code
3. Ending Customer Code
Starting Customer (All) _____
__________________________________________________________________
This program provides a summary of invoices and progress claims that have been created but not yet posted to Accounts Receivable.
This report was added to allow Management to ensure all relevant working invoices have been posted and not individually left in negotiation limbo.
------------------------------------------------------------------------ DD/MM/YY HH:MM AMENU Invoices to be Issued VN/SERIAL USER mulixx 1. Include Progress Claims 2. Include Sundry Invoices Start Date End Date ------------------------------------------------------------------------
This will then list all progress claims that have not been posted.
This will then list the invoices that have been created but not yet posted.
Muli accepts no liability for this product as per the license agreement.
PROPRIETARY RIGHTS NOTICE
All rights reserved. This material contains proprietary information of Muli Management Pty. Ltd., N.S.W., Australia, embodying confidential information, ideas and expressions, no part of which may be reproduced in any form without written permission of Muli Management Pty. Ltd.
COPYRIGHT ©MULI Management Pty. Ltd.
All rights reserved.
/" target=_top>Home | /Manuals/" target=_top>Main Menu | Document resides @