Currency Selection Issues in Payment Entry Recording

ERPNext
1

Problem Description:
When attempting to record payments in foreign currencies in ERPNext, users face restrictions that hinder the natural workflow process. The current system does not allow independent currency selection within payment entries, instead mandatorily linking it to bank or cash accounts.

Technical Details:

  1. Core Limitation:

    • Currency selection field is not independently available in payment entries
    • Currency is predetermined based on bank account or cash account settings
    • Cannot change currency during payment entry creation if linked to a pre-configured account

  2. Current Complex Workflow:

    • To receive $1000 from a customer and convert it to local currency:
      1. Create payment entry using dollar cash account
      2. Create transfer entry (Contra Entry) from dollar cash account to local currency cash account
    • Process requires two separate entries and double data entry

Requirements:

  1. Currency Selection Flexibility:

    • Ability to select currency directly from payment entry
    • No mandatory linking of currency to bank/cash account

  2. Currency Conversion Support:

    • Add “Convert to Base Currency” option in payment entry
    • Automatic equivalent amount calculation based on exchange rate
    • Ability to specify final receiving account (in base currency)

Example of Proposed Interface:

Flexible Currency Payment Entry
---
- Currency: [USD - US Dollar ▼] ← (Free selection)
- Original Amount: [1000] 
- Exchange Rate: [3.75] ← (Auto + Editable)
- Equivalent Amount: [3750 SAR] ← (Auto-calculated)
- □ Auto-convert to base currency
- Receiving Account: [Base Currency Account ▼]

User Impact:

  • Wasted time creating multiple entries
  • Increased probability of data entry errors
  • Unnecessary complexity in daily operations
  • Difficulty tracking currency conversion processes

Proposed Solution:
Develop payment entry interface to support independent currency selection and add currency conversion options within the same document, ensuring a flexible and efficient workflow that meets the needs of international businesses.

2

Hi there,

The accounting for this kind of thing can work in a number of different ways, so I’m not sure it would make sense to hard-code one particular approach into the system.

However you do it, though, It would just be a thin layer on top of the already existing functionality. You could add this feature yourself with a few custom fields and a bit of client scripting. Just add “Paid Currency”, “Paid Amount”, and “Exchange Rate Applied”. The script would trigger on field change to update the base paid_amount field, and you could also automate pulling an exchange rate from whatever internal or external source you use.

3

As for me, I will implement it, but it is essential and must be included in the system because most systems operate this way, and it is an important feature.