Time and Expense 9.05.702A

Glad to hear that it has improved things.

Simon

--- In vantage@yahoogroups.com, "Elizabeth" <gracefulthreads@...> wrote:
>
> Last night Epicor suggested I run Conversion Program 5460 (Reset DB Sequence Controls). I ran it in the test environment, then entered some labor, and IT SEEMED TO FIX IT!!!
>
> I ran it on the production database overnight and I'm about to go down to the shop floor and see what happens.
>
> In the early stages of this I did a trace and the two offending BOs were GetNewLaborDtlNoHdr (about 3-1/2 minutes) and LaborDefaultJobNum (2 min).
>
> This morning will be interesting.
>
> Thanks!
>
> Ernie Lowell
> Diba Industries
>
> --- In vantage@yahoogroups.com, "s1mhall" <s1mhall@> wrote:
> >
> > Ernie,
> > If you do a trace on the submit you will see when you put the trace into the performance diagnostic tool which method takes the time. When I did I saw that the Labor.GetRowsCalendarView method took the longest more than 4 times that of the submit method and I was only submitting 1 piece of time. The other thing to note is the method above is fired TWICE During the process. I presume because the data it retrieves needs to be fresh after the submit.
> >
> > I have to say the performance diag tool and the traces really helped in narrowing it down. Unfortunately all of the information I collated fell on deaf ears.
> >
> > Cheers
> > Simon
>
We've just upgraded from 9.04.507A to 9.05.702A and begun using Time and Expense entry from the main menu structure (we don't use MES).

It is SSSSSLLLLLLOOOOOOOWWWWWWW.

With Epicor support on the phone, a Trace took 213160.9013 milliseconds (213 seconds, or about 3-1/2 minutes) to perform a Labor.GetNewLaborDtlNoHdr, and then 127778.7365 ms (about 2 min) for Labor.DefaultJobNum. These are actually pretty fast... I've seen on the production floor where it can take over 5 minutes for each.

Anyone else having this issue?

Ernie Lowell
Diba Industries
Not sure this is what you are looking for but did you look at what you
are retrieving each time Time & Expense is opened?
Actions / Retrieve Records by
We have found that switching from Month to Week increased retrieval
time.


--- In vantage@yahoogroups.com, "Elizabeth" wrote:
>
> We've just upgraded from 9.04.507A to 9.05.702A and begun using Time
and Expense entry from the main menu structure (we don't use MES).
>
> It is SSSSSLLLLLLOOOOOOOWWWWWWW.
>
> With Epicor support on the phone, a Trace took 213160.9013
milliseconds (213 seconds, or about 3-1/2 minutes) to perform a
Labor.GetNewLaborDtlNoHdr, and then 127778.7365 ms (about 2 min) for
Labor.DefaultJobNum. These are actually pretty fast... I've seen on the
production floor where it can take over 5 minutes for each.
>
> Anyone else having this issue?
>
> Ernie Lowell
> Diba Industries
>



[Non-text portions of this message have been removed]
Yes,
We are on 701 and have seen performance issues around time and expense. How many resources do you have?

Cheers
Simon Hall

--- In vantage@yahoogroups.com, "Jean" <jbillet@...> wrote:
>
> Not sure this is what you are looking for but did you look at what you
> are retrieving each time Time & Expense is opened?
> Actions / Retrieve Records by
> We have found that switching from Month to Week increased retrieval
> time.
>
>
> --- In vantage@yahoogroups.com, "Elizabeth" wrote:
> >
> > We've just upgraded from 9.04.507A to 9.05.702A and begun using Time
> and Expense entry from the main menu structure (we don't use MES).
> >
> > It is SSSSSLLLLLLOOOOOOOWWWWWWW.
> >
> > With Epicor support on the phone, a Trace took 213160.9013
> milliseconds (213 seconds, or about 3-1/2 minutes) to perform a
> Labor.GetNewLaborDtlNoHdr, and then 127778.7365 ms (about 2 min) for
> Labor.DefaultJobNum. These are actually pretty fast... I've seen on the
> production floor where it can take over 5 minutes for each.
> >
> > Anyone else having this issue?
> >
> > Ernie Lowell
> > Diba Industries
> >
>
>
>
> [Non-text portions of this message have been removed]
>
Thanks Jean, but we've changed it down to Daily and it takes just as long. We've also UNset all the "Retrieve..." options on the Actions menu.

Ernie Lowell
Diba Industries

--- In vantage@yahoogroups.com, "Jean" <jbillet@...> wrote:
>
> Not sure this is what you are looking for but did you look at what you
> are retrieving each time Time & Expense is opened?
> Actions / Retrieve Records by
> We have found that switching from Month to Week increased retrieval
> time.
>
>
> --- In vantage@yahoogroups.com, "Elizabeth" wrote:
> >
> > We've just upgraded from 9.04.507A to 9.05.702A and begun using Time
> and Expense entry from the main menu structure (we don't use MES).
> >
> > It is SSSSSLLLLLLOOOOOOOWWWWWWW.
> >
> > With Epicor support on the phone, a Trace took 213160.9013
> milliseconds (213 seconds, or about 3-1/2 minutes) to perform a
> Labor.GetNewLaborDtlNoHdr, and then 127778.7365 ms (about 2 min) for
> Labor.DefaultJobNum. These are actually pretty fast... I've seen on the
> production floor where it can take over 5 minutes for each.
> >
> > Anyone else having this issue?
> >
> > Ernie Lowell
> > Diba Industries
> >
>
>
>
> [Non-text portions of this message have been removed]
>
Simon,

We have 13 Resource Groups, and each has either 1 or 2 resources (those with 1 resource just have a "Person", and those with 2 have "Person" and "Machine"). On my mid-distance horizon list is Finite Scheduling, and I'm not looking forward to it.

I've messed with both Calendar and Resource Group settings on the Employee ID entering the data, but cannot determine any correlation.

Ernie Lowell
Diba Industries

--- In vantage@yahoogroups.com, "s1mhall" <s1mhall@...> wrote:
>
> Yes,
> We are on 701 and have seen performance issues around time and expense. How many resources do you have?
>
> Cheers
> Simon Hall
>
> --- In vantage@yahoogroups.com, "Jean" <jbillet@> wrote:
> >
> > Not sure this is what you are looking for but did you look at what you
> > are retrieving each time Time & Expense is opened?
> > Actions / Retrieve Records by
> > We have found that switching from Month to Week increased retrieval
> > time.
> >
> >
> > --- In vantage@yahoogroups.com, "Elizabeth" wrote:
> > >
> > > We've just upgraded from 9.04.507A to 9.05.702A and begun using Time
> > and Expense entry from the main menu structure (we don't use MES).
> > >
> > > It is SSSSSLLLLLLOOOOOOOWWWWWWW.
> > >
> > > With Epicor support on the phone, a Trace took 213160.9013
> > milliseconds (213 seconds, or about 3-1/2 minutes) to perform a
> > Labor.GetNewLaborDtlNoHdr, and then 127778.7365 ms (about 2 min) for
> > Labor.DefaultJobNum. These are actually pretty fast... I've seen on the
> > production floor where it can take over 5 minutes for each.
> > >
> > > Anyone else having this issue?
> > >
> > > Ernie Lowell
> > > Diba Industries
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
I guess this is my day to come up with odd problems for the groupmind.
Thanks in advance...



We are currently running Epicor 9.05-700C and are encountering a
difficulty with reconciling inventory. Here is the situation:



We had an order for ten pieces of a given product, each of which
requires one piece of a specific part (WH-1260). The order was built and
shipped, and the supervisor is certain she entered her targets into the
system accurately. The traveler shows up as closed in the system.



Our problem is that inventory was relieved of only one of the WH-1215,
not ten.



Now we need to build more product using the WH-1215, and Epicor is
showing that we have nine pieces of WH-1215 in stock where actually we
used them all up building the previous order.



How can we begin to track out what really happened? Any ideas? Are we
looking at a problem with how the traveler was closed, the target
entered, a setting somewhere in E9? (The BOM for the end product is
correct and shows the correct quantity requirement for the WH-1260.)





[Non-text portions of this message have been removed]
Inventory was relieved of 1 WH-1215, do you know how this one was issued to the job?

Was it backflushed? Through Mass Issue to Mfg or Issue Material?

If it was backflushed - what was the labor qty?

In Job tracker you can go to Job > Job Details > Materials and look at the transaction for that part.

When you said it takes "one piece of a specific part (WH-1260)" - is this one per or is a fixed quantity of 1?



--- In vantage@yahoogroups.com, "Ree Pruehs" <rpruehs@...> wrote:
>
> I guess this is my day to come up with odd problems for the groupmind.
> Thanks in advance...
>
>
>
> We are currently running Epicor 9.05-700C and are encountering a
> difficulty with reconciling inventory. Here is the situation:
>
>
>
> We had an order for ten pieces of a given product, each of which
> requires one piece of a specific part (WH-1260). The order was built and
> shipped, and the supervisor is certain she entered her targets into the
> system accurately. The traveler shows up as closed in the system.
>
>
>
> Our problem is that inventory was relieved of only one of the WH-1215,
> not ten.
>
>
>
> Now we need to build more product using the WH-1215, and Epicor is
> showing that we have nine pieces of WH-1215 in stock where actually we
> used them all up building the previous order.
>
>
>
> How can we begin to track out what really happened? Any ideas? Are we
> looking at a problem with how the traveler was closed, the target
> entered, a setting somewhere in E9? (The BOM for the end product is
> correct and shows the correct quantity requirement for the WH-1260.)
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
Ernie,
If you do a trace on the submit you will see when you put the trace into the performance diagnostic tool which method takes the time. When I did I saw that the Labor.GetRowsCalendarView method took the longest more than 4 times that of the submit method and I was only submitting 1 piece of time. The other thing to note is the method above is fired TWICE During the process. I presume because the data it retrieves needs to be fresh after the submit.

I have to say the performance diag tool and the traces really helped in narrowing it down. Unfortunately all of the information I collated fell on deaf ears.

Cheers
Simon

--- In vantage@yahoogroups.com, "Elizabeth" <gracefulthreads@...> wrote:
>
> Simon,
>
> We have 13 Resource Groups, and each has either 1 or 2 resources (those with 1 resource just have a "Person", and those with 2 have "Person" and "Machine"). On my mid-distance horizon list is Finite Scheduling, and I'm not looking forward to it.
>
> I've messed with both Calendar and Resource Group settings on the Employee ID entering the data, but cannot determine any correlation.
>
> Ernie Lowell
> Diba Industries
>
> --- In vantage@yahoogroups.com, "s1mhall" <s1mhall@> wrote:
> >
> > Yes,
> > We are on 701 and have seen performance issues around time and expense. How many resources do you have?
> >
> > Cheers
> > Simon Hall
> >
> > --- In vantage@yahoogroups.com, "Jean" <jbillet@> wrote:
> > >
> > > Not sure this is what you are looking for but did you look at what you
> > > are retrieving each time Time & Expense is opened?
> > > Actions / Retrieve Records by
> > > We have found that switching from Month to Week increased retrieval
> > > time.
> > >
> > >
> > > --- In vantage@yahoogroups.com, "Elizabeth" wrote:
> > > >
> > > > We've just upgraded from 9.04.507A to 9.05.702A and begun using Time
> > > and Expense entry from the main menu structure (we don't use MES).
> > > >
> > > > It is SSSSSLLLLLLOOOOOOOWWWWWWW.
> > > >
> > > > With Epicor support on the phone, a Trace took 213160.9013
> > > milliseconds (213 seconds, or about 3-1/2 minutes) to perform a
> > > Labor.GetNewLaborDtlNoHdr, and then 127778.7365 ms (about 2 min) for
> > > Labor.DefaultJobNum. These are actually pretty fast... I've seen on the
> > > production floor where it can take over 5 minutes for each.
> > > >
> > > > Anyone else having this issue?
> > > >
> > > > Ernie Lowell
> > > > Diba Industries
> > > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>
Last night Epicor suggested I run Conversion Program 5460 (Reset DB Sequence Controls). I ran it in the test environment, then entered some labor, and IT SEEMED TO FIX IT!!!

I ran it on the production database overnight and I'm about to go down to the shop floor and see what happens.

In the early stages of this I did a trace and the two offending BOs were GetNewLaborDtlNoHdr (about 3-1/2 minutes) and LaborDefaultJobNum (2 min).

This morning will be interesting.

Thanks!

Ernie Lowell
Diba Industries

--- In vantage@yahoogroups.com, "s1mhall" <s1mhall@...> wrote:
>
> Ernie,
> If you do a trace on the submit you will see when you put the trace into the performance diagnostic tool which method takes the time. When I did I saw that the Labor.GetRowsCalendarView method took the longest more than 4 times that of the submit method and I was only submitting 1 piece of time. The other thing to note is the method above is fired TWICE During the process. I presume because the data it retrieves needs to be fresh after the submit.
>
> I have to say the performance diag tool and the traces really helped in narrowing it down. Unfortunately all of the information I collated fell on deaf ears.
>
> Cheers
> Simon
Following up to see if this worked in production for you with the
conversion program.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Elizabeth
Sent: Thursday, August 22, 2013 7:27 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Time and Expense 9.05.702A





Last night Epicor suggested I run Conversion Program 5460 (Reset DB
Sequence Controls). I ran it in the test environment, then entered some
labor, and IT SEEMED TO FIX IT!!!

I ran it on the production database overnight and I'm about to go down
to the shop floor and see what happens.

In the early stages of this I did a trace and the two offending BOs were
GetNewLaborDtlNoHdr (about 3-1/2 minutes) and LaborDefaultJobNum (2
min).

This morning will be interesting.

Thanks!

Ernie Lowell
Diba Industries

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"s1mhall" <s1mhall@...> wrote:
>
> Ernie,
> If you do a trace on the submit you will see when you put the trace
into the performance diagnostic tool which method takes the time. When I
did I saw that the Labor.GetRowsCalendarView method took the longest
more than 4 times that of the submit method and I was only submitting 1
piece of time. The other thing to note is the method above is fired
TWICE During the process. I presume because the data it retrieves needs
to be fresh after the submit.
>
> I have to say the performance diag tool and the traces really helped
in narrowing it down. Unfortunately all of the information I collated
fell on deaf ears.
>
> Cheers
> Simon





[Non-text portions of this message have been removed]
It half worked.

The Labor.GetNewLaborDtlNoHdr BO went down to virtually no time at all, but the Labor.DefaultJobNum BO went down only slightly (from about 2 min to about 1-1/2 min, which may or may not be significant depending on other Epicor/network activity).

I reported this to my support rep, but he hasn't gotten back to me yet.

Ernie Lowell
Diba Industries

--- In vantage@yahoogroups.com, "Chang, Chia" <cchang@...> wrote:
>
> Following up to see if this worked in production for you with the
> conversion program.
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Elizabeth
> Sent: Thursday, August 22, 2013 7:27 AM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Time and Expense 9.05.702A
>
>
>
>
>
> Last night Epicor suggested I run Conversion Program 5460 (Reset DB
> Sequence Controls). I ran it in the test environment, then entered some
> labor, and IT SEEMED TO FIX IT!!!
>
> I ran it on the production database overnight and I'm about to go down
> to the shop floor and see what happens.
>
> In the early stages of this I did a trace and the two offending BOs were
> GetNewLaborDtlNoHdr (about 3-1/2 minutes) and LaborDefaultJobNum (2
> min).
>
> This morning will be interesting.
>
> Thanks!
>
> Ernie Lowell
> Diba Industries
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "s1mhall" <s1mhall@> wrote:
> >
> > Ernie,
> > If you do a trace on the submit you will see when you put the trace
> into the performance diagnostic tool which method takes the time. When I
> did I saw that the Labor.GetRowsCalendarView method took the longest
> more than 4 times that of the submit method and I was only submitting 1
> piece of time. The other thing to note is the method above is fired
> TWICE During the process. I presume because the data it retrieves needs
> to be fresh after the submit.
> >
> > I have to say the performance diag tool and the traces really helped
> in narrowing it down. Unfortunately all of the information I collated
> fell on deaf ears.
> >
> > Cheers
> > Simon
>
>
>
>
>
> [Non-text portions of this message have been removed]
>