Our ERPAG app is officially available in all major app stores.

Now you can easily install ERPAG on your selected mobile device.
Apple App store, Google Play, Huawei App Gallery – whichever platform you use, we got you covered!

Introduction

A “reference number” is used to facilitate the tracking of trade payables. In theory, you should have a unique number provided by the supplier. Erpag uses that number to link debts (e.g. liabilities to the supplier) and deleverages (e.g. payments to the supplier). That way we know which invoice is paid, which is not paid, and whether it is overpaid or less paid. In combination with terms of payment (i.e. due date), we can know when we need to pay an obligation or when we have failed to pay it. But that’s another topic, in this blog, we will focus on payment statuses.

As always, a theory is one thing, real life is another. The reference number should be unique in the information system. But, often for suppliers, the reference number is essentially a customer account number. In this case, all invoices from the supplier have the same reference number. Also, when you are splitting documents, the reference number is automatically transferred to the split document, so you have the same reference number in that case as well.

Monitoring in these cases can be complicated but as always ERPAG has a solution. Our solution is to close the obligations (e.g. payment) from the oldest created document to the youngest.

To make this simpler, we will do some examples.


Logical control

We will enter two Purchase Orders with the same supplier and the same reference number, of course.

We will receive the goods on those purchase orders and make a supplier invoice. After that, the documents will have an “unpaid” status.

If by any chance, we activated the option of registering a payment in PO-000017, which is a younger document in time, the logical control will not allow such a record.

Instead, the system will suggest that we open the oldest unpaid document in a new tab. If in reality a payment of $ 2,500 was made and we want to record it, and since the supplier provides us with the same reference number, we assume that their records are cumulative for the entire reference and they probably do not care which specific purchase order they refer to. There are two solutions, one is to record up to $ 1,000 separately on the PO-000016 and then record the remaining $ 1,500 on PO-000017 or, the other solution would be to enter $ 2,500 in PO-000016.

Note: We inserted the logical control in the bulk payment action but not in the manual journal voucher or when recording payment via “Outstanding Pay-Outs”.


Recording payments greater than the amount of the purchase order

If you enter a higher amount than the purchase order amount in the oldest document, ERPAG will allocate the remaining amount to the next unpaid document.

This means that we do not have to split the payment record.

If the amount were higher than all unpaid bills (in our example we will enter $ 4000), then the youngest, most recently created document, will have the status “overpaid”.

If the next document from the same supplier has the same reference number, when the supplier invoice is made, ERPAG will automatically transfer the “overpaid” amount to that next, new document.

Note: If we do not have more than one supplier invoice with the same reference number, then you can refund or use deposits for an “overpaid” document.

You can find more information about deposits on our following blog: https://www.erpag.com/news/deposits-in-erpag


Splitting purchase order

If you need to split one purchase order into two (for example, we partially receive the quantity), the newly generated order will have the same reference number. You can change the transferred reference number (e.g. add a suffix) if you want to track them separately. If you keep it, the tracking will be identical as if the supplier provided us with identical reference numbers.


Return to supplier

Return to supplier, credit note and voiding of documents results in a reduction of the obligation to the supplier.

One common question is: “why is my status “Partially-paid” when I have not registered any payments, but have only made a customer return?

Payment is almost in 95% of cases reduction in liability as a type of transaction. As we mentioned, there are transactions that also reduce liabilities, one of which is the return to supplier. In that case, the goods are returned to the supplier and thus the obligation to pay is reduced. Theoretically, a “Return status” column could be added, but then a “Credit note status” and “Foreign exchange gain / loss”, “Late penalty” etc. columns should be added as well. This would unnecessarily complicate the entire design of the application. From the point of view of accounting, the correct name would be credit/debit, but the average operator is not very clear on what “credit” means to the supplier and what “debit” means to the customer. As mentioned, in most cases, those transactions are payments so for simplicity and association we chose that term.


Internal accounting

ERPAG has an internal accounting system. The way that Erpag presents the data in the accounting and in the operational part of the system is often different. For example, in accounting, transactions are arranged chronologically, while in the operative part they are broken down by documents.

You can see a quick insight into accounting transactions by reference number by clicking on the info icon of the “reference number”. If the icon does not exist then there are no corresponding transactions in the accounting.

You can find the complete report in the accounting part of ERPAG.

By selecting the parameters, you can narrow the selection according to the corresponding reference number.

Note: For official accounting, please use the integration with QuickBooks Online or XERO.

( https://www.erpag.com/news/quickbooks-online-and-erpag-manufacturing , https://www.erpag.com/news/xero-erpag-integration )

Read More

Related Posts

Change log 05/29/2023

Change log 05/29/2023

The biggest change we developed is Automatization and Customization. This change is a huge milestone for us, and we will publish individual instructions for using the new features in the upcoming period. This module is divided into individual wholes: JSON Designer -...

read more
#SLACK API – step by step integration instructions

#SLACK API – step by step integration instructions

ERPAG has the ability to use Blockly Script to send or receive data via the HTTP protocol. Integration of two systems via API (Application Programming Interface) is always a complex process, especially for someone with little experience. In this blog we will explain a...

read more
ERPAG Change Log 11/30/2022

ERPAG Change Log 11/30/2022

Let's wrap up November with some more changes: Validation values (Quantity and Price) - will forbid you to process any documents that have values above the given limits. This option is used to decrease the number of unwanted errors during document processing....

read more