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




Eric

We also manage our data by facility.

In 405 CD we do not use INV500 for the "C" transaction, just as we do not
use it for the CST100 "#" transaction.  The "C" transaction is generated by
PUR550 receipt of the merchandise or ACP500 accounting doing the invoice,
depending on your corporate procedures.  In our case we use PUR550 for
quantity against purchase order, then accounting receipt of invoice handles
the costing.

You might ask others who know V 6.1 whether INV500 is intended to be used
for "C" transaction.  INV500 is probably not doing all the same stuff that
PUR550 and ACP500 does with respect to updating purchase order.  Just as we
use JIT600 to manage transactions against shop orders, are supposed to use
DRP550 for resupply orders (we use modifications instead), and a variety of
ORD590 and BIL500 to process shipping and billing transactions ... in other
words we do not do "B" transactions or corrections via INV500.

Since you are reversing Vendor Invoice Posting, can you not do an
adjustment against that same Invoice via ACP500, so as to affect the same
financial records as what you are reversing?  Unless your month end has
purged the purchase order lines involved.

In our BPCSDOC
SSARUN03 is for INV
  - search for INV150 and read up on Transaction Effects which advise
strongly against changing them, particularly "C" transaction, without first
thorough understanding of this "documentation".  This documentation is
useful to compare INV355 now with the original version so you can see what
if anything has been "adjusted" at your company.  I notice our version
tracks date of activity while you not doing that.

SSARUN06 is for PUR
PUR550

SSARUN12 is for ACP
ACP500 enters an invoice
ACP510 makes corrections to an existing invoice

I do recall we have had problems with incorrectly entering invoice # and
duplicate invoice #s... apparently BPCS not support two invoices from same
vendor that same #, so we have to put some dummy character at end of
invoice # to differentiate the duplicates.

We have also had problems with some fields used by our modifications where
a consultant thought that something BPCS called a THIS NUMBER or a THAT
NUMBER was in fact NUMERIC but BPCS has it as an ALPHABETICAL FIELD which
means that keying errors can put non-digits in there.

I guess the big question is HOW to handle corrections.
In just about every sub-system there is the possibility of discovery of a
need to back out some transaction, or make corrections.
Sometimes you can go there and do a minus transaction, with a bit of hassle
whether to use a hard minus or a soft minus, but sometimes the opposite
transaction needs to be with a different transaction activity.

Al Macintyre (macwheel99@sigecom.net via Eudora)



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.