×
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.
I have many ideas ... hopefully one of them in here will help you solve
your question.
Summary answer ... it depends on how you use your BOL/Packlist #s
Minimum modification answer, assuming your version of BPCS works similar to
ours ... take a look at all the fields in the files created by the
invoiceing process ... for example SIL has the line items on an invoice and
SIH has the total for each invoice, with records of SIL and SIH linked by
invoice # ... OURS has the BOL/Packlist# in there, so it is theoretically
possible to have a report / inquiry cross indexing BOL/Packlist# vs. what
invoice # is that? ... So a customer sends you $, and they reference
BOL/Packlist #, then you look up proposed new inquiry/report such as a
query/400 to see what the corresponding invoice# for that.
See if you can access SIL.ILDOCR
This document reference # in our Invoice detail file is the BOL/Packlist#
which was used to ship the item line involved
In the same file is SIL.ILINVN
which is the invoice #
I no longer remember if this is native BPCS or our modifications.
If you have any customers that are slow to pay their bills, in which you
need to send them reminder notices, it might help speed the process of them
getting their financial act together if you supplied them the
BOL/Packlist#s associated with each of the Invoices they behind in paying.
If you want to replace Invoice # with BOL/Packlist#, I would think you
would need to have a compound # to ensure uniqueness, so that the
BOL/Packlist # is PART of the total string of #s, and some way to handle
reconciliation when customers pay part of what they are being invoiced.
We have some invoices which are for other than items shipped, such as
special tooling charges, setup charges, overtime charges on a rush order,
cancelation charges on an order that was partially made when it got
cancelled, and so forth ... if you have anything like that, you need to
have some way to do invoicing when there is no BOL/Packlist# in the equation.
Invoice #s ... some place in BPCS it remembers the last invoice # that was
issued
Then the Billing program looks up that place to get the last #, increments
it by one, uses that for the current #, and replaces the value in the
memory place.
I guess a modification could say ... do not use the value that is in that
place ... instead use this algorithm based on the document # in the BBL
record currently being processed, then check the invoice files SIH SIL RAR
to make sure we not already have that concocted # in the system, and have
some logic to do what if that # already in use.
See if in your BPCS library list there is an object by the name of BPCSDOC.
Depending on your 400 security, you may be able to access it via PDM ...
each member is a different BPCS manual ... the one on customer orders and
shipping is huge ... I split our SSARUN04 into pieces by sub-topic so
easier to navigate..
The front door on this is menu DOC which needs SYS security, or copy
selected options to OUR menus, and have security specific to them.
You are fortunate to be able to say that most of your customers pay in a
particular way.
For ours it would be more accurate to say that there is no sign of any
consistency from customer to customer. Any different way that is
theoretically possible, at least one of our customers will want to use that.
I have been with this same company since we installed BPCS I forget how
many years ago ... something like 17 years ago (I think it was 1988). It
is unreasonable to expect employees to remember all the stuff they have
ever done. That's why we have documentation standards, programming
standards, business records, but ours not structured for easy
retrieval. So that in theory, as there is employee turn-over, the new
people can access information on what all had been done by prior people.
We are on 405 CD somewhat modified. We do not have AS/Set, which means
that modifying ORD5* is prohibitive, unless we farm out the mod to 3rd party.
Our normal flow is that during a long day, that goes from like 5 am to
perhaps 6 pm, people can be shipping stuff, in which they key in a
BOL/Packlist #, consisting of prefix being the warehouse the shipment is
from, in which the first character of the warehouse is the facility .... so
we might have a BOL/Packlist # of 41012345 meaning it shipped from
warehouse 1 of facility 4.
We do not have ASN integrated with BPCS ... we do have various listings of
what was shipped various customers that day, and for some customers, all
they want from us are those lists, not the actual invoices ... so we have
reports for them consolidating the whole story on what they ordered, our
BOL etc. our invoice#, $ details, and they pay from that.
At one time, some people in the company wanted the BOL/Packlist # to be
automatically incremented, so not require human attention ... because we do
not have AS/Set, to implement this modification would have required farming
it out to 3rd party tech support, an expense which was never justified by
management.
The BOL/Packlist might be the same # for many different customer order #s
item #s different packages, going out at the same time, on different
trucking services ... regular, UPS, red, air ... the # refers to all this
STUFF that we sent out at one time. It cannot be used to track individual
pieces of the stuff.
Then in the evening, when 100% shipping has completed, I do pre-billing,
billing, post-billing, then next morning, the accounting clerk processes
the invoices and data from the reports I had generated.
Pre-Billing involves final verification of pricing, profit centers, bogus
orders, and other stuff that I can fix before it is a bigger nightmare to fix.
BPCS Billing generates an Invoice for each Customer Order that was involved
in the day's shipping. In our case, there might be several customer orders
on the same BOL/Packing #, and/or several BOL/Packing#s on the same
Customer Order.
We have modified the billing program so that it prints the BOL/Packlist #
... however, we lose precision accuracy in cases where there are multiple
BOL/Packlist #s for the items on one Invoice, because in the early days,
there was only one BOL/Packlist # to a shipment on the same customer order
#, but over time, the business has evolved, and now we can have more than
one BOL/Packlist # on the same order # in the same day.
Some customers have also asked us to track the release #s on their PO# ...
because we have named our end item#s to be the same as the customer part #,
we do not need the item description field for end items, so we use that for
release #, which then shows up through supply chain, and we have modified
other reports to extract it.
Hoping that one or more of my thoughts have been helpful,
your pal, Al Mac
BPCS Computer Janitor
Ok, I have a question as well.
Invoice numbers -- is it possible to use the BOL/Packlist number? We have
been on BPCS since 1999. Of course all that set it up are mostly gone by
now. Currently have multiple Prefix's we use for different
Divisions/facilities, types, etc. Numbering is set up in ACR160 with the
document sequences. Most of our customers pay from BOL# sent from the ASN
and don't even receive a real invoice anymore. One of the ladies thought
there had been a choice to use the BOL# -- but we can't find it. Any ideas?
Wendy Bunch
Cost Accountant
Wabash Technologies
1375 Swan Street
PO Box 829
Huntington, IN 46750-0829
Direct (260) 355-4204
Main (260) 355-4100
Fax (260) 355-4265
wbunch@xxxxxxxxxxxxxx
-
Al Macintyre http://www.ryze.com/go/Al9Mac
Find BPCS Documentation Suppliers
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
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.