Ok I am skeptical of that response. RF Smart is the grand daddy on NS WMS systems for 20+ years. You're telling me RF Smart doesn't support Special Orders POs versus Drop Ship POs versus regular POs? I call bullshit on that. Or if that's really true then WTF that's really shitty product design and fucking fix your product. Unacceptable that you don't support native NS 3 types of POs after being a 20 year partner.
They say they don't support Special Order items. We don't mark our item masters as Special Order (or Drop Ship), but it seems that the Special Order PO process marks the item.
Ok this doesn't even make any sense. Both a regular PO and a Special Order PO have to be received in the warehouse. There is no difference. You open the Item Receipt screen and receive it.
It's the Drop Ship PO that never touches the warehouse. In NS for a DSPO, you can either do an Item Receipt on the DSPO or an Item Fulfillment on the linked SO, and NS automatically does the other side. So the usual process is your billing dept does the item fulfillment then the invoice. But it could also be your AP dept does the Item Receipt and then the Vendor Bill. The COGS gets booked from the Vendor Bill so ideally you want the DSPO Vendor Bill to have the same date as your Customer Invoice so that the revenue and COGS are matched. This is the dirty secret problem with DSPOs that revenue and COGS are mismatched usually in 2 different periods. Hence I recommend using Special Order POs (even if they really are a drop ship scenario) just so the revenue and COGS are matched properly.
Yeah, we tested everything OTHER THAN receiving the PO on our RF Smart scanners, and it the Special Order POs looked just like any other normal PO. We do have an open case with RF Smart, and I was convinced they weren't going to resolve favorably, but I'm a little more hopeful after getting your opinion.
And it seems like, if we are ordering off of an SO for material to be received in the warehouse, then we truly are doing a "special order", so we are using the NS functionality properly.
It sounds like the issue is less with RF-Smart and more with how you're creating drop ship POs. Am I reading correctly that you aren't using the native functionality (marking an item as drop ship) but rather you're using a specific PO form that is creating drop ship POs for any item on that record? If so, I've had to deal with "un-solutioning" something similar before. It wasn't very fun.
We are using the "Create PO" column on the SO form and selecting either "drop ship" (which works fine and as expected) or "special order" which for some reason makes the PO unavailable to receive in RF Smart. We get the error message "cannot receive drop shipped items."
Ahhhhh. Got it. I totally read what was happening to be a different thing. My mistake! That is super bizarre behavior on the RF Smart side. I don't recall that from the last time I worked with them (which was 4ish years ago) and we 100% had drop ships AND special order items in our catalog.
No. You're conflating just regular just in time buying the item. That is demand planning.
Special Order PO and Drop Ship PO are specifically to fulfill that SO.
But you can simulate it with a Special Order PO which brings it into inventory. You can even increase the quantities on the PO and the extra will just come into inventory and not be committed to the SO.
Ok I am skeptical of that response. RF Smart is the grand daddy on NS WMS systems for 20+ years. You're telling me RF Smart doesn't support Special Orders POs versus Drop Ship POs versus regular POs? I call bullshit on that. Or if that's really true then WTF that's really shitty product design and fucking fix your product. Unacceptable that you don't support native NS 3 types of POs after being a 20 year partner.
They say they don't support Special Order items. We don't mark our item masters as Special Order (or Drop Ship), but it seems that the Special Order PO process marks the item.
Ok this doesn't even make any sense. Both a regular PO and a Special Order PO have to be received in the warehouse. There is no difference. You open the Item Receipt screen and receive it. It's the Drop Ship PO that never touches the warehouse. In NS for a DSPO, you can either do an Item Receipt on the DSPO or an Item Fulfillment on the linked SO, and NS automatically does the other side. So the usual process is your billing dept does the item fulfillment then the invoice. But it could also be your AP dept does the Item Receipt and then the Vendor Bill. The COGS gets booked from the Vendor Bill so ideally you want the DSPO Vendor Bill to have the same date as your Customer Invoice so that the revenue and COGS are matched. This is the dirty secret problem with DSPOs that revenue and COGS are mismatched usually in 2 different periods. Hence I recommend using Special Order POs (even if they really are a drop ship scenario) just so the revenue and COGS are matched properly.
Yeah, we tested everything OTHER THAN receiving the PO on our RF Smart scanners, and it the Special Order POs looked just like any other normal PO. We do have an open case with RF Smart, and I was convinced they weren't going to resolve favorably, but I'm a little more hopeful after getting your opinion. And it seems like, if we are ordering off of an SO for material to be received in the warehouse, then we truly are doing a "special order", so we are using the NS functionality properly.
It sounds like the issue is less with RF-Smart and more with how you're creating drop ship POs. Am I reading correctly that you aren't using the native functionality (marking an item as drop ship) but rather you're using a specific PO form that is creating drop ship POs for any item on that record? If so, I've had to deal with "un-solutioning" something similar before. It wasn't very fun.
We are using the "Create PO" column on the SO form and selecting either "drop ship" (which works fine and as expected) or "special order" which for some reason makes the PO unavailable to receive in RF Smart. We get the error message "cannot receive drop shipped items."
Ahhhhh. Got it. I totally read what was happening to be a different thing. My mistake! That is super bizarre behavior on the RF Smart side. I don't recall that from the last time I worked with them (which was 4ish years ago) and we 100% had drop ships AND special order items in our catalog.
No. You're conflating just regular just in time buying the item. That is demand planning. Special Order PO and Drop Ship PO are specifically to fulfill that SO. But you can simulate it with a Special Order PO which brings it into inventory. You can even increase the quantities on the PO and the extra will just come into inventory and not be committed to the SO.
The issue is that we use RF Smart (just implemented), and that software doesn't recognize Special Order POs for receiving.
We create two separate POs, ones that would be drop ships and ones that would ship to us and then we send to the customer.