× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The paperwork hassles of shop floor "control" and shipping billing "collecting" can be significant, but they are microscopic compared to the paperwork shuffling nightmare associated with the purchase, receipt, and paying for raw materials.

First, the paperwork volume can enormous, especially when we fall behind. We might receive 100+ deliveries on any given day. We might receive 100+ vendor invoices in any given day, in combination of snail mail, e-mail, fax, much of it delivered to thw wrong offices or wrong personnel attention.

There are patterns of error in multiple vendor billing, that is fraud by accident.
Over-billing, double & triple billing, extra billing, how to handle past due invoices, same invoices delivered multiple concurrent ways, billing for stuff not received, omitting credits on returns, confusing invoices, wrong quantities, wrong prices, wrong U/M, wrong PO#, wrong labeling. Every vendor uses a different form layout for where their stuff is located on their invoices.

So we have a paperwork nightmare to match what was ordered, received, invoiced, before it can be entered to the system. Then when BPCS thinks we have entered all that was ordered, received, invoiced, but THEN we find an error, where the vendor under-shipped, it can be too late to fix on THAT PO#.

This is complicated by a separation of our offices personnel doing pices of the paperwork, so it flows from office to office. Forget about being able to take advantage of "discount if paid in 10 days", worry about getting it all figured out before it is past due.

My employer is extremely resistant to spending more money on our computer
infrastructure, unless someone does a gifted sales job on the benefits we
would get from some investment.

We have heavily modified the SFC/JIT output. There has been an evolution
in the mixture used. Currently we have, what we call JT05 (major version #
5 of the Job Tickets), because that is now the form name. This has a copy
of the routing description for the part being made, where used that it is
needed, what BOM goes into it, what customer it is for, other info, and
space for labor reporting start stop time, who worked on it, date, etc.
where the layout of stuff on the form, and layout of stuff on JIT/SFC/600
has also been modified to simplify transcription.

When we do a print run, there can be several thousand of these, which then
involves a manual task of getting them where they need to go. Getting the
paperwork back, ciorrectly filled out, for data entry, is a bigger
challenge. It is not unusual for there to be a need for adjustments, to
compensate for missing reporting.

This has been supplemented by some reports on the work-in-progress & the
work to be done. You know SFC230? We have a different version for each
factory department, optimized to that department's setup & other needs. We
have what we call "The Schedule" whose birth was cloned from an MRP2
report, but is unlike any MRP2 report in appearance.

Our shipping / invoicing documents have also undergone significant
modification.
I think the trouble trend for the future is that different major customers
want THEIR documents electronically, in which THEIR definition of form &
substance is like they all fantasize about FAX or EDI or FTP or some e-mail
attachment, but no two customers share the same fantasy. They are all
reinventing this wheel, like on different planets in different
universes. Then when it is time for them to pay for our shipment, we would
prefer that they identify the invoice they are paying for, but many
identify the part #, or the shipping packing tracking delivery ticket#,
deduct for RMAs or unearned discounts, or price increases they
dispute. Some customer accounting is moving off-shore to personnel who do
not have experience in any kind of commerce, such as the purpose of a
remittance advice with a check payment.

I suspect this is a challenge for all ERP.

>Hello All,
>
>I am looking for a few BPCS users who currently print and assemble shop
>floor data packets or other shipping and billing documents using a
>manual process. (IE: Print, Manually Assemble, then Mail.)
>
>If your users are doing a lot of manual labor to assemble documents,
>please contact me if you're interested in discussing what you're doing.
>
>I'm doing a little research for a new document assembly product we're
>working on for the Native iSeries and Windows environments and I need
>some input.
>
>I can be reached directly via any of the below methods.
>
>Thanks.
>
>Regards,
>Richard Schoen
>RJS Software Systems Inc.
>"Get the information you need. Now!"
>Document Management, Workflow, Report Delivery, Forms and Business
>Intelligence
>Email: richard@xxxxxxxxxxxxxxx
>Web Site: http://www.rjssoftware.com
>Tel: (952) 736-5800
>Fax: (952) 736-5801
>Toll Free: (888) RJSSOFT


--
This is the BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

Delivered-To: macwheel99@xxxxxxxxxx



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.