JobProd.ReceivedQty

Yahoo Archive
1
We have also found that if you receive it to a different warehouse under the Make to Stock tab, it will not decrease the WIP quantity.





From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Robert Brown
Sent: Thursday, May 30, 2013 10:23 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: JobProd.ReceivedQty





The defined demand link is to a sales order so that doesn't surprise me that it may baffle the BO methods behind the action in some way. (on 8.03.4xx we found that even receipts of make to stock jobs to a different whse other than the one defined in the demand link can cause odd records & resulting odd behavior of related apps & trackers).
For these make to order jobs, what happens to jobprod.shippedqty when you receive to stock (and the similar fields in jobpart)?
Are you actually generating a parttran record (MFG-STK type rather than MFG-CUS) - and is there anything odd about those records?
What happens to your linked order after you receive the job intended to fulfill it to stock (rather than ship it direct from job?) Do you then make a shipment from stock?
The answer may be to simply block stk receipt of make direct jobs (and force a change of demand link - manual or otherwise if you can code it - before you do the stock receipt).

Curious what you find as you work through the issue and resolve it.

We're still on 8.04.409a but Epicor ERP (9) is going to be in testing soon enough (likely at least .701).

Appreciate any shared info you may learn about this quirk.

Rob Brown
Versa Products

>________________________________
>From: robertbeaghan <robert.beaghan@... <mailto:robert.beaghan%40ecoreintl.com> >
>To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
>Sent: Thursday, May 30, 2013 2:37 PM
>Subject: [Vantage] Re: JobProd.ReceivedQty
>
>
>We are on E9.05.607b and have found that 'Make To Order' jobs that are received to inventory do not update JobProd.ReceivedQty.
>
>Bob Beaghan
>
>--- In mailto:vantage%40yahoogroups.com, brenda mohr <brenda@...> wrote:
>>
>> Under what circumstances would this field NOT be updated when we receive inventory to stock?
>>
>> Brenda
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>
>

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
2
Under what circumstances would this field NOT be updated when we receive inventory to stock?

Brenda



[Non-text portions of this message have been removed]
3
We are on E9.05.607b and have found that 'Make To Order' jobs that are received to inventory do not update JobProd.ReceivedQty.

Bob Beaghan

--- In vantage@yahoogroups.com, brenda mohr <brenda@...> wrote:
>
> Under what circumstances would this field NOT be updated when we receive inventory to stock?
>
> Brenda
>
>
>
> [Non-text portions of this message have been removed]
>
4
The defined demand link is to a sales order so that doesn't surprise me that it may baffle the BO methods behind the action in some way. (on 8.03.4xx we found that even receipts of make to stock jobs to a different whse other than the one defined in the demand link can cause odd records & resulting odd behavior of related apps & trackers).
For these make to order jobs, what happens to jobprod.shippedqty when you receive to stock (and the similar fields in jobpart)?
Are you actually generating a parttran record (MFG-STK type rather than MFG-CUS) - and is there anything odd about those records?
What happens to your linked order after you receive the job intended to fulfill it to stock (rather than ship it direct from job?) Do you then make a shipment from stock?
The answer may be to simply block stk receipt of make direct jobs (and force a change of demand link - manual or otherwise if you can code it - before you do the stock receipt).
Â
Curious what you find as you work through the issue and resolve it.
Â
We're still on 8.04.409a but Epicor ERP (9) is going to be in testing soon enough (likely at least .701).
Â
Appreciate any shared info you may learn about this quirk.
Â
Rob Brown
Versa Products


>________________________________
>From: robertbeaghan <robert.beaghan@...>
>To: vantage@yahoogroups.com
>Sent: Thursday, May 30, 2013 2:37 PM
>Subject: [Vantage] Re: JobProd.ReceivedQty
>
>Â
>We are on E9.05.607b and have found that 'Make To Order' jobs that are received to inventory do not update JobProd.ReceivedQty.
>
>Bob Beaghan
>
>--- In mailto:vantage%40yahoogroups.com, brenda mohr <brenda@...> wrote:
>>
>> Under what circumstances would this field NOT be updated when we receive inventory to stock?
>>
>> Brenda
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>
>

[Non-text portions of this message have been removed]
5
Could be anything (even one of your own customizations or BPMs - or an outright bug that is just so rarely conditionally triggered & perhaps influenced by what optional modules are licensed and active, that support may not be able to reproduce).
Â
We have (exceedingly rare) cases where parttran records are created (8.03.409a) with no sysdate.
Â
We have more frequent (but still rare considering the number of lines we ship process) where both stock shipments and shipments direct from jobs (for former) fail to relieve inventory, no parttran record created and shipdtl.inventoryupdated left false, order/line/release left open - but all other data fields processed correctly) and in case of latter, jobprod/jobpart.jobqtyshipped (& several other table.fields that are variants of this) not updated, shipdtl.ourjobqtyshipped not updated (sometimes, sometimes it is), no MFG-CUS parttran record created, order/line/release not closed when shipped complete & job itself becomes a job completion & closing exception that must be manually reviewed & updated.
Â
Open case on this last one right now (repeat of several years past attempt to have a solution provided) but little expectation root cause will be determined and a true fix provided (as WE can't reproduce at will... it simply occurs art seemingly random times although sole pattern seems to be when it occurs in a packI ship processing detail line, all remaining lines in pack ID fail to process - but that gives no clue to root cause of what happened on that 1st shipdtl line.Â
Â
One off .R's being tried to at least correct data (no success yet) but again - little expectation at this point that a true process fix can be had.
Â
Some postulation (on our part) that perhaps two users (using 2 different terminals in our multi-terminal/user shipping area) are hitting the core trigger record of cascading failure at same time & some odd record lock is occurring - but no definitive provable aspect of that hunch.
Â
(Hopefully) less than a year away from moving to 9 (701 or maybe by then 702 after rigorous testing & availing ourselves of the opprotunity the move gives us to rethink some ways we implemented 8 - or no longer have to augment 8 with some BPMs, customizations, etc., because 9 now neagtes need ), it will not occur on Epicor ERP (9).
Â
ALL complex systems have some bugs & some (without changing underlying architecture significantly or db schema significantly) simply defy 'fixing' - without screwing something else up in the process (so you pick your battles).
Â
Example 8.03.410 'fixes' some things that have existed since 405 (and even earlier) - but does so by essentially negating valued function (to us) we currently have... We'll only migrate to it/thru it to get to the desired v9 level when we upgrade from .409, to .410 to 9.?05?.5xx. to .7xx.
Â
If it is truly casuing you significant problems (on a scale worthy of pursuit & time investment), get a case opened with tech support (as Epicor seems to have recommitted themselves to improving support) - and if need be, ask for it to be escalated (so you don't get brushed off with the 'working as designed' response more common in the past or left with a conversion program that doesn't fix problem but simply attempts to fix records impacted by problem to varying degrees of success/satisfaction.
Â
Pick you battles and proceed accordingly until satisified all has been done that can be done. (The recommitted tech support now seems like it will do what it can to resolve) - but let's face it, even behemoths like Microsoft, Google, Apple, etc., do not make perfect software.
Â
That's not an apologist's excuse for them (as in the past, I've been somewhat harsh at time out of frustration - excessively so on occasion which was not the appropriate way to handle it):
Â
It's just reality. If it's really impacting you, ask for help (now) & 'kick it upstairs' via escalation if you feel it is getting no where. But if it's more of an annoyance than business impediemnt, save those bullets for when you really need them (for something really justifying it as we are partners with Epicor in resolving these issues because of the varying versions, modules licensed, degrees with which we use the system and how for our business needs, customizations, integration attempts with other software, quality of data, server and client platforms & performance optimization)... Pursuit will consume your time as well (so make sure it is justified for the time/effort).
Â
Â
Rob Brown
Versa Products
Â


>________________________________
>From: brenda mohr <brenda@...>
>To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
>Sent: Thursday, May 30, 2013 9:50 AM
>Subject: [Vantage] JobProd.ReceivedQty
>
>Â
>Under what circumstances would this field NOT be updated when we receive inventory to stock?
>
>Brenda
>
>[Non-text portions of this message have been removed]
>
>
>

[Non-text portions of this message have been removed]
6
Well then…. I just wrote a BPM that populates it when a MFG-STK PartTran record is created, but “forgets” to update the Rec’d Qty field. Seems to be working at this point.

Brenda

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Robert Brown
Sent: Friday, May 31, 2013 3:36 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] JobProd.ReceivedQty



Could be anything (even one of your own customizations or BPMs - or an outright bug that is just so rarely conditionally triggered & perhaps influenced by what optional modules are licensed and active, that support may not be able to reproduce).

We have (exceedingly rare) cases where parttran records are created (8.03.409a) with no sysdate.

We have more frequent (but still rare considering the number of lines we ship process) where both stock shipments and shipments direct from jobs (for former) fail to relieve inventory, no parttran record created and shipdtl.inventoryupdated left false, order/line/release left open - but all other data fields processed correctly) and in case of latter, jobprod/jobpart.jobqtyshipped (& several other table.fields that are variants of this) not updated, shipdtl.ourjobqtyshipped not updated (sometimes, sometimes it is), no MFG-CUS parttran record created, order/line/release not closed when shipped complete & job itself becomes a job completion & closing exception that must be manually reviewed & updated.

Open case on this last one right now (repeat of several years past attempt to have a solution provided) but little expectation root cause will be determined and a true fix provided (as WE can't reproduce at will... it simply occurs art seemingly random times although sole pattern seems to be when it occurs in a packI ship processing detail line, all remaining lines in pack ID fail to process - but that gives no clue to root cause of what happened on that 1st shipdtl line.

One off .R's being tried to at least correct data (no success yet) but again - little expectation at this point that a true process fix can be had.

Some postulation (on our part) that perhaps two users (using 2 different terminals in our multi-terminal/user shipping area) are hitting the core trigger record of cascading failure at same time & some odd record lock is occurring - but no definitive provable aspect of that hunch.

(Hopefully) less than a year away from moving to 9 (701 or maybe by then 702 after rigorous testing & availing ourselves of the opprotunity the move gives us to rethink some ways we implemented 8 - or no longer have to augment 8 with some BPMs, customizations, etc., because 9 now neagtes need ), it will not occur on Epicor ERP (9).

ALL complex systems have some bugs & some (without changing underlying architecture significantly or db schema significantly) simply defy 'fixing' - without screwing something else up in the process (so you pick your battles).

Example 8.03.410 'fixes' some things that have existed since 405 (and even earlier) - but does so by essentially negating valued function (to us) we currently have... We'll only migrate to it/thru it to get to the desired v9 level when we upgrade from .409, to .410 to 9.?05?.5xx. to .7xx.

If it is truly casuing you significant problems (on a scale worthy of pursuit & time investment), get a case opened with tech support (as Epicor seems to have recommitted themselves to improving support) - and if need be, ask for it to be escalated (so you don't get brushed off with the 'working as designed' response more common in the past or left with a conversion program that doesn't fix problem but simply attempts to fix records impacted by problem to varying degrees of success/satisfaction.

Pick you battles and proceed accordingly until satisified all has been done that can be done. (The recommitted tech support now seems like it will do what it can to resolve) - but let's face it, even behemoths like Microsoft, Google, Apple, etc., do not make perfect software.

That's not an apologist's excuse for them (as in the past, I've been somewhat harsh at time out of frustration - excessively so on occasion which was not the appropriate way to handle it):

It's just reality. If it's really impacting you, ask for help (now) & 'kick it upstairs' via escalation if you feel it is getting no where. But if it's more of an annoyance than business impediemnt, save those bullets for when you really need them (for something really justifying it as we are partners with Epicor in resolving these issues because of the varying versions, modules licensed, degrees with which we use the system and how for our business needs, customizations, integration attempts with other software, quality of data, server and client platforms & performance optimization)... Pursuit will consume your time as well (so make sure it is justified for the time/effort).


Rob Brown
Versa Products


>________________________________
>From: brenda mohr <brenda@...<mailto:brenda%40humtown.com>>
>To: "vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>" <vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>>
>Sent: Thursday, May 30, 2013 9:50 AM
>Subject: [Vantage] JobProd.ReceivedQty
>
>
>Under what circumstances would this field NOT be updated when we receive inventory to stock?
>
>Brenda
>
>[Non-text portions of this message have been removed]
>
>
>

[Non-text portions of this message have been removed]



[Non-text portions of this message have been removed]
7
We are on 607B as well. Off the top of my head, w/out research, seems about right.... We are planning to upgrade to 702 next week, so I'll add this to my testing plan.

Thanks for the replies :D

Brenda

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of robertbeaghan
Sent: Thursday, May 30, 2013 2:38 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: JobProd.ReceivedQty



We are on E9.05.607b and have found that 'Make To Order' jobs that are received to inventory do not update JobProd.ReceivedQty.

Bob Beaghan

--- In vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>, brenda mohr <brenda@...<mailto:brenda@...>> wrote:
>
> Under what circumstances would this field NOT be updated when we receive inventory to stock?
>
> Brenda
>
>
>
> [Non-text portions of this message have been removed]
>



[Non-text portions of this message have been removed]