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



Thanks Gord,

I'm afraid we are already far down the road and already went there.

The problem with simplifying the FRW definitions is that sometimes
divisions start to use string segments for "special" purposes.
I guess you need a very centralized organization that can command uniform
use of segments.

At least it sounds like we are not the only ones who are prepared to become
a very complex organization one day.

Regards,
Monika


Monika





                    Gord Royle
                    <GRoyle@cott.co        To:     "'bpcs-l@midrange.com'" 
<bpcs-l@midrange.com>
                    m>                     cc:
                    Sent by:               Subject:     RE: Reflecting 
complexity of corporate structure in account
                    bpcs-l-admin@mi        strin   g
                    drange.com


                    02/14/2002
                    01:50 PM
                    Please respond
                    to bpcs-l






Hi Monika

Our organization uses 7 segments Consolidation, Legal Entity, Division,
Site(Location), Cost Center, Account and Project. The first six are
mandatory. Even though our organization may be more complex than yours, we
still probably don't need all of those segments. For instance a division
wil
occur in one and only one legal entity and a Site will occur in one and
only
one division.

As for FRW row definitions, you don't have to make them as complex as the
account structure. If you have redundancies in your strings, ignore all but
one segment. For instance, if your "location" codes are uniquely assigned
and don't duplicate across company, business, geography, legal entity, you
can safely ignore all four of those segments in your row definitions and
just define the "location" code.

As for reducing the number of string segments, that is a difficult (if not
impossible) job once you have started using them. Your best bet is "Don't
go
there".

Gord Royle

-----Original Message-----
From: Monika_Rossocha@PLANAR.COM [mailto:Monika_Rossocha@PLANAR.COM]
Sent: Thursday, February 14, 2002 4:13 PM
To: bpcs-l@midrange.com
Subject: Reflecting complexity of corporate structure in account string


Hi,

we are currently using five string segments (company, business, geography,
legal entity, location), an account and a department number to organize our
GL data.
This creates some input work and maintenance requirements although we are
not a complex conglomerate.

I'm seeking information on how other companies use these segments as
compared to how complex the company structure is. Do you have redundancies
in your string like having a segment for location and one for company
although location and company would be unique identifiers.

I found that making use of 5+2 segments for GL transactions makes creating
and maintaining FRW row definitions quite cumbersome.

Has anyone reduced the number of string segments used after finding that
you were duplicating information?

Thank you,

Monika

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.


Cott - The Leader in Premium Retailer Brand Beverage Innovation.


_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.






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.