Cleared Date for Payments can be viewed through Edit screen or though the entire page of payments tab (Cleared checked via “Edit Columns”) following 23.4.20 implementation:
Would it be possible to view also the Cleared date on Payment — View screen?
To date, this might be possible only through a custom theme (however, it is an obsolete feature) if the variable of Cleared date is known.
Cloud - 24.2.19.1314
What is the use case? When a payment is first recorded, there generally is no cleared date. A business has little or no control over when a payment clears at the bank.
While it’s true that the cleared date may not always be known at the time of payment, there are practical scenarios where having this information is beneficial.
One such instance is with remittances, especially when making web banking transfers to third-party banks. In these cases, businesses have a reasonable estimate of when the payment is to be cleared.
For example, if a payment is submitted/recorded on day D by X hour, it will clear on the next day (D+1) and, if is recorded after X hour, then it will be cleared the following day (D+2) (this is an example of an internet banking rule e.g. in Greece and as I know in other countries in Europe, having this info depicted on the screen whenever we make a payment through web banking services).
Consider the situation where a business wants to share payment details with a supplier via email. By capturing and displaying the scheduled cleared date (e.g., D+1 or D+2) on the Payment - View screen, the supplier gains visibility into when the amount is expected to be credited to its account.
This additional information can facilitate smoother communication.
I fail to see that your justification adds weight to your request.
First, entering estimates—reasonable or not—in your accounting records is always a bad idea.
Second, your internal banking details and clearance status are no business of your supplier. Your supplier has no interaction with your bank on your behalf. More important, the date a transaction is cleared by your bank is of no use to your supplier, who cares only when it clears the supplier’s bank. The only communication that might matter to the supplier cannot be made smoother by information from your bank.
Let’s delve into this with a concrete example to better illustrate my point.
Suppose I make a remittance on February 1st, after 4:00 PM, to pay supplier X. Since it involves a transfer to a third-party bank, it’s processed after the bank’s specified cutoff time (4:00 PM), resulting in it being “cleared” after 2 days, i.e., on February 3rd (if it was before this deadline, then it would be cleared the next day). This information is reflected on the payment screen at the time of entering the payment (so it is something solid, not only a reasonable estimate).
Consequently, on February 1st, my bank’s “account balance” is reduced by the payment amount, and on February 3rd, the corresponding “available balance” is similarly reduced. This is actual data provided by the bank.
In the case of such remittances, the “cleared date” for my bank is also the date when the amount appears in the supplier’s account. Therefore, in this context, the “cleared date” is not only relevant for my internal records but also aligns with when the supplier sees the credited amount (so, it can proceed e.g. with the delivery of the goods ordered when the agreement is to receive the payment before).
Given the existing format of “Payment - View,” displaying the cleared date becomes valuable in accurately reflecting these real-time banking details and facilitating better coordination with suppliers.
Since that Cleared date data is already available through Edit screen and also via Payments tab screen view, why not to have such a choice to be depicted also in the Payment - View?
Here is where you are wrong and why your justification falls apart. The clearance date is when a transaction is recorded as having been processed by your bank. There is no guarantee the receiving bank will process the deposit to your supplier’s account at the same moment. Very often—and I mean very often—banks hold incoming funds for their own account for one or more days before applying them to end-user accounts. This float can be governed by local banking regulations, receiving bank policy, or simple workload delays. It can be a source of significant income for the receiving bank when aggregated over all deposits and lengthy accounting periods. Even if, in your example, your payment is deposited in the supplier’s account on February 3, that might not occur until the overnight shift, long after the close of business. So rather than “facilitating better coordination,” it could easily become the source of contention. The clearance date reflects “real-time” banking details only for your bank’s leg of the transaction.
Actually not. I am talking about remittances where this date is also the time (date & time) when the supplier will see the amount to its account. There are 3 main choices through internet banking services to select the payee to receive the money through remittance a) instantly (in a few seconds) b) the next day (for payments before cut-off time) and c) in two days (for payments after cut-off time).
In these cases, we have as a cleared date the same for our bank as for our recipient (the details of these dates are provided with the payment confirmation we receive just after we complete the remittance through internet banking).
Yes, but through the choices I presented above, banks also provide alternative solutions (of course, with bank charges for each one) to have specific date for our suppliers to receive their money (and reduce the “valeur” of bank transfers).
Well, all I can say is that over the many years I have moderated this forum, no one else among Manager’s many thousands of users has ever requested such a feature. If received payment is a condition for shipping goods, I cannot conceive of a supplier accepting your word that money was deposited into their account. The supplier would check to confirm. In my opinion this would just be software bloat.
Of course, a supplier will not be based on my “word” (email), in any case it will confirm the payment through its bank account. But with the feature I requested, suppliers can see our email with this information and be aware of when they expect to receive a payment (so that they confirm it).
Anyway, if it is considered a “bloat”, fair enough.
If its that important why not record such information through custom field?
This could be a solution, but I was seeking to use the (existing) data of Cleared Date field without adding new fields (avoiding the need to enter this date again).
Yes ,you just have to put this information twice but thats the only downside. You can also change your custom field name to something like Expected Clearing which makes more sense in your case.
The best way is to ask @lubos to expose more data sources fields for Custom theme so we can display more information in the document view.
Actually we can access API2 to get the information we need in the document view.
Maybe the code below can give us an idea
......
<td style="text-align: end; vertical-align: top">
{% for field in fields %}
<div style="font-weight: bold">{{ field.label }}</div>
<div style="margin-bottom: 10px">{{ field.text }}</div>
{% endfor %}
<div id="bankClearedLabel" style="font-weight: bold">Cleared Date</div>
<div id="bankClearedDate" style="margin-bottom: 10px"></div>
</td>
......
.....
</table>
<script>
// Get the value of 'Reference' from your template
const referenceValue = '{{ fields["Reference"] }}';
const recipientName = '{{ recipient.name }}';
// Construct the URL with the dynamic term
const apiUrl = `https://{{Subdomain}}.manager.io/api2/payments?term=${referenceValue}&fields=Cleared&fields=Payee`;
fetch(apiUrl, {
method: 'GET',
headers: {
'Accept': 'application/json',
'X-API-KEY': 'AccessToken'
}
}).then(response => response.json()).then(data => {
// Check if the 'payments' array exists in the response
if (data && data.payments && Array.isArray(data.payments) && data.payments.length > 0) {
// Find the payment with the matching customer value
const matchingPayment = data.payments.find(payment => payment.payee === recipientName);
if (matchingPayment) {
// If a matching payment is found, get its 'cleared' value
const clearedValue = matchingPayment.cleared;
// Parse the clearedValue date string
const clearedDate = new Date(clearedValue);
// Format the clearedDate in the same format as fields["Date"]
const formattedClearedDate = clearedDate.toLocaleDateString('en-US', {
year: 'numeric',
month: '2-digit',
day: '2-digit'
});
// Update the content of the <div> element with the formatted cleared date
const bankClearedDateElement = document.getElementById('bankClearedDate');
const bankClearedLabelElement = document.getElementById('bankClearedLabel');
if (formattedClearedDate !== 'Invalid Date') {
bankClearedDateElement.textContent = formattedClearedDate;
} else {
bankClearedDateElement.style.display = 'none'; // Hide BankClearedDate element
bankClearedLabelElement.style.display = 'none'; // Hide BankClearedLabel element
}
} else {
console.error('Error: No payment found for the customer');
}
} else {
console.error('Error: Payments data not found or is not in the expected format');
}
}).catch(error => {
console.error('Error fetching data:', error);
});
</script>
Notes.
Reference Number + Customer Name In the document must be unique to get the correct data from API2.
I hope that in the future, the Term parameter in Api2 can handle dynamic expressions to make data search easier
@Mabaega great, great work!
Thank you very much for sharing such an exceptional solution!
Very much appreciated!!
Update Sample Code.
Api2 Term working with contains operators.
If there is an invoice from the same supplier and a reference with a similar number, the script will take the Cleared Date from first payment.
I added a reference number test so the script can display Cleared Date data from the actual invoice.
......
<td style="text-align: end; vertical-align: top">
{% for field in fields %}
<div style="font-weight: bold">{{ field.label }}</div>
<div style="margin-bottom: 10px">{{ field.text }}</div>
{% endfor %}
<div id="bankClearedLabel" style="font-weight: bold; display:none">Cleared Date</div>
<div id="bankClearedDate" style="margin-bottom: 10px; display:none"></div>
</td>
......
......
</table>
<script>
// Get the value of 'Reference' from your template
const referenceValue = '{{ fields["Reference"] }}';
const recipientName = '{{ recipient.name }}';
// Construct the URL with the dynamic term
const apiUrl = `https://{{subdomain}}.manager.io/api2/payments?term=${referenceValue}&fields=Cleared&fields=Reference&fields=Payee`;
fetch(apiUrl, {
method: 'GET',
headers: {
'Accept': 'application/json',
'X-API-KEY': 'AccessToken'
}
}).then(response => response.json()).then(data => {
// Check if the 'payments' array exists in the response
if (data && data.payments && Array.isArray(data.payments) && data.payments.length > 0) {
// Find the payment with the matching customer value and reference value
const matchingPayment = data.payments.find(payment => payment.payee === recipientName && payment.reference === referenceValue);
if (matchingPayment) {
// If a matching payment is found, get its 'cleared' value
const clearedValue = matchingPayment.cleared;
// Parse the clearedValue date string
const clearedDate = new Date(clearedValue);
// Format the clearedDate in the same format as fields["Date"]
const formattedClearedDate = clearedDate.toLocaleDateString('en-US', {
year: 'numeric',
month: '2-digit',
day: '2-digit'
});
// Update the content of the <div> element with the formatted cleared date
const bankClearedDateElement = document.getElementById('bankClearedDate');
const bankClearedLabelElement = document.getElementById('bankClearedLabel');
if (formattedClearedDate !== 'Invalid Date') {
bankClearedDateElement.textContent = formattedClearedDate;
bankClearedDateElement.style.display = 'block'; // Show BankClearedDate element
bankClearedLabelElement.style.display = 'block'; // Show BankClearedLabel element
}
} else {
console.error('Error: No payment found for the customer');
}
} else {
console.error('Error: Payments data not found or is not in the expected format');
}
}).catch(error => {
console.error('Error fetching data:', error);
});
</script>