ZH/List Develop

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

以下案例為

Ecosoft系統公司為自行車製造業客製化實際研習案例

(技術轉移顧問 Albert Skype:Adempiere/Compiere)

Ecosoft/Customization for Bicycle Manufacturer Case Study From AdempiereWiki

Revision as of 07:59, 26 September 2010 by Kittiu (Talk | contribs) (diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) Jump to: navigation, search

本頁次為草稿文件修飾進行中

(技術轉移顧問 Albert Skype:Adempiere/Compiere)

This page is under construction --Kittiu 16:18, 20 September 2010 (UTC) Contents [hide] 

   * 1 Overview
   * 2 Enable Print & Print Preview Buttons With specific Logic
         o 2.1 Background
         o 2.2 Requirement Summary
         o 2.3 Deployment
   * 3 Simple One Time Business Partner Credit Approval
         o 3.1 Background
         o 3.2 Requirement Summary
         o 3.3 Deployment
   * 4 DocAction to show only Prepare when DocStatus = Draft
         o 4.1 Background
         o 4.2 Requirement Summary
         o 4.3 Deployment
   * 5 Overwriting UOM Conversion Rate on MM Receipt
         o 5.1 Background
         o 5.2 Requirement Summary
         o 5.3 Deployment

Overview

This page contain specific customization made for Bicycle Manufacturer Case Study. All customizations are made without touching the core application, using customization.jar techinque

Source code (compiled to customization.jar) of this project will be updated to @ Bicycle SVN Enable Print & Print Preview Buttons With specific Logic Background

As of AD-360LTS, the Print and Print Preview Button is still not capable of enable/disable based on Document Status or other conditions, but only based on 1) report existence for that document type and 2) whether user has right to that report.

In our project, we have the need to prevent Document Forms (i.e., sales order, invoice, receipt) from being printed out when the document is not yet completed (or closed or voided) (DocStatus = CO, CL). There are some other alternative without touching the code, such as, have the status printout in big letters, so that people can spot it by their eye. But this is rejected by the client. Requirement Summary 


   * Use System Configurator window to control whether to use this feature.
   * Print and Print Preview button will be enabled only when the condition set is met. 
   * For example, we might want print buttons to enable only when document status is Complete/Closed/Voided, 
   * but except MM Shipment and AR Receipt Form that will be enabled in all DocStatus. 
   
   * 本頁次為草稿文件修飾進行中(敬請支持:技術轉移顧問 Albert Skype:Adempiere/Compiere)
   
   * 將[列印]/[預覽列印]按鍵狀態[有效]/[失效]是依據不同單據基礎類別不同單據狀態,
   * [MM出貨]/[AR收款]在任何狀態下是有效的,
   * 其他單據只有在[Complete/Closed/Voided]狀態才有效.


Deployment

1) org.compiere.model.GridTab.java

  • Modify isPrinted() function to also check for the ENABLE_PRINT_BUTTON_WITH_LOGIC’s logic

public boolean isPrinted() { // Start of Modification - Enable Print Buttons with some logics

/* * return m_vo.AD_Process_ID != 0; */

if (m_vo.AD_Process_ID == 0) { return false; } else 

               { // Check if Status is on the Enable List

String docstatuslist = MSysConfig.getValue 

               ("ENABLE_PRINT_BUTTON_WITH_LOGIC", null, 
               Env.getAD_Client_ID(m_vo.ctx), 
               Env.getAD_Org_ID(m_vo.ctx)
               );

if (docstatuslist != null && docstatuslist.toString().length() > 0) return Evaluator.evaluateLogic(this, docstatuslist); else // No logic defined, back to normal return true; } // End of Modification - Enable Print Buttons with some logics } // isPrinted


2) org.compiere.apps.APanel.java 

   * Modify getTitle() function add 2 lines to also set enable the button,
         o aPrint.setEnabled(m_curTab.isPrinted());
         o aPrintPreview.setEnabled(m_curTab.isPrinted());

public String getTitle() {

// Start of Modification (add) - Enable Print Buttons with some logics

aPrint.setEnabled(m_curTab.isPrinted());

aPrintPreview.setEnabled(m_curTab.isPrinted());

// End of Modification - Enable Print Buttons with some logics

3) Add new record in System Configurator window

  • Name: ENABLE_PRINT_BUTTON_WITH_LOGIC
  • Search Key: 文件類型為 MM/AR 與 文件狀態 CO/CL/VO 永遠有效

@C_DocType_ID@=120 | @C_DocType_ID@=119 | @DocStatus@='CO' | @DocStatus@='CL' | @DocStatus@='VO'

  • Note: 120, 119 is the c_doctype_id, many change from system to system.
  • Check Document Type window for the current id.

Remarks: 

   * Discussion about this feature in forum [1]
   * In tracker, but not trunkable, as there is another alternative using rule script (applicable but not same result) [2]

Simple One Time Business Partner Credit Approval Background

給客戶一個信用狀態為 : 信用觀察 Given a Business Partner with Credit Status = Credit Watch. In the existing functionality,

  • 開受訂單據時如果信用餘額不足將無法成立,並經單據狀態改為[驗證失效]
  • If user creates a Sales Order (SO)
  • for this Business Partner with Sales Amount more than the credit available (remaining),
  • He/she will not be able to complete the document.
  • Clicking on Complete button will give warning message Credit On Hold…
  • and Document Status will be changed to Invalid

As per existing functionality, the supervisor / admin will have to login and make change to Credit Status of this BP in Business Partner window to “Credit OK” or to increase the Credit Limit amount, and then supervisee will be able to complete document.

Currently, there is no built-in way to do one time approval in ADempiere.

This enhancement is to create a simple way(by select a CheckBox) for Supervisor of the SO creator to review and if everything is ok, make approval directly to this specific SO by ticking a CheckBox. And as the checkbox is ticked, the approval process will be ignored.

Remarks: At first, we are looking at using standard Workflow, but eventually found some difficulties,

信用檢查未通過時已經中止工作流程, 因此無法利用工作流程來做信用核准.

以下 Albert 個人經驗是 :

一般上市公司信用授權額度並非業務主管的權限

是業務主管可以申請更改該客戶信用額度

客戶信用額度是財務部在控管

我們無法理解財務部主管

怎會跑到業務工作流程會簽作業!!!

這個按例 Albert 個人經驗是 :

不推薦他的工作流程

但是介紹一下他如何改而已

這種流程是一種偏方看看就好別相信!!

  • Doc Process WF: This type of workflow is not even fired yet,
  • as AD already stop it when check on Credit Limit.
  • Doc Value WF: This type of workflow will always send message to the Invoker
  • (which is the user himself, no use). There is no way to specify the target approver.
  • This enhancement is not submitted as FR, as it is quite specific to this customer

Requirement Summary

Following is the TO-BE process for SO Credit Approval. 

   * User creates SO (Sales Order), select BP (Business Partner) and add SO Lines with the total amount exceed Credit Available for this BP.
   * User clicks Complete Button to try to complete the document. The system will not allow and give warning message. DocStaus changes to Invalid. Without changing of the amount of SO lines, he/she will not able to continue.
   * User will notify his/her supervisor (manually) to approve the underline SO number.
   * Supervisor, will login to ADempiere as normal, open up the problem SO number, review and make decision.
         o If Approve,
               + Supervisor will click on “Credit Approved?” checkbox at the bottom of page and Save this document.
               + Supervisor will either notify his/her supervisee to go back and complete it, or he/she will complete by him/herself.
               + With the “Credit Approved?” checkbox checked, ADempiere should not give any warning.
               + End of the completion process. 
         o If not Approve,
               + Supervisor simply does not do anything, and either go back to his/her to void it. Or he/she could void it by him/herself.
               + Supervisor simply does not do anything, and either
                     # Keep it as ‘Invalid’ status and approve it when BP settles payment and their credit is available.
                     # Or void it by him/herself or even go back to his/her supervisee to do it.

Note: 

   * Since we do not use the Workflow to track, but use a simple Credit Approved CheckBox. Do make sure that, 

   * This checkbox is visible only when the document status is Invalid
   * This checkbox should be Editable only for the specified supervisor but show as Read Only for other users at all time.
   * When SO document is copied as new SO, this checkbox will always be unchecked (although the original is checked)
   * Even this SO is already approved, but if user change Business Partner or the Line Amount (so the credit available is changed), this checkbox should be cleared.

Deployment

1) Use Application Dictionary to setup proper UI 

   * Table and column widnow --> IsCreditApproved column in table C_Order set to editable.

update ad_column set isupdateable = 'Y' where ad_column_id = 2176; 

   * Window Tab & Field window --> add Credit Approved field at the bottom of window.

update ad_field set seqno = 540, issameline = 'Y', isdisplayed = 'Y', displaylogic = '@OrderType@=SO&@DocStatus@=IN' where ad_field_id = 1088; 

   * Use Table and Column window and set Readonly logic for Credit Approved field, Readonly for end users, and Editable for approving users.

update ad_column set readonlylogic = '@#AD_User_Name@!nantachai & @#AD_User_Name@!SuperUser' where ad_column_id = 2176;

2) Setup Rules Scripts to ensure that if user change BP or total amount, Credit Approved will be unchecked 

   * Rule: Reset_IsCreditApproved

import org.compiere.util.DB; String sql = "update c_order set iscreditapproved = 'N' where c_order_id = "+ A_Tab.getValue("C_Order_ID"); int no = DB.executeUpdate(sql); result = ""; 


   * Table and Column window --> Assign this rule to
         o C_Order.C_BPartner_ID: @script:beanshell:Reset_IsCreditApproved
         o C_OrderLine.LineNetAmt: @script:beanshell:Reset_IsCreditApproved

3) org.compiere.model.MOrder.java 

   * Modify method prepareIt() so that, if IsCreditApproved field is ‘Y’, then by pass the credit checking.

// -- if (MBPartner.SOCREDITSTATUS_CreditHold.equals(bp.getSOCreditStatus(grandTotal))) if (MBPartner.SOCREDITSTATUS_CreditHold.equals(bp.getSOCreditStatus(grandTotal)) && this.isCreditApproved() == false)

DocAction to show only Prepare when DocStatus = Draft Background

Each Document Type, there is a certain list of DocAction defined in ADempiere. Although we can use Role Security / Document Action to control list of action based on role, we can't restrict DocAction based on DocStatus. In our case, when document status is "Prepare" we don't want want end user to complete it immediately (double check routine). Carlos Ruiz have discuss it here. Requirement Summary

For Order Window 

   * When DocStatus = “Draft”
         o Click on DocAction button
         o Show only “Prepare” action 
   * When DocStatus != “Draft”
         o Click on DocAction button
         o Show more actions, i.e., Prepare, Complete, Close, Void

Deployment

1) org.compiere.model.MOrder.java 

   * Implement DocOption interface

public class MOrder extends X_C_Order implements DocAction, DocOptions { 

   * Add customizeValidActions() function to overwrite the existing list of action. 

   /**
    * Customize Valid Actions
    * @param docStatus
    * @param processing
    * @param orderType
    * @param isSOTrx
    * @param AD_Table_ID
    * @param docAction
    * @param options
    * @return Number of valid options
    */
   public int customizeValidActions (String docStatus, Object processing, 
                   String orderType, String isSOTrx, int AD_Table_ID, String[] docAction, String[] options, int index) {
   	
   	// If status = Drafted, only show "Prepare" in the list
   	if (docStatus.equals(DocumentEngine.STATUS_Drafted)) {
   		// 1. Remove all
   		for (int i = 0; i < options.length; i++) {
   			options[i] = null;
   		}
   		// 2. Add Prepare
   		options[0] = DocumentEngine.ACTION_Prepare;
   		index = 1;
   	}
   	
   	return index;
   }


2) For Order windows, make sure default is set to "Prepare"


Overwriting UOM Conversion Rate on MM Receipt Background

For some material (i.e., steel), purchased as one unit (i.e., KG) and receive in another unit (i.e., pieces). But when receiving, the conversion rate can vary slightly.

For example, purchase 1 Kg of steal = 100 pieces on average conversion rate. But when receive material it could be, i.e., 102 pieces or 97 pieces. As such, when receiving we need to overwrite the conversion rate and keep that overwriting rate to this receiving transaction. Requirement Summary

For MM Receipt Line window 

   * Introduce new field, Overwrite Rate
   * In case need to change rate, user fill in the new rate in Overwrite Rate --> Quality field is recalculated with the new rate.
   * The new rate should be stored in this MM Receipt Line (in the table)

Deployment

1) User Application Dictionary to create new TextBox "Conversion Rate Overwrite" in Receipt Line tab 

   * Create Element OverwriteRate_Overwrite Rate
   * Create new Column OverwriteRate_Overwrite Rate under table M_InOutLine_Shipment/Receipt Line --> number (22), Default=1, Readonly Logic='@OverwriteRate@=1', Callout=org.compiere.model.CalloutInOut.qty
   * Create new field OverwriteRate_Overwrite Conversion Rate next to field Movement Quality in Receipt Line_Material Receipt window
   * Mark this OverwriteRate and Movement Quality to always displayed (no Display Logic)
   * SQL Script [3]

2) org.compiere.model.MInOutLine.java 

   * Modify beforeSave(), to ensure that the OverwriteRate is set correctly.

3) org.compiere.model.CalloutInOut.java 

   * Modify callout, to recalculate the Movement Quality based on new Overwriting Rate [4]


(Difference between revisions) Jump to: navigation, search Revision as of 07:59, 26 September 2010 (view source) Kittiu (Talk | contribs) (→Deployment) ← Older edit

Latest revision as of 08:58, 26 September 2010 (view source) Kittiu (Talk | contribs) (→Deployment)

Line 210: Line 210:

  • Mark this OverwriteRate and Movement Quality to always displayed (no Display Logic)
  • Mark this OverwriteRate and Movement Quality to always displayed (no Display Logic)

-

2) org.compiere.model.MInOutLine.java

+

2) Modify models for M_InOutLine

-

  • Modify beforeSave(), to ensure that the OverwriteRate is set correctly.

+ 

	+
  • org.compiere.model.MInOutLine.java --> Modify beforeSave(), to ensure when InOut line is created new (from any method), the OverwriteRate is set correctly to --> MovementQty / Qty [4]
3) org.compiere.model.CalloutInOut.java
3) org.compiere.model.CalloutInOut.java
  • Modify callout, to recalculate the Movement Quality based on new Overwriting Rate [5]
  • Modify callout, to recalculate the Movement Quality based on new Overwriting Rate [6]

Latest revision as of 08:58, 26 September 2010

This page is under construction --Kittiu 16:18, 20 September 2010 (UTC) Contents [hide] 

   * 1 Overview
   * 2 Enable Print & Print Preview Buttons With specific Logic
         o 2.1 Background
         o 2.2 Requirement Summary
         o 2.3 Deployment
   * 3 Simple One Time Business Partner Credit Approval
         o 3.1 Background
         o 3.2 Requirement Summary
         o 3.3 Deployment
   * 4 DocAction to show only Prepare when DocStatus = Draft
         o 4.1 Background
         o 4.2 Requirement Summary
         o 4.3 Deployment
   * 5 Overwriting UOM Conversion Rate on MM Receipt
         o 5.1 Background
         o 5.2 Requirement Summary
         o 5.3 Deployment

Overview

This page contain specific customization made for Bicycle Manufacturer Case Study. All customizations are made without touching the core application, using customization.jar techinque

Source code (compiled to customization.jar) of this project will be updated to @ Bicycle SVN Enable Print & Print Preview Buttons With specific Logic Background

As of AD-360LTS, the Print and Print Preview Button is still not capable of enable/disable based on Document Status or other conditions, but only based on 1) report existence for that document type and 2) whether user has right to that report.

In our project, we have the need to prevent Document Forms (i.e., sales order, invoice, receipt) from being printed out when the document is not yet completed (or closed or voided) (DocStatus = CO, CL). There are some other alternative without touching the code, such as, have the status printout in big letters, so that people can spot it by their eye. But this is rejected by the client. Requirement Summary 

   * Use System Configurator window to control whether to use this feature.
   * Print and Print Preview button will be enabled only when the condition set is met. For example, we might want print buttons to enable only when document status is Complete/Closed/Voided, but except MM Shipment and AR Receipt Form that will be enabled in all DocStatus.

Deployment

1) org.compiere.model.GridTab.java 

   * Modify isPrinted() function to also check for the ENABLE_PRINT_BUTTON_WITH_LOGIC’s logic

public boolean isPrinted() { // Start of Modification - Enable Print Buttons with some logics /* * return m_vo.AD_Process_ID != 0; */ if (m_vo.AD_Process_ID == 0) { return false; } else { 

               // Check if Status is on the Enable List

String docstatuslist = MSysConfig.getValue("ENABLE_PRINT_BUTTON_WITH_LOGIC", null, Env.getAD_Client_ID(m_vo.ctx), Env.getAD_Org_ID(m_vo.ctx)); if (docstatuslist != null && docstatuslist.toString().length() > 0) return Evaluator.evaluateLogic(this, docstatuslist); else // No logic defined, back to normal return true; } // End of Modification - Enable Print Buttons with some logics } // isPrinted

2) org.compiere.apps.APanel.java 

   * Modify getTitle() function add 2 lines to also set enable the button,
         o aPrint.setEnabled(m_curTab.isPrinted());
         o aPrintPreview.setEnabled(m_curTab.isPrinted());

public String getTitle() { // Start of Modification (add) - Enable Print Buttons with some logics aPrint.setEnabled(m_curTab.isPrinted()); aPrintPreview.setEnabled(m_curTab.isPrinted()); // End of Modification - Enable Print Buttons with some logics

3) Add new record in System Configurator window 

   * Name: ENABLE_PRINT_BUTTON_WITH_LOGIC
   * Search Key: @C_DocType_ID@=120 | @C_DocType_ID@=119 | @DocStatus@='CO' | @DocStatus@='CL' | @DocStatus@='VO'
   * Note: 120, 119 is the c_doctype_id, many change from system to system. Check Document Type window for the current id.

Remarks: 

   * Discussion about this feature in forum [1]
   * In tracker, but not trunkable, as there is another alternative using rule script (applicable but not same result) [2]

Simple One Time Business Partner Credit Approval Background

Given a Business Partner with Credit Status = Credit Watch. In the existing functionality, 

   * If user creates a Sales Order (SO) for this Business Partner with Sales Amount more than the credit available (remaining),
   * He/she will not be able to complete the document. Clicking on Complete button will give warning message Credit On Hold… and Document Status will be changed to Invalid

As per existing functionality, the supervisor / admin will have to login and make change to Credit Status of this BP in Business Partner window to “Credit OK” or to increase the Credit Limit amount, and then supervisee will be able to complete document.

Currently, there is no built-in way to do one time approval in ADempiere.

This enhancement is to create a simple way (by select a CheckBox) for Supervisor of the SO creator to review and if everything is ok, make approval directly to this specific SO by ticking a CheckBox. And as the checkbox is ticked, the approval process will be ignored.

Remarks: At first, we are looking at using standard Workflow, but eventually found some difficulties, 

   * Doc Process WF: This type of workflow is not even fired yet, as AD already stop it when check on Credit Limit.
   * Doc Value WF: This type of workflow will always send message to the Invoker (which is the user himself, no use). There is no way to specify the target approver.
   * This enhancement is not submitted as FR, as it is quite specific to this customer

Requirement Summary

Following is the TO-BE process for SO Credit Approval. 

   * User creates SO (Sales Order), select BP (Business Partner) and add SO Lines with the total amount exceed Credit Available for this BP.
   * User clicks Complete Button to try to complete the document. The system will not allow and give warning message. DocStaus changes to Invalid. Without changing of the amount of SO lines, he/she will not able to continue.
   * User will notify his/her supervisor (manually) to approve the underline SO number.
   * Supervisor, will login to ADempiere as normal, open up the problem SO number, review and make decision.
         o If Approve,
               + Supervisor will click on “Credit Approved?” checkbox at the bottom of page and Save this document.
               + Supervisor will either notify his/her supervisee to go back and complete it, or he/she will complete by him/herself.
               + With the “Credit Approved?” checkbox checked, ADempiere should not give any warning.
               + End of the completion process. 
         o If not Approve,
               + Supervisor simply does not do anything, and either go back to his/her to void it. Or he/she could void it by him/herself.
               + Supervisor simply does not do anything, and either
                     # Keep it as ‘Invalid’ status and approve it when BP settles payment and their credit is available.
                     # Or void it by him/herself or even go back to his/her supervisee to do it.

Note: 

   * Since we do not use the Workflow to track, but use a simple Credit Approved CheckBox. Do make sure that, 

   * This checkbox is visible only when the document status is Invalid
   * This checkbox should be Editable only for the specified supervisor but show as Read Only for other users at all time.
   * When SO document is copied as new SO, this checkbox will always be unchecked (although the original is checked)
   * Even this SO is already approved, but if user change Business Partner or the Line Amount (so the credit available is changed), this checkbox should be cleared.

Deployment

1) Use Application Dictionary to setup proper UI 

   * Table and column widnow --> IsCreditApproved column in table C_Order set to editable.

update ad_column set isupdateable = 'Y' where ad_column_id = 2176; 

   * Window Tab & Field window --> add Credit Approved field at the bottom of window.

update ad_field set seqno = 540, issameline = 'Y', isdisplayed = 'Y', displaylogic = '@OrderType@=SO&@DocStatus@=IN' where ad_field_id = 1088; 

   * Use Table and Column window and set Readonly logic for Credit Approved field, Readonly for end users, and Editable for approving users.

update ad_column set readonlylogic = '@#AD_User_Name@!nantachai & @#AD_User_Name@!SuperUser' where ad_column_id = 2176;

2) Setup Rules Scripts to ensure that if user change BP or total amount, Credit Approved will be unchecked 

   * Rule: Reset_IsCreditApproved

import org.compiere.util.DB; String sql = "update c_order set iscreditapproved = 'N' where c_order_id = "+ A_Tab.getValue("C_Order_ID"); int no = DB.executeUpdate(sql); result = ""; 


   * Table and Column window --> Assign this rule to
         o C_Order.C_BPartner_ID: @script:beanshell:Reset_IsCreditApproved
         o C_OrderLine.LineNetAmt: @script:beanshell:Reset_IsCreditApproved

3) org.compiere.model.MOrder.java 

   * Modify method prepareIt() so that, if IsCreditApproved field is ‘Y’, then by pass the credit checking.

// -- if (MBPartner.SOCREDITSTATUS_CreditHold.equals(bp.getSOCreditStatus(grandTotal))) if (MBPartner.SOCREDITSTATUS_CreditHold.equals(bp.getSOCreditStatus(grandTotal)) && this.isCreditApproved() == false)

DocAction to show only Prepare when DocStatus = Draft Background

Each Document Type, there is a certain list of DocAction defined in ADempiere. Although we can use Role Security / Document Action to control list of action based on role, we can't restrict DocAction based on DocStatus. In our case, when document status is "Prepare" we don't want want end user to complete it immediately (double check routine). Carlos Ruiz have discuss it here. Requirement Summary

For Order Window 

   * When DocStatus = “Draft”
         o Click on DocAction button
         o Show only “Prepare” action 
   * When DocStatus != “Draft”
         o Click on DocAction button
         o Show more actions, i.e., Prepare, Complete, Close, Void

Deployment

1) org.compiere.model.MOrder.java 

   * Implement DocOption interface

public class MOrder extends X_C_Order implements DocAction, DocOptions { 

   * Add customizeValidActions() function to overwrite the existing list of action. 

   /**
    * Customize Valid Actions
    * @param docStatus
    * @param processing
    * @param orderType
    * @param isSOTrx
    * @param AD_Table_ID
    * @param docAction
    * @param options
    * @return Number of valid options
    */
   public int customizeValidActions (String docStatus, Object processing, 
                   String orderType, String isSOTrx, int AD_Table_ID, String[] docAction, String[] options, int index) {
   	
   	// If status = Drafted, only show "Prepare" in the list
   	if (docStatus.equals(DocumentEngine.STATUS_Drafted)) {
   		// 1. Remove all
   		for (int i = 0; i < options.length; i++) {
   			options[i] = null;
   		}
   		// 2. Add Prepare
   		options[0] = DocumentEngine.ACTION_Prepare;
   		index = 1;
   	}
   	
   	return index;
   }


2) For Order windows, make sure default is set to "Prepare"


Overwriting UOM Conversion Rate on MM Receipt Background

For some material (i.e., steel), purchased as one unit (i.e., KG) and receive in another unit (i.e., pieces). But when receiving, the conversion rate can vary slightly.

For example, purchase 1 Kg of steal = 100 pieces on average conversion rate. But when receive material it could be, i.e., 102 pieces or 97 pieces. As such, when receiving we need to overwrite the conversion rate and keep that overwriting rate to this receiving transaction. Requirement Summary

For MM Receipt Line window 

   * Introduce new field, Overwrite Rate
   * In case need to change rate, user fill in the new rate in Overwrite Rate --> Quality field is recalculated with the new rate.
   * The new rate should be stored in this MM Receipt Line (in the table)

Deployment

1) User Application Dictionary to create new TextBox "Conversion Rate Overwrite" in Receipt Line tab 

   * Create Element OverwriteRate_Overwrite Rate
   * Create new Column OverwriteRate_Overwrite Rate under table M_InOutLine_Shipment/Receipt Line --> number (22), Default=1, Readonly Logic='@OverwriteRate@=1', Callout=org.compiere.model.CalloutInOut.qty
   * Create new field OverwriteRate_Overwrite Conversion Rate next to field Movement Quality in Receipt Line_Material Receipt window
   * Mark this OverwriteRate and Movement Quality to always displayed (no Display Logic)
   * SQL Script [3]

2) Modify models for M_InOutLine 

   * Generate Model Classes for M_InOutLine [4]
   * org.compiere.model.MInOutLine.java --> Modify beforeSave(), to ensure when InOut line is created new (from any method), the OverwriteRate is set correctly to --> MovementQty / Qty [5]

3) org.compiere.model.CalloutInOut.java 

   * Modify callout, to recalculate the Movement Quality based on new Overwriting Rate [6]
Retrieved from "http://www.adempiere.com/index.php5?title=ZH/List_Develop&oldid=31351"