POLL: Vendor Inv# @ PO Receive

[timbre4]

This is a programming question I posed the other day. Polling of how you actually use it will help shape the response.

NOTE: There is no committment yet to make this a reality, but I would like to get it on the table for internal discussion.

When you order parts, you don't know what the vendor invoice is (unless the vendor tells you over the phone?). Later you are tasked with entering the vendor invoice # into each Ref/Inv# field of the PO parts on various orders, if you want to get that data stored into history.

What if on the PO screen to receive PO parts that just arrived, you could enter the vendor invoice as shown below and then it would fill all of the Ref/Inv# part fields when you finished receiving?

This creates a question; should the PO entry data always REPLACE any user entered data in the part item edit Ref/Inv#? Please choose the option that best describes how you use it and what you'd like to see in this regard. Thanks

[fortknoxx]

i don't use po's, but i use the inv# in that field

haha I'm first!

[Chris W.]

Here is a program question, What if you only rec one part from your PO at a time and the second part comes in on a new vender invoice# we are back to where you were manual enter twice.
But what if you move that data entry to the Receive and the Receive All button?
If you use the RO# in the system it sticks to the PO.
just a thought.

[ricmorin]

We manually enter the invoice number on the PO. IT WOULD BE AWESOME TO HAVE THE SAME FIELD AUTO-POPULATE ON THE PART RECORD.

[Pauls Automotive]

We manually enter all our vendor invoice numbers into that field so having that automated would be a wonderful thing.

[timbre4]

What if you only rec one part from your PO at a time and the second part comes in on a new vender invoice# we are back to where you were manual enter twice.

So a back-ordered item doesn't reference the same inv # and later shows up with a new one? Is that accounted for on the vendor side? (ie cancel the BO off 1234 and now ship it on 6789, delete the BO ref from 1234 as now fulfilled by 6789)

But what if you move that data entry to the Receive and the Receive All button?

ISSUES
Requires third Receive checkbox, defaulted as checked to use the master vendor inv #, unchecked to enter a diff vendor invoice #?
Would require an input box to feed down to that part on the order
Storing and displaying more than one invoice #

If you use the RO# in the system it sticks to the PO.

Eh?

[Chris W.]

So a back-ordered item doesn't reference the same inv # and later shows up with a new one? Is that accounted for on the vendor side? (ie cancel the BO off 1234 and now ship it on 6789, delete the BO ref from 1234 as now fulfilled by 6789)

Correct part shipped with new vender invoice#

But what if you move that data entry to the Receive and the Receive All button?

ISSUES
Requires third Receive checkbox, defaulted as checked to use the master vendor inv #, unchecked to enter a diff vendor invoice #?
Would require an input box to feed down to that part on the order
Storing and displaying more than one invoice #

What if you feed the SQL by placeing the field as below. So if you rec one part or the whole PO the field would be placed on the RO parts field.

po3s.png (132.55 KiB) Viewed 15972 times

[timbre4]

I think we're on the same page for the most part. My concerns are:

Storing more than one Vendor invoice # [additional field(s) reqd in db]
Displaying more than one Vendor invoice # [additional field(s) reqd in PO screen?]
How/where to control writing exceptions

I'm thinking the way to manage this is to:

1. Use the Ref/Inv # field in the existing location (nearly all the time)
2. Then also display that vendor # in the Receive window (dimmed and checked)
3. Unchecking the box allows overwriting with diff # (to be stored along with the original vendor # that applies to other parts)

po3x.png (134.89 KiB) Viewed 15961 times

[Chris W.]

I think we're on the same page for the most part. My concerns are:

Yes we are
You wouldn't be storing any new data just a new data entry field for an existing information at the parts record level
I't just looks like an added step with the check box. When if you don't revc the part on that venders invoice the # is going to change when he bills it out on your next parts run.

[timbre4]

This is what I see:

1. Receive All PO parts process (5 parts)
2. Enter the Vendor inv # on main screen, noting 4th item is BO
3. 1st part OK
4. 2nd part OK
5. 3rd part OK
6. 4th part enter Q in BO, uncheck box to blank out (disassociate) vendor inv #
7. 5th part OK

PO remains open with original vendor inv # entered, stored and transmitted down to appropriate order part lines

8. BO part arrives and return to PO screen; highlight 4th part line
9. Receive part and now enter the new vendor inv # and close PO

I am storing more than one vendor invoice in this scenario and the current design reflects using one; so the rules for the Ref/Inf# field are changed to accomodate more than one entry.

I'd also like to see Ref/Inv# added to PO Search screen so have to be aware of how future search results would work with more that a single vendor invoice # stuffed into that field. (make it loose like Tire Package Description field I guess)

[Chris W.]

Looks like a plan push it to the top.

[timbre4]

I'm going to try, need to see some more votes on this.

[Pauls Automotive]

I can tell you I like what you have come up with. Makes a lot of sense and would seem to work well if the programmers can make it happen.

[steven kiser]

off the point but still on the subject. how do you group delete all the po's. i thought of using the po option but seeing as i'm a bit mmmmmmm o.c.d.ish or just a virgo i feel the need to start from scratch.

[timbre4]

There is no mass delete function; it's a dangerous proposition. Wally, you clicked what?!

POs are designed to go through the Receive All process and then they're closed as part of that process.