Payment Request

From ADempiere
Revision as of 07:03, 15 July 2013 by Rvergara (Talk) (Contributors)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Status

Contributors

  • Alberto Abudinen
  • OFB Consulting Ltda

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

Please see File:OFB Manual de solicitud de pago v11.pdf (in Spanish)

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:
    • Enrique Ruibal 14:01, 1 July 2013 (UTC) - Functional and Technical Review

Result of analysis from personal POV (this is for initial discussion)

Screen1.png

  • Comments from General Process
    • PayComplete flag should be removed it won't be required
    • Signature 1 and Signature 2 fields should be removed because it is not part of standard functionality as approvals should be implemented with workflows (as general rule)
    • Business Partner field should be removed not required here, for reference see Payment Selection Window
    • Create Lines from should display all business partners, not just one, please see comparison versus Payment Selection (Manual) Screen

Screen2.png

  • A design consideration should be made to change the 'Process Now' button action, this should generate Prepared Payments instead of the Payments themselves, the end result should be the same as with current Payment Selection (Manual) but this approach using Payment Requests will provide more flexibility.

Screen3.png

  • The payment request from accounting is a great feature, since it allows to create a Payment directly from GL Journal lines!

Note: Still need to review accounting facts created from this transaction.

Screen4.png

  • Summary
    • Payment Requests provide additional flexibility to the usually cumbersome task of massively and at the same time selectively creating payments, I think these enhancements will be highly appreciated by users of mid size companies and public organizations.
    • There are a few caveats that need to be resolved before these enhancements are integrated into trunk, namely:
      • The Business Partner field should be removed from the current Payment Request header and make it discretionally selectable by user instead.
      • The Processing function should be changed to create Prepared Payment records instead of final Payments

User roles & profiles

Business process definition

See Purpose above

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