Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Work order Paperwork "empty" SOLVED
03-19-2017, 01:28 AM, (This post was last modified: 03-22-2017, 11:59 PM by dalescott.)
#1
Work order Paperwork "empty" SOLVED
Hi, I tried printing the work order "Paperwork" and "Labels", but the generated PDFs only have company logos on the pages, nothing else.

I created a work order for qty 10 of a manufactured item and used the "Print W/O" link to print the Paperwork and Labels. "Paperword" was 13 pages long and "Labels" was 10 pages long, but the only thing on each page was the company logo.

I suspect I just don't understand the work order process correctly. Can anyone clarify the basic workflow?

* When would I typically print the work order "Paperwork"

* Is the "Paperwork" intended to travel with the work-in-process on the production floor? (I.e. as a "traveller"?)

* What are the work order labels used for? Are they labels for the output stock?

* Is there a "pick list" for picking the raw materials from the stock shelves? Will this be part of the "Paperwork" when I get it working?

You can see a skeleton draft skeleton of my manufacturing tutorial http://www.dalescott.net/manufacturing-using-weberp/

Many thanks,
Dale
http://www.dalescott.net
Reply
03-19-2017, 06:29 AM, (This post was last modified: 03-19-2017, 08:16 AM by dalescott.)
#2
RE: Work order Paperwork "empty"
Fyi, I generated the work order "Paperwork" (PDF) after creation but before issuing material, and also after issuing material but before receiving, and the PDF is still empty except for the company logo (although it's now it was 13 pages at one point, but it now back to 11). There are no indications of errors in either the webERP log file (webERP Log Severity Level is set to All) or the Apache log file.

I added the Paperwork PDF in case it helps understand what's happening.

P.S. you should be able to see everything if you want http://weberp.dalescott.net (login as "auditor" with password "guest").


Attached Files
.pdf   weberp-item-20000001-00_mfg-207-02_work_order.pdf (Size: 22.38 KB / Downloads: 5)
http://www.dalescott.net
Reply
03-22-2017, 01:05 AM,
#3
RE: Work order Paperwork "empty"
Is the xml file in the FormDesigns folder? It should be called WOPaperwork.xml

Tim
Reply
03-22-2017, 03:22 PM, (This post was last modified: 03-23-2017, 12:07 AM by dalescott.)
#4
RE: Work order Paperwork "empty"
Copied from email to developers mail list.

The webERP_4.13.1.zip archive downloaded from Sourceforge is missing a number of xml files from the companies/weberp/FormDesigns directory. This prevented at least the correct generation of work order PDF "Paperwork" and "Labels" files.

root@whizzer:/usr/local/www/weberp-4.13.1 # ll companies/weberp/FormDesigns
total 32
-rw-r--r-- 1 www www 5264 Feb 21 13:26 GoodsReceived.xml
-rw-r--r-- 1 www www 3901 Feb 21 13:26 Journal.xml
-rw-r--r-- 1 www www 8903 Feb 21 13:26 PickingList.xml
-rw-r--r-- 1 www www 7650 Feb 21 13:26 PurchaseOrder.xml

root@whizzer:/usr/local/www/weberp-4.13.1 # ll companies/weberpdemo/FormDesigns
total 48
-rw-r--r-- 1 www www 1702 Mar 21 15:42 FGLabel.xml
-rw-r--r-- 1 www www 5264 Mar 21 15:42 GoodsReceived.xml
-rw-r--r-- 1 www www 3901 Mar 21 15:42 Journal.xml
-rw-r--r-- 1 www www 8903 Mar 21 15:42 PickingList.xml
-rw-r--r-- 1 www www 7650 Mar 21 15:42 PurchaseOrder.xml
-rw-r--r-- 1 www www 1204 Mar 21 15:42 QALabel.xml
-rw-r--r-- 1 www www 7967 Mar 21 15:42 WOPaperwork.xml

I diff'd the files in common and they were identical. Then I copied over the files missing in weberp/ from weberpdemo/ and correct work order PDFs appear to be generated. Thanks to Tim Schofield for his help figuring this out.

How is the zip release file created? I checked the trunk branch on Sourceforge and did not see a companies/weberp directory.

For what it's worth, I would have taken the effort to enter this into a project bug tracker (even if in hindsight this issue turns out to be my fault, and not a bug at all). I read through archived mail threads proposing a project bug tracker, and understand the rationale that a quick email from a user, and equally quick fix from a developer, is less work than what a bug tracker would impose (e.g. enter bug, fix code, commit code, link bug to commit, close bug). However, not having a bug tracker also means there is no common or public place to store issues for fixing later (e.g. when the fix isn't quick, or isn't a high priority), and searching through mail archives for old bug reports, and then figuring out if a report has already been fixed or not, becomes much more work than a bug tracker would have been (and much less reliable).

I've experimented using the Sourceforge Tickers system on one of my own projects and although not perfect, it seems convenient and good enough for the basics. Bug reports could still be welcomed from casual community members through email or forum posts, with active members taking it upon themselves to create a ticket when they felt it was justified.

A side benefit to a bug tracker is the confidence it gives to the general community, showing bugs are treated seriously, and reports are triaged and resolved appropriately. There may be arguments about _how_ a bug was triaged or resolved (in particular, the ones simply classified as "won't fix" without any explanation get my back up), but the visibility means that a bug report can't ever be overlooked or forgotten.

Cheers,
Dale

http://www.dalescott.net
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)