RE: Problem with 'C' transaction

[Al Mac <macwheel99@xxxxxxxxxxx>]

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)