× 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 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.