Difference between revisions of "FS Commitment AR AP"
From WikiQSS
CarlosRuiz (talk | contribs) (template) |
CarlosRuiz (talk | contribs) (initial) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Commitment A/R A/P - Functional Specifications == |
| Line 7: | Line 7: | ||
==== Purpose ==== | ==== Purpose ==== | ||
| + | Adempiere allow accounting management for commitments (sales and purchase commitments), but the Accounts Receivable / Payable modules cannot manage or show the commitments from sales and purchase orders. | ||
| + | |||
| + | For some companies (for example building construction) it's important to manage the accounts receivable/payable based on the commitments agreed by customers (sales orders) and promised to vendors (purchase orders). | ||
==== Scope ==== | ==== Scope ==== | ||
| + | * Change the accounting receivables / payables functionalities to show data from sales/purchase orders. | ||
| + | * Allow to schedule payments in sales/purchase orders as well as in sales/purchase invoice (currently Adempiere just allow schedule on sales invoice) | ||
==== References ==== | ==== References ==== | ||
| + | ... empty ... | ||
=== Design Considerations === | === Design Considerations === | ||
| Line 19: | Line 25: | ||
==== Assumptions ==== | ==== Assumptions ==== | ||
| + | All components of the development must be translated to spanish. | ||
==== Dependencies ==== | ==== Dependencies ==== | ||
| + | ... empty ... | ||
==== Constraints ==== | ==== Constraints ==== | ||
| + | * Inherit to invoices the schedule agreed on orders when possible, there can be problematic to inherit the schedule when the invoice is create from a partial receipt/shipment, in this case it's proposed to create the schedule averaged. | ||
=== Glossary === | === Glossary === | ||
| + | ... empty ... | ||
=== Functional Requirements === | === Functional Requirements === | ||
| Line 34: | Line 44: | ||
==== User roles & profiles ==== | ==== User roles & profiles ==== | ||
| + | Sales people: they must fill the schedule of payments for sales orders when necessary | ||
| + | |||
| + | Purchase people: they must fill the schedule of payments for sales orders when necessary | ||
| + | |||
| + | A/R A/P managers: they will be allowed to include commitments on the reports | ||
==== Business process definition ==== | ==== Business process definition ==== | ||
| + | ==== User stories ==== | ||
| − | + | In building industry (in Colombia) a house is promised to a customer - the customer signs a promise to buy (a sales order) and the company cannot invoice until the house is completed and delivered to the customer. Since the sales order the customer agreed to pay in a defined schedule and the company needs to manage all the A/R including orders. | |
| + | Similar situation can be seen when dealing with vendors. And specifically this is needed if you want to issue a cash flow (see [[FS Cash Flow]]) because cash flow must include the agreed schedule of payments on purchase and sales orders. | ||
==== Functional requirements based on business processes ==== | ==== Functional requirements based on business processes ==== | ||
| + | * Modify Sales Order Window to allow capture of Payment Schedule | ||
| + | * Modify Purchase Order Window to allow capture of Payment Schedule | ||
| + | * Modify Purchase Invoice Window to allow capture of Payment Schedule | ||
| + | * Modify Open Items report to add a flag allowing to include commitments (orders) | ||
| + | * Modify Aging report to add a flag allowing to include commitments (orders) | ||
| + | * Modify Dunning configuration, report and functionality to add a flag allowing to include commitments (orders) | ||
==== User Interface Mockups ==== | ==== User Interface Mockups ==== | ||
| + | ... empty ... | ||
=== Technical Requirements === | === Technical Requirements === | ||
| + | * create a C_OrderPaySchedule table similar to C_InvoicePaySchedule | ||
| + | * when creating invoices from orders the pay schedule will be inherited | ||
| + | * when creating from shipments/receipts it will be inherited when possible and averaged in case of partials | ||
| + | * add a parameter to the report "Open Items" to allow the user to select include commitments | ||
| + | * add a parameter to the report "Aging" to allow the user to select include commitments | ||
| + | * change the dunning lines table to include information from orders | ||
| + | * add a parameter to the "Dunning" process to allow the user to select include commitments | ||
| + | * change default dunning template if needed to include commitments information | ||
=== Non-Functional Requirements === | === Non-Functional Requirements === | ||
| + | ... empty ... | ||
=== Open Discussion Items === | === Open Discussion Items === | ||
Latest revision as of 14:03, 27 August 2010
Contents
Commitment A/R A/P - Functional Specifications
Overview
Purpose
Adempiere allow accounting management for commitments (sales and purchase commitments), but the Accounts Receivable / Payable modules cannot manage or show the commitments from sales and purchase orders.
For some companies (for example building construction) it's important to manage the accounts receivable/payable based on the commitments agreed by customers (sales orders) and promised to vendors (purchase orders).
Scope
- Change the accounting receivables / payables functionalities to show data from sales/purchase orders.
- Allow to schedule payments in sales/purchase orders as well as in sales/purchase invoice (currently Adempiere just allow schedule on sales invoice)
References
... empty ...
Design Considerations
Assumptions
All components of the development must be translated to spanish.
Dependencies
... empty ...
Constraints
- Inherit to invoices the schedule agreed on orders when possible, there can be problematic to inherit the schedule when the invoice is create from a partial receipt/shipment, in this case it's proposed to create the schedule averaged.
Glossary
... empty ...
Functional Requirements
User roles & profiles
Sales people: they must fill the schedule of payments for sales orders when necessary
Purchase people: they must fill the schedule of payments for sales orders when necessary
A/R A/P managers: they will be allowed to include commitments on the reports
Business process definition
User stories
In building industry (in Colombia) a house is promised to a customer - the customer signs a promise to buy (a sales order) and the company cannot invoice until the house is completed and delivered to the customer. Since the sales order the customer agreed to pay in a defined schedule and the company needs to manage all the A/R including orders.
Similar situation can be seen when dealing with vendors. And specifically this is needed if you want to issue a cash flow (see FS Cash Flow) because cash flow must include the agreed schedule of payments on purchase and sales orders.
Functional requirements based on business processes
- Modify Sales Order Window to allow capture of Payment Schedule
- Modify Purchase Order Window to allow capture of Payment Schedule
- Modify Purchase Invoice Window to allow capture of Payment Schedule
- Modify Open Items report to add a flag allowing to include commitments (orders)
- Modify Aging report to add a flag allowing to include commitments (orders)
- Modify Dunning configuration, report and functionality to add a flag allowing to include commitments (orders)
User Interface Mockups
... empty ...
Technical Requirements
- create a C_OrderPaySchedule table similar to C_InvoicePaySchedule
- when creating invoices from orders the pay schedule will be inherited
- when creating from shipments/receipts it will be inherited when possible and averaged in case of partials
- add a parameter to the report "Open Items" to allow the user to select include commitments
- add a parameter to the report "Aging" to allow the user to select include commitments
- change the dunning lines table to include information from orders
- add a parameter to the "Dunning" process to allow the user to select include commitments
- change default dunning template if needed to include commitments information
Non-Functional Requirements
... empty ...
