3-Way Match/Voucher Logging

DeniseDG

Active Member
Hello List Members

My company has been on JDE since the late 80's and has never implemented 3-way match. I'm in the process of trying to accomplish that now.

We are purely distribution company with 22 warehouses and centralized accounting. Currently all vendor invoices go to remote locations who approve & forward to acctg. for payment. Under 3-way match we will have all invoices going to accounting. I'm currently working on the dilemma of how to resolve variances that arise when matching invoices to received PO lines.

I thought possibly we could use the voucher logging process to put on 'HOLD' those invoices that don't match within tolerance. Does anyone know if it's possible to to use voucher logging process even when PO lines have already been received? JDE documentation talks only about using it when PO lines have not been received.

I guess I'm wondering if anyone in a similar situation might be willing to correspond with me off-line about how they handle the whole variance resolution issue. I'm not an A/P expert, and we don't really have an expert on this subject in our IT department either.

Thanks for any help,
Denise
VP-Business Processes
Ris Paper Company, Inc.
 
Hi Denise!

Voucher logging is more for the case where the vouchers are entered in one
area, but the matching (or re-distribution as it would be called under this
scenario) is done in another. An example of this may be centralized
accounts, where people get the invoices on the system (by logging) so they
are visible, but matching is done at the locations.....

There are a number of options available on the matching front (types 1-9 and
can be found in the manuals or under the online help), but if you could
illustrate where the variances are coming from then the list can best
advise.

Note an example may be that the variences are due to shipping charges, which
you pay, which may indicate the use of landed costs are required.

Best regards

Peter

Peter Bannister : [email protected]
1st Consulting Ltd : www.1stconsulting.biz
Mobile : +44-(0)7711-649358
Fax : +44-(0)7739-256227
E-mail on the move : [email protected]




Product Specialist
 
Re: RE: 3-Way Match/Voucher Logging

Peter, thank you for your response.

Our situation would be that PO's are received into the system in remote locations, but invoices would be sent to and vouchers created in central accounting department.

My question is, if when accounting is attempting to match an invoice to open receipt, the variance between invoice amount & extended amounts on detail lines is above tolerance, could we then back out of the match program without creating a voucher; instead go into voucher logging and create a logged voucher...then we would communicate w/field offices, the problem invoices. They would have to un-receive the PO and correct what-ever problem is causing the variance (most likely incorrect unit cost on PO) and then re-received the corrected detail lines. I thought then that accounting could re-distribute the logged voucher (PO), but when I test this, I can't seem to get the JE to clear the suspense account and post to A/P. I'm wondering if it's simply that Voucher Logging/Redistribute PO will not work if PO detail lines have already been received, will it only work if PO detail lines have not yet been received?

I'm trying to find some way to keep track of invoices that are outside of tolerance when trying to match to detail received PO lines. Our invoice volume is so high, I'm afraid if we use a soft error instead of a hard error, the number of transactions posted to the variance accounts and the tracking of how they are resolved and reconciled will be a major nightmare.
 
Re: RE: 3-Way Match/Voucher Logging

Hi Denise

I feel you realy need to look at the business process of 'Procure to Pay'. If there are too many variances between your purchase order and invoices raised from the vendor then there is something wrong outside the system nothing to do with JDE. Even if you are in a volatile market where the cost of procured item changes very quickly, the agreed price is the purchase order price. If vendor is invoicing you in a different price from the price mentioned on the Purchase order then you need to pull up the vendor. If the prices are being changed after taking the lengthy route of reversing the reciept etc, then the buyers are making some errors.

I know some companies who have got rid of this invoice matching itself. They pay their vendors as per the purchase order on the due date and they have even asked their vendors not to send their invoices. This reduces manpower to a great extent in your A/P department. I do not know the legal implications in this but this could be achieved.
 
RE: RE: 3-Way Match/Voucher Logging

Thank you for your response.
You are entirely correct of course; the types of errors I expect to
encounter are almost entirely due to what can only be called 'laziness' on
the part of the buyers, in not making sure that the cost on their PO is the
actual cost we will pay. They have a habit of just letting that PO cost
default. We are in somewhat of a "commodity" business (we distribute fine
paper) and costs tend to stay static for periods of time. The truth is,
until we actually implement the three-way match on the system, we don't
really have any idea how many variances we'll encounter. I may be
(hopefully) over-reacting in advance. My feeling is that, upon initial
implementation, if we force, as you aptly referred to it: "the lengthy route
of reversing the receipt etc", the buyers will quickly learn the importance
of making sure their PO cost is correct at initial entry.

Looking to the future; if our variances are not a big issue, your suggestion
of eliminating the processing of invoices entirely is very enticing.

Thanks Again



World 7.3 Cum 10
 
RE: RE: 3-Way Match/Voucher Logging

Denise,
You can set up tolerance on the voucher match process as well. There
is a processing option on the Voucher Match program (P4314) that indicates
what to do about tolerance checking. We have that processing option set to
put our vouchers to Pay Status "V" if exceed tolerance. That puts the
voucher (F0411) record on hold status, in effect, until the tolerance is
resolved and the pay status code reset to open to pay. That way the invoice
gets into the system, but won't be paid until resolved. Hope this helps a
little bit.

John Dickey
JDE Financial Systems
Administrator/Programmer/Analyst
White-Rodgers, Division of Emerson
St. Louis, MO
314-577-1466
 
Voucher Logging....don't do it. It's potentially a huge disaster as you are
now logging (i.e. "dumping") $$$ into an account where it's a hodge-podge of
"stuff" (balance sheet items, capital items, overhead expenses, selling
expenses, whatever all lumped into one uncontrolled account). Put invoices
that should be processed with a 3-way match but for some reason can't be
processed into a problem file. Then, working with your Purchasing and
Receiving dept., fix them one-by-one (i.e., so that you can then enter them
properly with a 3-way match). Also, fix and continuously enhance the
business processes that resulted in these problems being created in the
first place (problems could be the requisitioner, could by Purchasing, could
be the Vendor, could be Receiving). Do not do voucher logging. You will
create an account balance that is completely out-of-control, and, if it's a
balance sheet account, it will absolutely result in an audit comment if it's
anything approaching a "material" amount!

In a very controlled way for specific vendors (high volume, frequent receipt
production parts where we have firm PO prices and robust receiving processes
reducing likelihood of errors and where errors are promptly identified to
both our planning dept and our vendor's customer service depatment), we have
implemented Evaluated Receipts processing (voucher automagically upon
receipt). This works great with tremendous accuracy and big reduction in
A/P effort. But getting the surrounding business processes (here and at our
vendors) robust enough to permit this to happen reliably was a struggle and
even involved implementing an external to JDE Supply Chain Management
solution.

...Gerry



World 7.3, Cum 10
Moving to XE, AS/400, Coexistence, HTML
 
Craig....comments about E.R.S. and JDE

--We are primarily on World.
--We are an automotive, repetitive manufacturer, few suppliers, high volume
--Our release process was based on Excel spreadsheets fax'd to Suppliers
--Implemented JDE shop floor and MRP
--Purchased a web-based SCM solution called Supplyworks
(www.supplyworks.com). User needs only Internet Explorer 5.5 or higher (and
a fast PC with good Internet connection).
--Supplyworks customized their application greatly (& quickly) to meet our
needs
--Part information for vendors using Supplyworks comes from JDE PDM via
integration (Supplyworks built integration). New parts are recognized and
sent up to Supplyworks.
--Blanket POs are set up in Supplyworks (not JDE blankets) by our Purchasing
Dept. Individual Blanket POs are set up for each part due to special
requirements for each part. Includes max quantity, price, payment terms and
Evaluated Receipts flag.
--Via integration (Supplyworks built) Supplyworks take a feed from our MRP
output and creates Supplier Schedules which can be manually adjusted before
posting.
--Suppliers indicate when they plan to ship
--Our planners and our suppliers Customer Service view same screen showing
our demand and Suppliers planned shipments. Lots of info on this
screen....amazing. Lots of collaboration tools provided. Alerts
automatically created and sent when vendor indicates they cannot meet our
demand.
--From same screen, suppliers shipping department can indicate that they are
shipping (we call it an ASN), the parts, the quantities (default in from
plan but can be changed), the number of boxes and the number in each box,
and their "packing list number" (hopefully this is the same as the invoice
number in their system or is some type of number that their A/R department
can use because this number becomes the Invoice Number on the voucher
created by E.R.S.). The Supplier's Shipping department prints out a
shipment summary that includes a Bar Code and includes this paper with the
shipment. PO status is Shipped.
--Supplyworks electronically sends us the ASN, integration creates standard
JDE POs (Doc type "OZ" to separate them from standard "OPs") containing part
and quantity info from ASN, supplier info, payment terms, and pricing from
Supplyworks Blanket PO. Single shipment creates multiple POs. POs exactly
match what the supplier says they ship.
--Supplyworks integration also updates a tentative receiving file (our
design) containing a unique bar code for that shipment, and all the
information need to complete JDE receiving including the packing list
number.
--When Shipment arrives, Receiving scans bar code on the printout that comes
with the shipment. Using SST functionality (SST is software that can take
data and complete JDE data entry forms) this then completes all receipts for
all POs on the shipment and puts the Supplier "packing list number" entered
above into the Supplier Remarks field in the F43121 receiving file.
--If shipment doesn't arrive and we don't process within a day of expected
delivery, an automatic alert is created by Supplyworks and sent to our
Planning and Suplier's Customer Service. It has been know to happen that
shipping paperwork doesn't get processed. (THIS IS IMPORTANT TO INSURE THE
VENDOR GETS PAID FOR ITEMS SHIPPED!)
--Integration back to Supplyworks from JDE receiving changes PO Status to
Received.
--E.R.S. runs automatically at night, processing options look for receipts
from selected vendors with Evaluated Receipts flag set to "Y" and Invoice
Logging Field set to "P". E.R.S. wants to create a voucher for each P.O.
Our clever RPQ programmer figured out that the JDE P43800 program would
group POs on a single voucher if a "P" was put into the Invoice Logging
Field in the F43121 so before P43800 fires off we have a little program with
the same processing options as P43800 which puts a "P" in the Invoice
Logging Field. When E.R.S. runs a single voucher is created for the
multiple POs that usually are part of any shipment from our vendors. One
Shipment, one packing list number, multiple parts, multiple POs, one
voucher.
--A/P prints out vouchers (using an AS/400 query) and files.
--Checks are created based on payment terms. The amounts by invoice on the
check stub are really amounts by packing list number. This has not caused
any major problems with our vendors, but for some (where the packing list
number is not the invoice number) they have had to develop some special
processes.
--Quality Department verifies quantities and quality after shipment. If
returns are necessary or parts are bad or quantities are wrong, Quality
works with Supplier. Supplier sends "negative ASN" through Supplyworks that
is then processed just like a regular E.R.S. Negative receipts are
processed in E.R.S. just like positive ones. Quality initiates a paper
process (VDMRs-Vendor Defective Material Report) which can include
additional charges if necessary. These charges are manual credits entered
using Standard Voucher Entry.


Glitches:
--Additional freight, or material surcharges, or box charges or whatever
can't be added by the vendor but must be included in the piece price or
charged monthly via a separate invoice.
--Supplyworks does not currently handle multiple currencies, but it will be
in the next release (we will be going live with a Canadian company that
needs this feature fairly soon).
--Vendors must support this. They have to have powerful PCs (lots of Java
applet processing on local boxes) and fast internet connections. Their
Customer Service, Shipping and to some extent their A/R departments must
learn how to use the system.
--Supplyworks is slow to repaint the screen, but they are working on
improving speed (more server side processing and less transfer of data &
local processing).
--Integration is tricky to set up. Requires some local expertise and
separate integration server (what's another server).
--Planning added Suppliers to Supplyworks and did not tell me (controller of
JDE processing options) or A/P. Good communication is necessary....duh.
--I only see this working for our "good" vendors who ship regularly. For
suppliers who send us lots of small quantity MRO items where items are added
all the time and pricing changes frequently, I don't see this as a solution.



World 7.3, Cum 10
Moving to XE, AS/400, Coexistence, HTML
 
Back
Top