Payment Request

From ADempiere ERP Wiki

(Difference between revisions)
Jump to: navigation, search
(Purpose)
(Design Considerations)
Line 18: Line 18:
== References  ==
== References  ==
== Design Considerations  ==
== Design Considerations  ==
 +
 +
It is necessary to add business partner primary key in GL journal lines, here the sql statement
 +
ALTER TABLE GL_JournalLine ADD C_BPartner_ID numeric(10) DEFAULT NULL.
 +
 +
It is necessary to add a new table and put it as a tab in project windows. Here the sql statement:
 +
CREATE TABLE c_projectschedule
 +
(
 +
  c_projectschedule_id numeric(10,0) NOT NULL,
 +
  ad_client_id numeric(10,0) NOT NULL,
 +
  ad_org_id numeric(10,0) NOT NULL,
 +
  isactive character(1) NOT NULL DEFAULT 'Y'::bpchar,
 +
  created timestamp without time zone NOT NULL DEFAULT now(),
 +
  createdby numeric(10,0) NOT NULL,
 +
  updated timestamp without time zone NOT NULL DEFAULT now(),
 +
  updatedby numeric(10,0) NOT NULL,
 +
  c_project_id numeric(10,0),
 +
  duedate timestamp without time zone NOT NULL,
 +
  dueamt numeric NOT NULL DEFAULT 0,
 +
  duebalance numeric NOT NULL DEFAULT 0,
 +
  isvalid character(1) NOT NULL DEFAULT 'Y'::bpchar,
 +
  c_paymentrequest_id numeric(10,0) DEFAULT NULL::numeric,
 +
  dm_document_id numeric(10,0) DEFAULT NULL::numeric,
 +
  description character varying(255),
 +
  ishistoricpay character(1),
 +
  percentage numeric(10,0) DEFAULT (0)::numeric
 +
)
===Assumptions===
===Assumptions===
-
===Dependencies===
+
 
 +
All components of the development must be translated to English.
 +
 
===Constraints===
===Constraints===
 +
 +
The invoices allocations are generated when the payment is generated, but the allocations are completed when the payment is completed
 +
== Glossary ==  
== Glossary ==  
==Functional Requirements==
==Functional Requirements==

Revision as of 20:02, 25 June 2013

Contents

Status

Contributors

Overview

The payment request functionality was created to facilitate the allocation of payments within ADempiere. This functionality is mainly used with invoices but it may also be used use to allocate payments related to stages of projects or accounting entries such as remuneration (payroll).

Purpose

Payment Requests are divided into three groups (types of request): from invoices, accounting and projects. Therefore the payment request is intended to facilitate the work in these 3 areas:

1. From invoices: suppose you want to pay several invoices from different suppliers (or same supplier) and you want to make a single payment and send it to the Bank. So the Bank pay these suppliers. This could be done without payment request, but that would take a lot of time to generate the payment (with the correct amount) and then correctly allocate to all invoices (one by one), so it is in this context where this functionality is helpful.

2. From accounting: suppose that you have 20 employees who want a pre-paid in the middle of the month, So you prepare a posting entry to match the accounts, but after that you must generate the payments and assign the corresponding charge. Here again, the payment request is very useful since it directly reads the account posting and generates as many payments as lines found in the GL journal (only GL journal lines with business partners), then before you complete the payment request you can select which lines you want to generate a payment and which lines not. Unlike of the “from invoices” where only one payment is generated here ADempiere generate as many payments as lines found in the payment request.


3. From project, assume that you are running or managing a project and it has several payment associated to a milestone, and you want to generate payments related to each milestone. The payment request generate payment very quickly related to the milestone.

References

Design Considerations

It is necessary to add business partner primary key in GL journal lines, here the sql statement ALTER TABLE GL_JournalLine ADD C_BPartner_ID numeric(10) DEFAULT NULL.

It is necessary to add a new table and put it as a tab in project windows. Here the sql statement: CREATE TABLE c_projectschedule (   c_projectschedule_id numeric(10,0) NOT NULL,   ad_client_id numeric(10,0) NOT NULL,   ad_org_id numeric(10,0) NOT NULL,   isactive character(1) NOT NULL DEFAULT 'Y'::bpchar,   created timestamp without time zone NOT NULL DEFAULT now(),   createdby numeric(10,0) NOT NULL,   updated timestamp without time zone NOT NULL DEFAULT now(),   updatedby numeric(10,0) NOT NULL,   c_project_id numeric(10,0),   duedate timestamp without time zone NOT NULL,   dueamt numeric NOT NULL DEFAULT 0,   duebalance numeric NOT NULL DEFAULT 0,   isvalid character(1) NOT NULL DEFAULT 'Y'::bpchar,   c_paymentrequest_id numeric(10,0) DEFAULT NULL::numeric,   dm_document_id numeric(10,0) DEFAULT NULL::numeric,   description character varying(255),   ishistoricpay character(1),   percentage numeric(10,0) DEFAULT (0)::numeric )

Assumptions

All components of the development must be translated to English.

Constraints

The invoices allocations are generated when the payment is generated, but the allocations are completed when the payment is completed

Glossary

Functional Requirements

Functional team

  • Volunteers for analyzing:
  • Result of analysis:

User roles & profiles

Business process definition

User stories

Functional requirements based on business processes

User Interface Mockups

Acceptance criteria

QA and test cases

Development infrastructure

Technical Requirements

Technical team

  • Volunteers for analyzing:
  • Result of analysis:

Data Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

Personal tools