KanBan Jobs Blank Title 126641

Thanks Bruce and Chuck for pointing out some options that we can use for our KanBan jobs.

 

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Butler, Bruce
Sent: Wednesday, November 27, 2013 6:19 AM
To: vantage@yahoogroups.com
Subject: RE: RE: [Vantage] RE: KanBan Jobs

 

 

We use Kanban receipts in 8.03.409c.  In the LaborHed table there is Trans Set field that gets set to “kanban” automatically when the transaction is generated through Kanban entry.  There is also a Payroll checkbox that gets unchecked when the transaction is generated through Kanban entry.  Because it is important for us to know who created the Kanban receipt we modified our payroll reporting to ignore the Kanban entries based on those fields.  I don’t remember setting up a BPM to “fix” these fields for our reporting.  As we look forward to 9.x, it would be good for me to know if these fields are still utilized. 

 

Note also, we use an external service for payroll processing, therefore, we do not use the payroll module.   All reporting that is sent to the external payroll processor is derived from a custom report used for exporting the data. 

 

-Bruce B.

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of chuck.degreeff@...
Sent: Tuesday, November 26, 2013 4:16 PM
To: vantage@yahoogroups.com
Subject: RE: RE: [Vantage] RE: KanBan Jobs

 

 

I think I see what might be happening.  Epicor creates a Labor Header record for the employee for the full day when the KanBan process is run for each part that is received, for the payroll side of the labor.  the actual job labor should be calculated based on the pro-rated cycle time vs qty calculation.  To address this we created a virtual KanBan employee, with a department rate of 0 that we used to create the KanBan transactions. The virtual employee was not a payroll employee, so we didn't care about payroll hours.  We also didn't care about production costing in this case because the underlying backflushed assemblies carried all of the effective labor cost.



---In vantage@yahoogroups.com, <cathy@...> wrote:

Thank you for getting back to me.

 

Our setup is pretty simple.  We do not have employees setup on the resource group.

 

We use KB as you described below.

 

I called Epicor yesterday and was told it is KanBan functionality to create a separate Labor Head record with the start and end of the shift.

 

Doesn’t make sense to me since it is a  Job and should be part of the LaborDetail.

 

Just wondering if anyone else is having problems with this and what they did about it -

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of chuck.degreeff@...
Sent: Tuesday, November 26, 2013 9:54 AM
To: vantage@yahoogroups.com
Subject: [Vantage] RE: KanBan Jobs

 

 

If the employee who is clocking into the KB job is also listed as the default labor source on the resource group you could wind up with double transactions. When we used KB jobs the system automatically completed and closed the job, which were created based on the KanBan receipt to inventory transaction.  I'm not sure that I understand how your employee creates the KB job.  We are 9.05.702 but functionality should be pretty much the same as yours.



---In vantage@yahoogroups.com, <cathy@...> wrote:

We have been having problems understanding the KanBan job and the way labor is accounted for in Epicor 9.05.605.

Example - we have an Employee that clocks in at 7am.

At 11am the employee creates a Kan Ban job.

Then the KanBan job clocks the employee in at 7 again and then clocks the employee out at 3:30 with one half an hour for lunch per the employee's shift.

The total labors hours on the KanBan jobs are 0.

At the end of the day we have 2 labor head records for 8 hours.  Looks like the employee work 16 hours.

Does this makes sense to anyone?

Why would a KanBan job clock the employee in a second time?

We have been having problems understanding the KanBan job and the way labor is accounted for in Epicor 9.05.605.

Example - we have an Employee that clocks in at 7am.

At 11am the employee creates a Kan Ban job.

Then the KanBan job clocks the employee in at 7 again and then clocks the employee out at 3:30 with one half an hour for lunch per the employee's shift.

The total labors hours on the KanBan jobs are 0.

At the end of the day we have 2 labor head records for 8 hours.  Looks like the employee work 16 hours.

Does this makes sense to anyone?

Why would a KanBan job clock the employee in a second time?

If the employee who is clocking into the KB job is also listed as the default labor source on the resource group you could wind up with double transactions. When we used KB jobs the system automatically completed and closed the job, which were created based on the KanBan receipt to inventory transaction.  I'm not sure that I understand how your employee creates the KB job.  We are 9.05.702 but functionality should be pretty much the same as yours.



---In vantage@yahoogroups.com, <cathy@...> wrote:

We have been having problems understanding the KanBan job and the way labor is accounted for in Epicor 9.05.605.

Example - we have an Employee that clocks in at 7am.

At 11am the employee creates a Kan Ban job.

Then the KanBan job clocks the employee in at 7 again and then clocks the employee out at 3:30 with one half an hour for lunch per the employee's shift.

The total labors hours on the KanBan jobs are 0.

At the end of the day we have 2 labor head records for 8 hours.  Looks like the employee work 16 hours.

Does this makes sense to anyone?

Why would a KanBan job clock the employee in a second time?

Thank you for getting back to me.

 

Our setup is pretty simple. We do not have employees setup on the resource group.

 

We use KB as you described below.

 

I called Epicor yesterday and was told it is KanBan functionality to create a separate Labor Head record with the start and end of the shift.

 

Doesn’t make sense to me since it is a Job and should be part of the LaborDetail.

 

Just wondering if anyone else is having problems with this and what they did about it -

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of chuck.degreeff@...
Sent: Tuesday, November 26, 2013 9:54 AM
To: vantage@yahoogroups.com
Subject: [Vantage] RE: KanBan Jobs

 

 

If the employee who is clocking into the KB job is also listed as the default labor source on the resource group you could wind up with double transactions. When we used KB jobs the system automatically completed and closed the job, which were created based on the KanBan receipt to inventory transaction.  I'm not sure that I understand how your employee creates the KB job.  We are 9.05.702 but functionality should be pretty much the same as yours.



---In vantage@yahoogroups.com, <cathy@...> wrote:

We have been having problems understanding the KanBan job and the way labor is accounted for in Epicor 9.05.605.

Example - we have an Employee that clocks in at 7am.

At 11am the employee creates a Kan Ban job.

Then the KanBan job clocks the employee in at 7 again and then clocks the employee out at 3:30 with one half an hour for lunch per the employee's shift.

The total labors hours on the KanBan jobs are 0.

At the end of the day we have 2 labor head records for 8 hours.  Looks like the employee work 16 hours.

Does this makes sense to anyone?

Why would a KanBan job clock the employee in a second time?

I think I see what might be happening.  Epicor creates a Labor Header record for the employee for the full day when the KanBan process is run for each part that is received, for the payroll side of the labor.  the actual job labor should be calculated based on the pro-rated cycle time vs qty calculation.  To address this we created a virtual KanBan employee, with a department rate of 0 that we used to create the KanBan transactions. The virtual employee was not a payroll employee, so we didn't care about payroll hours.  We also didn't care about production costing in this case because the underlying backflushed assemblies carried all of the effective labor cost.



---In vantage@yahoogroups.com, <cathy@...> wrote:

Thank you for getting back to me.

 

Our setup is pretty simple.  We do not have employees setup on the resource group.

 

We use KB as you described below.

 

I called Epicor yesterday and was told it is KanBan functionality to create a separate Labor Head record with the start and end of the shift.

 

Doesn’t make sense to me since it is a  Job and should be part of the LaborDetail.

 

Just wondering if anyone else is having problems with this and what they did about it -

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of chuck.degreeff@...
Sent: Tuesday, November 26, 2013 9:54 AM
To: vantage@yahoogroups.com
Subject: [Vantage] RE: KanBan Jobs

 

 

If the employee who is clocking into the KB job is also listed as the default labor source on the resource group you could wind up with double transactions. When we used KB jobs the system automatically completed and closed the job, which were created based on the KanBan receipt to inventory transaction.  I'm not sure that I understand how your employee creates the KB job.  We are 9.05.702 but functionality should be pretty much the same as yours.



---In vantage@yahoogroups.com, <cathy@...> wrote:

We have been having problems understanding the KanBan job and the way labor is accounted for in Epicor 9.05.605.

Example - we have an Employee that clocks in at 7am.

At 11am the employee creates a Kan Ban job.

Then the KanBan job clocks the employee in at 7 again and then clocks the employee out at 3:30 with one half an hour for lunch per the employee's shift.

The total labors hours on the KanBan jobs are 0.

At the end of the day we have 2 labor head records for 8 hours.  Looks like the employee work 16 hours.

Does this makes sense to anyone?

Why would a KanBan job clock the employee in a second time?

<!-- #ygrps-yiv-824382625 _filtered #ygrps-yiv-824382625 {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #ygrps-yiv-824382625 {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #ygrps-yiv-824382625 {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #ygrps-yiv-824382625 {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #ygrps-yiv-824382625 {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #ygrps-yiv-824382625 {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} _filtered #ygrps-yiv-824382625 {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} #ygrps-yiv-824382625 #ygrps-yiv-824382625 p.ygrps-yiv-824382625MsoNormal, #ygrps-yiv-824382625 li.ygrps-yiv-824382625MsoNormal, #ygrps-yiv-824382625 div.ygrps-yiv-824382625MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman", "serif";} #ygrps-yiv-824382625 a:link, #ygrps-yiv-824382625 span.ygrps-yiv-824382625MsoHyperlink { color:blue; text-decoration:underline;} #ygrps-yiv-824382625 a:visited, #ygrps-yiv-824382625 span.ygrps-yiv-824382625MsoHyperlinkFollowed { color:purple; text-decoration:underline;} #ygrps-yiv-824382625 p {

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 code
{
font-family:“Courier New”;}
#ygrps-yiv-824382625 pre
{

margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:“Courier New”;}
#ygrps-yiv-824382625 tt
{
font-family:“Courier New”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625MsoAcetate, #ygrps-yiv-824382625 li.ygrps-yiv-824382625MsoAcetate, #ygrps-yiv-824382625 div.ygrps-yiv-824382625MsoAcetate
{

margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:“Tahoma”, “sans-serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625ygrps-yiv-1249354775msonormal, #ygrps-yiv-824382625 li.ygrps-yiv-824382625ygrps-yiv-1249354775msonormal, #ygrps-yiv-824382625 div.ygrps-yiv-824382625ygrps-yiv-1249354775msonormal
{

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 span.ygrps-yiv-824382625HTMLPreformattedChar
{

font-family:“Consolas”, “serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625attach, #ygrps-yiv-824382625 li.ygrps-yiv-824382625attach, #ygrps-yiv-824382625 div.ygrps-yiv-824382625attach
{

margin-right:0in;

margin-left:0in;
font-size:9.0pt;
font-family:“Arial”, “sans-serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625bold, #ygrps-yiv-824382625 li.ygrps-yiv-824382625bold, #ygrps-yiv-824382625 div.ygrps-yiv-824382625bold
{

margin-right:0in;

margin-left:0in;
font-size:10.0pt;
font-family:“Arial”, “sans-serif”;
font-weight:bold;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625green, #ygrps-yiv-824382625 li.ygrps-yiv-824382625green, #ygrps-yiv-824382625 div.ygrps-yiv-824382625green
{

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;
color:#628C2A;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625replbq, #ygrps-yiv-824382625 li.ygrps-yiv-824382625replbq, #ygrps-yiv-824382625 div.ygrps-yiv-824382625replbq
{
margin:3.0pt;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625ad, #ygrps-yiv-824382625 li.ygrps-yiv-824382625ad, #ygrps-yiv-824382625 div.ygrps-yiv-824382625ad
{

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625underline, #ygrps-yiv-824382625 li.ygrps-yiv-824382625underline, #ygrps-yiv-824382625 div.ygrps-yiv-824382625underline
{

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 span.ygrps-yiv-824382625yshortcuts
{}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625ad1, #ygrps-yiv-824382625 li.ygrps-yiv-824382625ad1, #ygrps-yiv-824382625 div.ygrps-yiv-824382625ad1
{

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625ad2, #ygrps-yiv-824382625 li.ygrps-yiv-824382625ad2, #ygrps-yiv-824382625 div.ygrps-yiv-824382625ad2
{

margin-right:0in;
margin-bottom:7.5pt;
margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;}
#ygrps-yiv-824382625 p.ygrps-yiv-824382625underline1, #ygrps-yiv-824382625 li.ygrps-yiv-824382625underline1, #ygrps-yiv-824382625 div.ygrps-yiv-824382625underline1
{

margin-right:0in;

margin-left:0in;
font-size:12.0pt;
font-family:“Times New Roman”, “serif”;
text-decoration:underline;}
#ygrps-yiv-824382625 span.ygrps-yiv-824382625yshortcuts1
{
font-family:“Verdana”, “sans-serif”;
font-weight:bold;}
#ygrps-yiv-824382625 span.ygrps-yiv-824382625yshortcuts2
{
font-family:“Verdana”, “sans-serif”;
font-weight:normal;}
#ygrps-yiv-824382625 span.ygrps-yiv-824382625BalloonTextChar
{

font-family:“Tahoma”, “sans-serif”;}
#ygrps-yiv-824382625 span.ygrps-yiv-824382625EmailStyle38
{
font-family:“Calibri”, “sans-serif”;
color:#1F497D;}
#ygrps-yiv-824382625 .ygrps-yiv-824382625MsoChpDefault
{
font-size:10.0pt;}
_filtered #ygrps-yiv-824382625 {
margin:1.0in 1.0in 1.0in 1.0in;}
#ygrps-yiv-824382625 div.ygrps-yiv-824382625WordSection1
{}
#ygrps-yiv-824382625
_filtered #ygrps-yiv-824382625 {
}
_filtered #ygrps-yiv-824382625 {

font-family:Symbol;}
_filtered #ygrps-yiv-824382625 {

font-family:“Courier New”;
}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
_filtered #ygrps-yiv-824382625 {

font-family:Wingdings;}
#ygrps-yiv-824382625 ol
{margin-bottom:0in;}
#ygrps-yiv-824382625 ul
{margin-bottom:0in;}
–>

We use Kanban receipts in 8.03.409c. In the LaborHed table there is Trans Set field that gets set to “kanban” automatically when the transaction is generated through Kanban entry. There is also a Payroll checkbox that gets unchecked when the transaction is generated through Kanban entry. Because it is important for us to know who created the Kanban receipt we modified our payroll reporting to ignore the Kanban entries based on those fields. I don’t remember setting up a BPM to “fix” these fields for our reporting. As we look forward to 9.x, it would be good for me to know if these fields are still utilized.Â

 

Note also, we use an external service for payroll processing, therefore, we do not use the payroll module.  All reporting that is sent to the external payroll processor is derived from a custom report used for exporting the data.Â

 

-Bruce B.

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of chuck.degreeff@…
Sent: Tuesday, November 26, 2013 4:16 PM
To: vantage@yahoogroups.com
Subject: RE: RE: [Vantage] RE: KanBan Jobs

 

 

I think I see what might be happening.  Epicor creates a Labor Header record for the employee for the full day when the KanBan process is run for each part that is received, for the payroll side of the labor.  the actual job labor should be calculated based on the pro-rated cycle time vs qty calculation.  To address this we created a virtual KanBan employee, with a department rate of 0 that we used to create the KanBan transactions. The virtual employee was not a payroll employee, so we didn’t care about payroll hours.  We also didn’t care about production costing in this case because the underlying backflushed assemblies carried all of the effective labor cost.



—In vantage@yahoogroups.com, <cathy@…> wrote:

Thank you for getting back to me.

 

Our setup is pretty simple.  We do not have employees setup on the resource group.

 

We use KB as you described below.

 

I called Epicor yesterday and was told it is KanBan functionality to create a separate Labor Head record with the start and end of the shift.

 

Doesn’t make sense to me since it is a  Job and should be part of the LaborDetail.

 

Just wondering if anyone else is having problems with this and what they did about it -

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of chuck.degreeff@
Sent: Tuesday, November 26, 2013 9:54 AM
To: vantage@yahoogroups.com
Subject: [Vantage] RE: KanBan Jobs

 

 

If the employee who is clocking into the KB job is also listed as the default labor source on the resource group you could wind up with double transactions. When we used KB jobs the system automatically completed and closed the job, which were created based on the KanBan receipt to inventory transaction.  I’m not sure that I understand how your employee creates the KB job.  We are 9.05.702 but functionality should be pretty much the same as yours.



—In vantage@yahoogroups.com, <cathy@…> wrote:

We have been having problems understanding the KanBan job and the way labor is accounted for in Epicor 9.05.605.

Example - we have an Employee that clocks in at 7am.

At 11am the employee creates a Kan Ban job.

Then the KanBan job clocks the employee in at 7 again and then clocks the employee out at 3:30 with one half an hour for lunch per the employee’s shift.

The total labors hours on the KanBan jobs are 0.

At the end of the day we have 2 labor head records for 8 hours.  Looks like the employee work 16 hours.

Does this makes sense to anyone?

Why would a KanBan job clock the employee in a second time?