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



Hi Richard,

We use softLanding with as/set and BPCS V8.1. We do manage BMR and won't 
have any problems so far.....

Sumit




bpcs-l-request@xxxxxxxxxxxx
Sent by: bpcs-l-bounces+srohatgi=mother-parkers.com@xxxxxxxxxxxx
07/19/2005 01:01 PM
Please respond to bpcs-l

 
        To:     bpcs-l@xxxxxxxxxxxx
        cc: 
        Subject:        BPCS-L Digest, Vol 3, Issue 151


Send BPCS-L mailing list submissions to
                 bpcs-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
                 http://lists.midrange.com/mailman/listinfo/bpcs-l
or, via email, send a message with subject or body 'help' to
                 bpcs-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
                 bpcs-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of BPCS-L digest..."


Today's Topics:

   1. BPCS, AS/SET and SoftLanding  (Richards, Mark)
   2. Re: BPCS-L Digest, Vol 3, Issue 150 (misterbpcs@xxxxxxx)
   3. SFC600S5(JIT) (Peggy Pacella)
   4. RE: BPCS, AS/SET and SoftLanding  (Neeraj Sarougi)
   5. SHOP PACKET PRINT ERROR (Daniel Wilkins)


----------------------------------------------------------------------

message: 1
date: Tue, 19 Jul 2005 09:38:27 -0400
from: "Richards, Mark" <richarma@xxxxxxxxxxxx>
subject: [BPCS-L] BPCS, AS/SET and SoftLanding 

Anyone using any version of BPCS and SoftLanding's change management
software?  If so, and you have any experience (good or bad) using it to
manage the BMR process would you be willing to discuss your experience
with us?
 
We are using their tools Turnover (for custom code) and Setturn (for
Asset) on V8.2.01.  TIA.
 
Mark Richards
Senior Systems Analyst

Tel: 616-546-3949
Fax: 616-392-2323
Email: richarma@xxxxxxxxxxxx <mailto:richarma@xxxxxxxxxxxx> 


Hart & Cooley

Web Site <http://www.hartandcooley.com/> 

Hart & Cooley, Information Technology 
500 E. 8th ST | Holland, MI 49423 | USA (Map)
<http://www.mapquest.com/maps/map.adp?countryid=250&addtohistory=&countr
y=US&address=500+E.+8th+St.&city=Holland&state=MI&zipcode=49423&historyi
d=&submit=Get+Map> 

 


------------------------------

message: 2
date: Tue, 19 Jul 2005 10:06:10 -0400
from: misterbpcs@xxxxxxx
subject: [BPCS-L] Re: BPCS-L Digest, Vol 3, Issue 150

It seems that the commonly used standard rule for rounding can be found in 
the rules used by Microsoft in their product called Excel.  If the digit 
is less than 5 it is dropped. If the digit igreater than 4, it rounds 
upward.  Try it! 
 
Ric Weide
Email: MisterBPCS@xxxxxxx
 
 
-----Original Message-----
From: bpcs-l-request@xxxxxxxxxxxx
To: bpcs-l@xxxxxxxxxxxx
Sent: Mon, 18 Jul 2005 12:00:26 -0500
Subject: BPCS-L Digest, Vol 3, Issue 150


Send BPCS-L mailing list submissions to
    bpcs-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.midrange.com/mailman/listinfo/bpcs-l
or, via email, send a message with subject or body 'help' to
    bpcs-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
    bpcs-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of BPCS-L digest..."


Today's Topics:

   1. RE: SMG BOM Change / Delete (Genyphyr Novak)
   2. [BPCS-BIL] Rounding at Sales Invoice Amount (Indah Kurniaty)
   3. Re:  Rounding at Sales Invoice Amount (Al Mac)
   4. Re: Re: Rounding at Sales Invoice Amount (Indah Kurniaty)
   5. Re: Re: Rounding at Sales Invoice Amount (Al Mac)


----------------------------------------------------------------------

message: 1
date: Sun, 17 Jul 2005 21:59:49 +0200
from: "Genyphyr Novak" <Genyphyr.Novak@xxxxxxxxxxxxx>
subject: RE: [BPCS-L] SMG BOM Change / Delete


Hello, 

You will need to get in touch with SSA sales or services about this. It
is possible to get new SMG gateways constructed upon request. 

Thanks,
Genyphyr Novak
Senior System Software Engineer
SSA Global R&D

Join us for SSA Global's premier customer event!
Global Client Forum 2005
September 19th - 22nd
Gaylord Palms Resort
Orlando, Florida
www.ssaglobal.com/gcf2005 
Learn why 13,000 businesses worldwide rely on SSA Global to extend ERP
across all their enterprise processes - from supplier to employee to
customer.
 
Get started by visiting www.ssaglobal.com 
----------------------------------------------------------------

date: Fri, 15 Jul 2005 15:52:47 -0500
from: "Zhang, Chaohui" <chaohui.zhang@xxxxxxxxxxx>
subject: [BPCS-L] SMG BOM Change / Delete


Hi, everyone:

We are trying to feed BOM data into BPCS (6004) through SMG,
but the current SMG version only supports Create method for BOM.

I have tried to modify related members in MAPS file in order to add 
Change and Delete method, but always got 

"**  ERROR(2) is unsupported message."

I have modified SMGMBMAG, SMGMBMD, any other things need to be done?

Thanks
Chaohui



------------------------------

message: 2
date: Mon, 18 Jul 2005 10:32:14 +0700
from: Indah Kurniaty <indah.kurniaty@xxxxxxxxx>
subject: [BPCS-L] [BPCS-BIL] Rounding at Sales Invoice Amount

Hi All,
 Would you like to share your experience about rounding at Sales Invoice ?
Is it true that BPCS round amount net price and tax at invoice line level, 

not at total invoice level ..or maybe I don't setup parameter incorrectly?

Example:

*(Setting)*
Round Type: Half adjustment
Round to position type : 1 
Tax Rate: 10%

I have 1 invoice with 3 inv line. All of these inv lines have same setting 

above.

*(SIL.ILNET )*
SUM(97.5 + 97.6 + 97.8) for invoice #1 = 292.8
After rounding, it should be 239

*(SIL.ILTA01)*
SUM(9.75+9.76+9.77) for invoice no. #1 = 29.29
After rounding, it should be 29

But.. what I found at SIH.SITOT and SIH.SITAX ?
SITOT = 324 and SITAX = 30 

I assumed that 324 was origined from 294 + 30 (sitax).
294 = half adj(97.5) + half adj(97.6) + half adj(97.7)
30 = half adj(9.75 ) + half adj(9.76) + half adj(9.77)
 Thanks in advance..


------------------------------

message: 3
date: Mon, 18 Jul 2005 00:11:04 -0500
from: Al Mac <macwheel99@xxxxxxxxxxx>
subject: [BPCS-L] Re:  Rounding at Sales Invoice Amount

This is probably version specific.  What version you at?
We at 405 CD on AS/400 mixed mode on OS/400 V5R1.

This sort of thing also varies by what programming language you using, 
also 
look at query/400.

There is also an issue of what the people in charge of company accounting 
want done, and whether your version offers you the flexibility to go one 
of 
several ways.  I do not have enough education in accounting to know what 
is 
a valid rule, and if this varies by government jurisdiction.

We had to modify because of systemic bug that SSA would not fix when we 
were on them for tech support ... we now on another place.

The systemic problem is that in IBM RPG when you are doing math with 
maximum size fields like x,xxx,xxx,xxx.xxxxx there is a concept that 
people 
in Microsoft and Internet world call a buffer overflow, but in the IBM 
world it is that when values in the math fall outside of the 
x,xxx,xxx,xxx.xxxxx space alotted without the programmer supplying work 
fields to handle that overflow, then you can get mathematically wrong 
results, and this is most likely to happen not when you have population 
near the ends of the fields like in the first or last digits, but when you 

working with what IBM calls extreme values like zero and one.

99% of the time it looks just like a rounding error.
If your cost buckets don't add up and they off by like 0.00001 or 0.00002 
and some costs go negative, this problem probably caused by this bug.
We once got an entry to our General Ledger for 9,999,999,999.99998 which 
was caused by this bug.
Because it is from a bug, you can't reverse the transaction and expect the 

error to go away.

This is clearly spelled out in the IBM RPG programmer manual.
When I reported this to SSA, I gave them chapter and verse from the 
manual, 
and where in several programs (e.g. costing, invoicing) they doing this 
wrong, but I don't think SSA tech support understood what I was trying to 
tell them.

We do our invoicing to 3 decimal places after the $
this is because we used to be selling reels of wire which very 
competitively priced, and needed the extra decimal places in the quoting.

So basically our invoices are telling our customers that they owe to some 
fraction that does not exist in real currency.

I had a former boss who disagreed with me what half adjust meant and 
demanded that we modify all the programs to agree with his 
interpretation.  I wanted to let it just do whatever IBM and SSA had 
programmed, and not sweat that microscopic detail in billions of source 
code lines, but he wanted it fixed.

I said that when I went to school and we covered this, it was 50 years 
ago, 
so my memory could be failing, but what I remember was:
* When what you are rounding is material consumed, you always round up any 

fractions ... it is like the story of the army busses and trucks ... how 
many vehicles to carry all the troops, without the extras sitting in 
someone's lap, on the floor between seats, standing up or whatever ... you 

round up to an extra vehicle
* When the value is bigger than point 5 you round up
* When the value is smaller than point 5 you round down
* When the value is exactly point 5 you take it to the nearest even number

Well my former boss disagreed about the exactly point 5 scenario ... he 
said it always went up

Afterwards I asked my sister about this ... she teaches high school math, 
and at the time she was also doing some college classes ... basically she 
told me that we were both wrong

it is not true that there is ONE RULE
there are in fact several valid rules available

We had a similar situation on the ERP we were on before BPCS
I was in the habit of studying the documentation on patches before trying 
to implement them.
I found one in which I knew enough accounting to know this cannot be 
right.
Some customer that knew nothing about accounting had complained that the 
ERP would not let them post to General Ledger when the debits and credits 
did not match, so the vendor fixed that, and one of the latest collections 

of patches would let 100% of the ERP customers post stuff to General 
Ledger 
not in balance.

>Hi All,
>  Would you like to share your experience about rounding at Sales Invoice 
?
>Is it true that BPCS round amount net price and tax at invoice line 
level,
>not at total invoice level ..or maybe I don't setup parameter 
incorrectly?
>
>Example:
>
>*(Setting)*
>Round Type: Half adjustment
>Round to position type : 1
>Tax Rate: 10%
>
>I have 1 invoice with 3 inv line. All of these inv lines have same 
setting
>above.
>
>*(SIL.ILNET )*
>SUM(97.5 + 97.6 + 97.8) for invoice #1 = 292.8
>After rounding, it should be 239
>
>*(SIL.ILTA01)*
>SUM(9.75+9.76+9.77) for invoice no. #1 = 29.29
>After rounding, it should be 29
>
>But.. what I found at SIH.SITOT and SIH.SITAX ?
>SITOT = 324 and SITAX = 30
>
>I assumed that 324 was origined from 294 + 30 (sitax).
>294 = half adj(97.5) + half adj(97.6) + half adj(97.7)
>30 = half adj(9.75 ) + half adj(9.76) + half adj(9.77)
>  Thanks in advance..

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor ... see
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html


------------------------------

message: 4
date: Mon, 18 Jul 2005 16:20:54 +0700
from: Indah Kurniaty <indah.kurniaty@xxxxxxxxx>
subject: Re: [BPCS-L] Re: Rounding at Sales Invoice Amount

Thanks Mac & Andrea for your explanation.
 I'm sorry I wrote wrong question.
The statement should be:
Is it true that BPCS round amount REVENUE and TAX at invoice line level , 
not at total invoice level ..or maybe I don't setup parameter incorrectly
 Andrea Garzia said that:
It was true that BPCS did rounding at invoice line level.
 The question is:
Why at SIL.ILREV, bpcs rounded 97.5 to 98, but at SIL.ILTA01 bpcs didn't 
round 9.75 to 10 ? And at SIH.SITAX = 30?
 Thanks...


------------------------------

message: 5
date: Mon, 18 Jul 2005 10:47:38 -0500
from: Al Mac <macwheel99@xxxxxxxxxxx>
subject: Re: [BPCS-L] Re: Rounding at Sales Invoice Amount

There's always the possibility that different humans wrote the programming 

code for different functions.  If it was done by people like me, my former 

boss, and my sister, as in my last post, we each have different ideas 
about 
what is needed, in the absence of any standards imposed by higher 
authority.  Thus, different programs, supposedly doing the same functions, 

could get different results, depending on the algorithms used by the whims 

of the programmers involved.

Have you reviewed any of the official BPCS documentation on this?

I have not seen any SSA standards on how this kind of thing ought to be 
handled.  I sure hope they exist some place for the SSA programmers.

>Thanks Mac & Andrea for your explanation.
>  I'm sorry I wrote wrong question.
>The statement should be:
>Is it true that BPCS round amount REVENUE and TAX at invoice line level ,
>not at total invoice level ..or maybe I don't setup parameter incorrectly
>  Andrea Garzia said that:
>It was true that BPCS did rounding at invoice line level.
>  The question is:
>Why at SIL.ILREV, bpcs rounded 97.5 to 98, but at SIL.ILTA01 bpcs didn't
>round 9.75 to 10 ? And at SIH.SITAX = 30?
>  Thanks...




------------------------------


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.