I've been working with the jobhed table and can see how it is used to add jobs (projects) I want to work on.
What I don't understand is, what is the jobop table for, and more specifically, if I want to segment jobs(projects) with tasks, how that would be done.
For example, job(project) 1000 has three tasks, painting, assembly and wiring. If I want to work on those tasks I would clock in on task 0123, 0124 or 0125 ideally, under that job number: 1000
I see the fields below in the jobop table, there is a task code, but I'm not sure how a job is formatted so a task can be selected. I tried adding a task / jobnum to the jobop table, and that jobnum disappeared from the list of available jobs. It was already in the jobhed table.
To repeat, I would like to create a job (or project) with sub-tasks under it. These tasks may be identical
to another job, but I want to track the work on a task down to that job number.
More granularity is always better.
We have a web administration utility for doing much of this. This will make adding jobs and what not a whole lot easier for you.
Other than that, you are on the right idea of why the jobop table is there. We build DCS so that you can either log onto a job or define tasks beneath a job. So first you set up your job in jobhed. This is the top level job. So you assign a jobnum, partnum, part desc, any of the fields you need.
So once you have this new job created, you need to create sub-tasks to it. Now technically DCS lets you have assemblies above your operations, but we'll ignore those for now. So you want to link the jobnum to the jobhed table. So in jobnum put the jobnum of the job you created in jobhed. Next you want to put an opr_seq in. This is your operation (i.e. subtask). Fill in any other information you need. You may want to create workcenters (first make the workcenter in the wc table) then put the code you assigned to that work center in the wc_code field. This will show up on your main employee list then.
Once you have an operation made, it should now show up under the available jobs screen. It is important to note that once a job has operations, you cannot log onto the job generically. So if you have job 305 with operation 10, you cannot log onto just job 305 any more.
Also, always make sure that oprcomplete and jobcomplete is set to 0. This means that the job is active.
So when you have a job, you can log onto this job by browsing to it through the available jobs screen or you can type in the barcode:
Like before, those signifiers are defined in the config file. The 305 represents your job number. If you have an assembly it would be:
Like I said, we have a php administration utility that takes care of creating these jobs for you. We hope to have this up for download ASAP.
If you get to a point where you created your job and you created your operation and it is linked to your job but still not working, feel free to post what you have set up in the database and I will troubleshoot it for you.
Also, you probably want to uncomment the standalone mode:
This allows you to select employees by double clicking on them (makes it alot easier to test).
As I am writing this, saberlogic_ae is preparing to post the php administration utility. All this needs is dumped into your web directory (web server running php) and edit the file COM_DCS.inc in the library directory to match your environment.
I hope this helps. Let me know if you have any more questions.
The file you want is under 'SaberNet DCS - Web' and is called 'sndcs_web.tar.gz'.
Like I said, extract this into your web directory (apache server running php) and edit that COM_DCS.inc file to have your settings and you should be ready to go.
Let me know if you have any more questions.
Okay... sorry about that. You can only use the SaberNet administration utility to edit and make new top level jobs. For now you will have to create operations (sub-tasks) yourself by editing the jobop table.
What is the intended purpose of the task_code field in jobop?
Also is the jobnum field limited to numeric? It appears so.
I'm still working on a job / subtask schema...I think I can work around the alpha limit on jobnum, but curious about task_code.
Also, with subtasks defined, it shows the description for the jobnum. It would be nice if it could describe the subtask.
The task code is just a link to the task table where that task code is assigned a description. This is really just used for reporting now. An example would be if you had a task "splitting". Then in your task table you would have the task code defined as "100" and the description as "Splitting". Then when you created your operation (we refer to subtasks as operations because otherwise the concept would get very confusing) you could say that this operation is actually this process by saying that it is task code 100. So then when you build a crystal report off of it, you add both tables and link on task code.
Jobnum could very well be set up as pure numeric by default. All database settings are defined in the config file. So if you needed to get around the numeric limitation you can go into the config file and change the jobnum field type to something like varchar(100). You then want to re-create your database (I would rename your database or make sure that in the config file you have specified a different database name). There are some instructions on this site about "Initializing a SaberNet DCS Database". Simply put... edit your config file to have all the settings you want and then run "sndcs -I" and it will create the database.
Yeah it would be nice to really make that primary screen very flexable in what it shows. Our intention was that each job is going to produce one result. This result is your part... hence on the primary screen it is showing you what part each person is working on. Then to know where everyone is at, if you define the workcenter code (wc_code) and create an entry in your wc table that will show up in <>'s after the job. So maybe somebody is working in part "Shoe Insole 101" and are currently working on the "Splitter" workcenter the primary screen would show:
PartNum: Shoe Insole 101 <Splitter>
And since each seperate subtask can have a different workcenter you can describe the process in this way.
Hope This Helps!
Brian: Thanks for the help on the jobnum, I'll take a look at that.
I checked, the default appears to already be a varchar(100) for jobnum in the config file... If I create a jobnum ABC (or abc) it does not show up on the polling screen. If I attempt to scan it and a sub-task I get:
"The job status of ABC-0001 does not allow this transaction." I am running this on Windows 2000 is this a problem with the ported app?
The problem shouldn't have anything to do with the win32 port because the business logic is identical between the ports. I believe you are actually experiencing two separate problems here...
1. The job/operation not showing up on the list of available activities.
2. The system not allowing you to log onto the job/op because of the status.
Problem #1 is probably being caused by a bug/undocumented data scheme. There are three levels of abstraction used to describe all of the parts that make up a "job"...
|_ assembl(y | ies)
The names are essentially arbitrary but they are somewhat common terms used in ERP's. A job is your top level object (i.e. car). The job made be made up of several assemblies (i.e. engine, chasis, exhaust). And each assembly requires it's own operations to manufacture it (i.e. cut this, stamp out that, weld this other thing). One important thing to note is that the "assembly" level of abstraction is optional. So if your job does not require assemblies your scheme would look like this...
So, in our above example, if _all_ you do is manufacture exhast systems you would have your top level job (i.e. exhaust) and the operations that go into making it (i.e. clamp this, weld that).
Now I will get to the point of explaining all of that ;) If you *don't* have an assembly then the "assembly_seq" field in the "jobop" table *must* have a zero in it or it won't display in the list of available activities. At the very least the MySQL data scheme should set a default of "0" which it currently doesn't do so I will file a bug report when I am done here. You will still be able to log onto it though which leads me to problem #2...
The error message you describe is triggered by trying to log onto a job/op that has been closed. Either the "oprcomplete" field in the "jobop" table or the "jobcomplete" field in the "jobhed" table has a "1" in it for the record you are trying to log onto (flaging it as complete).