Maximo List Archive

This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.



change order with items received

From: Travis Herron (2011-10-21 19:51)

Maximo 6.2.6, weblogic, sql server
You send out a PO. The vendor sends more than you ordered. You decide to accept them. How do you handle that in Maximo? You enter it in Receiving, it warns you that you are receiving more than was ordered, but it lets you receive it. Now what?
I'm trying to make a Workflow to handle it. Normally, in our manual, paper-driven process, we'd hand the invoice to the person that ordered the item and ask him to sign the invoice. However, there are instances where the accountants are picky and the PO must exactly match the Invoice. For these, we normally make a change order.
Maximo won't let you make a change order if items have been received.
So, what do you all do? Just need some guidance, some opinions on best practices -- answers do not have to be limited to within Maximo.
Travis Herron


From: Shannon Rotz (2011-10-24 14:18)

I haven't got an optimal solution either, other than upgrading to V7.5,
which has new Receipt tolerance functionality. Otherwise: as far as I
know, the only way to stop it from happening would be in Java.

One client has a report sent to the Finance Manager every month, with a list
of the over-receipts. The others are just living with it .

One of my ideas is an escalation, which automatically sends out a
notification if someone over-receives.

But I agree - it's not optimal to notify afterwards, as opposed to
preventing it from happening to begin with.



Shannon

From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
Travis Herron
Sent: October-21-11 12:52 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] change order with items received


Maximo 6.2.6, weblogic, sql server
You send out a PO. The vendor sends more than you ordered. You decide to
accept them. How do you handle that in Maximo? You enter it in Receiving, it
warns you that you are receiving more than was ordered, but it lets you
receive it. Now what?
I'm trying to make a Workflow to handle it. Normally, in our manual,
paper-driven process, we'd hand the invoice to the person that ordered the
item and ask him to sign the invoice. However, there are instances where the
accountants are picky and the PO must exactly match the Invoice. For these,
we normally make a change order.
Maximo won't let you make a change order if items have been received.
So, what do you all do? Just need some guidance, some opinions on best
practices -- answers do not have to be limited to within Maximo.
Travis Herron


From: Gideon Olivar (2011-10-24 15:57)

You are right, Maximo only prompts you but you can still receive more than ordered anyway. In this scenario, since change PO is not possible anymore, you create a Credit invoice. This is how we address this kind of scenario in our set up. Thinking this will give yo some idea.
regards
________________________________
From: Shannon Rotz <shannonrotz@yahoo.ca>
To: MAXIMO@yahoogroups.com
Sent: Tuesday, 25 October 2011 8:18 AM
Subject: RE: [MAXIMO List] change order with items received
 
I haven't got an optimal solution either, other than upgrading to V7.5,
which has new Receipt tolerance functionality. Otherwise: as far as I
know, the only way to stop it from happening would be in Java.
One client has a report sent to the Finance Manager every month, with a list
of the over-receipts. The others are just living with it .
One of my ideas is an escalation, which automatically sends out a
notification if someone over-receives.
But I agree - it's not optimal to notify afterwards, as opposed to
preventing it from happening to begin with.
Shannon
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
Travis Herron
Sent: October-21-11 12:52 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] change order with items received
Maximo 6.2.6, weblogic, sql server
You send out a PO. The vendor sends more than you ordered. You decide to
accept them. How do you handle that in Maximo? You enter it in Receiving, it
warns you that you are receiving more than was ordered, but it lets you
receive it. Now what?
I'm trying to make a Workflow to handle it. Normally, in our manual,
paper-driven process, we'd hand the invoice to the person that ordered the
item and ask him to sign the invoice. However, there are instances where the
accountants are picky and the PO must exactly match the Invoice. For these,
we normally make a change order.
Maximo won't let you make a change order if items have been received.
So, what do you all do? Just need some guidance, some opinions on best
practices -- answers do not have to be limited to within Maximo.
Travis Herron


From: Travis Herron (2011-10-25 13:03)

Interesting. . .so I guess in 7.5 it could actually stop you from over-receiving.
That's not the concern I have in this particular instance. In this scenario, we're okay with having over-received it. It's just I have a requirement to make the PO match. Maximo is designed to allow the over-receipt and then the invoice is where all the "fixing up" of the prices and quantities happen. I'll ALSO need to be able to go backwards and produce a matching PO.
All I can figure out, and what IBM support is suggesting, is to go back and change the original PO to WAPPR status, make the changes, then re-approve it.
I think what I'll end up doing is teach people that when they want to do a change order, we'll take the existing PO number, duplicate the PO, and tack a ".01" at the end of the PO number. We'll pretend it's a change order that way.
FWIW, I think I now understand why they did what they did. . .
Assuming the Change Order is a complete re-do of the original PO (not just containing the changes, but containing the entire PO with the changes), the receipts from the original PO would have to be moved from the original to the Change Order. And the Change Order would be WAPPR so you can't have receipts against that. . .Then the change you're making could somehow negate the receipt (like you ordered WidgetX, received it, sent it back because you don't like it after all, then make a "change order" to order WidgetY, it wouldn't make sense to have a receipt for WidgetX on your change order because WidgetX wasn't on that order).
Travis Herron
--- In MAXIMO@yahoogroups.com, "Shannon Rotz" <shannonrotz@...> wrote:
>
> I haven't got an optimal solution either, other than upgrading to V7.5,
> which has new Receipt tolerance functionality. Otherwise: as far as I
> know, the only way to stop it from happening would be in Java.
>
>
>
> One client has a report sent to the Finance Manager every month, with a list
> of the over-receipts. The others are just living with it .
>
>
>
> One of my ideas is an escalation, which automatically sends out a
> notification if someone over-receives.
>
>
>
> But I agree - it's not optimal to notify afterwards, as opposed to
> preventing it from happening to begin with.
>
>
>
>
>
>
>
> Shannon
>
>
>
> From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
> Travis Herron
> Sent: October-21-11 12:52 PM
> To: MAXIMO@yahoogroups.com
> Subject: [MAXIMO List] change order with items received
>
>
>
>
>
> Maximo 6.2.6, weblogic, sql server
>
> You send out a PO. The vendor sends more than you ordered. You decide to
> accept them. How do you handle that in Maximo? You enter it in Receiving, it
> warns you that you are receiving more than was ordered, but it lets you
> receive it. Now what?
>
> I'm trying to make a Workflow to handle it. Normally, in our manual,
> paper-driven process, we'd hand the invoice to the person that ordered the
> item and ask him to sign the invoice. However, there are instances where the
> accountants are picky and the PO must exactly match the Invoice. For these,
> we normally make a change order.
>
> Maximo won't let you make a change order if items have been received.
>
> So, what do you all do? Just need some guidance, some opinions on best
> practices -- answers do not have to be limited to within Maximo.
>
> Travis Herron
>
>
>
>
>
>
>


From: in2data (2011-10-25 15:40)

Hi,
We have them put the PO in WAPPR and make the changes and then receive the extra items. Internal audit wants the PO, receipts and invoices to always match.
We also have all of the purchasing related application tables like po, poline, matrectrans, invoice, invoiceline .... audited. The audit tables are crucial in cases where someone like accounting or internal audit have questions.
Dave Bone
--- In MAXIMO@yahoogroups.com, "Travis Herron" <therron@...> wrote:
>
> Interesting. . .so I guess in 7.5 it could actually stop you from over-receiving.
>
> That's not the concern I have in this particular instance. In this scenario, we're okay with having over-received it. It's just I have a requirement to make the PO match. Maximo is designed to allow the over-receipt and then the invoice is where all the "fixing up" of the prices and quantities happen. I'll ALSO need to be able to go backwards and produce a matching PO.
>
> All I can figure out, and what IBM support is suggesting, is to go back and change the original PO to WAPPR status, make the changes, then re-approve it.
>
> I think what I'll end up doing is teach people that when they want to do a change order, we'll take the existing PO number, duplicate the PO, and tack a ".01" at the end of the PO number. We'll pretend it's a change order that way.
>
> FWIW, I think I now understand why they did what they did. . .
>
> Assuming the Change Order is a complete re-do of the original PO (not just containing the changes, but containing the entire PO with the changes), the receipts from the original PO would have to be moved from the original to the Change Order. And the Change Order would be WAPPR so you can't have receipts against that. . .Then the change you're making could somehow negate the receipt (like you ordered WidgetX, received it, sent it back because you don't like it after all, then make a "change order" to order WidgetY, it wouldn't make sense to have a receipt for WidgetX on your change order because WidgetX wasn't on that order).
>
> Travis Herron
>
> --- In MAXIMO@yahoogroups.com, "Shannon Rotz" <shannonrotz@> wrote:
> >
> > I haven't got an optimal solution either, other than upgrading to V7.5,
> > which has new Receipt tolerance functionality. Otherwise: as far as I
> > know, the only way to stop it from happening would be in Java.
> >
> >
> >
> > One client has a report sent to the Finance Manager every month, with a list
> > of the over-receipts. The others are just living with it .
> >
> >
> >
> > One of my ideas is an escalation, which automatically sends out a
> > notification if someone over-receives.
> >
> >
> >
> > But I agree - it's not optimal to notify afterwards, as opposed to
> > preventing it from happening to begin with.
> >
> >
> >
> >
> >
> >
> >
> > Shannon
> >
> >
> >
> > From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
> > Travis Herron
> > Sent: October-21-11 12:52 PM
> > To: MAXIMO@yahoogroups.com
> > Subject: [MAXIMO List] change order with items received
> >
> >
> >
> >
> >
> > Maximo 6.2.6, weblogic, sql server
> >
> > You send out a PO. The vendor sends more than you ordered. You decide to
> > accept them. How do you handle that in Maximo? You enter it in Receiving, it
> > warns you that you are receiving more than was ordered, but it lets you
> > receive it. Now what?
> >
> > I'm trying to make a Workflow to handle it. Normally, in our manual,
> > paper-driven process, we'd hand the invoice to the person that ordered the
> > item and ask him to sign the invoice. However, there are instances where the
> > accountants are picky and the PO must exactly match the Invoice. For these,
> > we normally make a change order.
> >
> > Maximo won't let you make a change order if items have been received.
> >
> > So, what do you all do? Just need some guidance, some opinions on best
> > practices -- answers do not have to be limited to within Maximo.
> >
> > Travis Herron
> >
> >
> >
> >
> >
> >
> >
>