RE: Maintaining Open Order Total for Customers

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Bud,

Well, based on that, I agree with everyone else....  QUOTES!  Actually, we
have what may be a similar need in what we called booked orders (not using
the same terminology that MAPICS uses), and we needed visibility in future
demand.  For some reason, they didn't want to use MAPICS Quotes.  We ended
up having an offline (as in not a MAPICS) database on the system that
contained "future potential orders", or what the customer had "committed"
to.  The quote signs are deliberate, the customer basically agrees to
acquire a quantity of campers (that's what we build and sell), and gave us
models that they would want.  We book them for use in our forecasting (not
MAPICS') and use in MPSP, but they aren't really orders until the customer
actually says to ship them.  At that time, what they said they wanted
initially typically changes drastically in response to their actual needs
(the 1st definition of a forecast is that it is wrong).  To make things
easier on our sales force, they can log their "bookings", then when it's
time to make a "booking" into an actual order, we gave Sales an easy tool
that they can use to change the "booked" order into what is actually
wanted, then run it through COM offline load.  Again, another case where
MAPICS makes it (relatively) easy to work around their system, and still
use it for what it does well.

Dale @ Fleetwood






Bud Roble <BRoble@CharlesRobleConsulting.com>
Sent by: mapics-l-admin@midrange.com
11/05/02 05:59 PM
Please respond to mapics-l


        To:     "'mapics-l@midrange.com'" <mapics-l@midrange.com>
        cc:
        Subject:        RE: Maintaining Open Order Total for Customers


Dale,

Thanks again for your input and to everyone else who has taken the time to
try to help me out!   I have used the user exits many times and as you
said,
they are great for all the reasons you pointed out.   There is a basic
problem with using a user exit in this instance however.   I can't simply
look at the current order that is being processed.   The current order may
or may not be a HFR order.   Each time a credit check is done, I would
need
to know the total value of ALL HFR orders in the system for that customer,
and then deduct that amount from the total open order amount used in the
credit checking.    What I need to know is where the credit checking is
performed, and then modify the logic that calculates the total value of
all
open orders for the customer to ignore the HFR orders.

Bud

-----Original Message-----
From: DaleGindlesperger@fft-inc.com [mailto:DaleGindlesperger@fft-inc.com]
Sent: Tuesday, November 05, 2002 2:33 PM
To: mapics-l@midrange.com
Subject: RE: Maintaining Open Order Total for Customers

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Bud,

I would use User Exits UMBCOH2B or UMBCOH2R (probably 2B would be better -
it depends), write a small piece of logic in the shell program to check
the due date and also check MBCKREP (Order Hold file) to see if it's on
hold.  If you have the specific due date (I see nothing wrong with using
01/01/39 - the likelyhood of this application still running as is in 37
years is pretty small), update MBCKREP as required (put in an approval
flag and date).

If you want, I can e-mail you a piece of source you can use as an example.
 It's not hard, and we have found the user exits to be EXTREMELY powerful
tools in bending MAPICS flow to our specific demands.  And the best part
is, you aren't modifying MAPICS, you are just shortcutting the need to
manually do some functions.  That's why MAPICS provides them.  Just be
very sure you understand the values in the fields you are updating.  If
confused, submit a question for clarification to the hot line via e-Info.
I have found them all to be very helpful in explaining codes and the
impact on some of the logic flow.  All the groups are very helpful, but it
seems the COM group is especially so - I think they are pretty well used
to it.

Oh, by the way, if you use CSM, I think the user exit is UMBCOH4R, instead
of 2B or 2R.  It uses the batch flow instead of interactive flow, just
like COM_Net.

Dale Gindlesperger
Fleetwood Folding Trailers, Inc.






Bud Roble <BRoble@CharlesRobleConsulting.com>
Sent by: mapics-l-admin@midrange.com
11/05/02 05:16 PM
Please respond to mapics-l


        To:     "'mapics-l@midrange.com'" <mapics-l@midrange.com>
        cc:
        Subject:        RE: Maintaining Open Order Total for Customers


Dale,

Thanks for the input.   You first example wouldn't work in our case as we
don't want to deal with multiple customer numbers.   Here is the exact
situation.....   We have certain orders we key into the system that have
an
"undefined" due date.   We really have no idea when they will be shipped
and
in some cases, they never do.   We call these orders "Hold for release"
orders (HFR's).    These orders have been keyed into the system with a
special due date 01/01/39.   I know you're going to ask "what happens when
you get to the year 2039"  ;-)  What can I say.... I inherited this, but I
have to deal with it now.  We want the credit checking procedure to ignore
any open orders having this special due date.   In an ideal world, the
credit checking would occur in a single program somewhere and I would go
in
and modify the code to ignore the 01/01/39 dates when it's figuring out
the
value of the open orders in the system.    I've found an API (UMBCLC1R)
that
is for Customer Credit Checking but the Mapics support line told me this
is
a shell program and I would need to write a whole credit checking routine
from scratch myself.   In addition, if I was to put my own routine in this
API, they say I would need to turn off the Mapics credit checking.  I
don't
really want to do that.    The mod I need to make seems pretty simple on
the
surface; I just need to figure out where to make it and hopefully only in
one place.

Bud

-----Original Message-----
From: DaleGindlesperger@fft-inc.com [mailto:DaleGindlesperger@fft-inc.com]
Sent: Tuesday, November 05, 2002 1:37 PM
To: mapics-l@midrange.com
Subject: Re: Maintaining Open Order Total for Customers

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
We have what may be a similar situation.  Our dealers have multiple credit
limits, depending on the product they purchase.  We gave each dealer a
unique customer number for each product line.  To make it easier, we broke
the customer number in to a 6 and 2 format.  For example:

Campers:   12332110
Parts:          12332111
Trailers:      12332130

The common customer number in this instance would be 123321.  You can set
a different credit limit on each of the 8 digit customer numbers.

You can also do it in user exits.  We do some terms code overrides and
automatic credit approvals in the end-of-order user exits for certain
orders (promotional items and so on).  That's especially useful if you use
COM_Net, which doesn't allow for terms code entry and other special stuff.

Dale Gindlesperger
Fleetwood Folding Trailers, Inc.





Bud Roble <BRoble@CharlesRobleConsulting.com>
Sent by: mapics-l-admin@midrange.com
11/05/02 03:06 PM
Please respond to mapics-l


        To:     "'Mapics Mailing List (mapics-l@midrange.com)'"
<mapics-l@midrange.com>
        cc:
        Subject:        Maintaining Open Order Total for Customers


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
I have a need to filter out certain orders from being included in the Open
Order Totals for Customers.    Basically, I don't want certain orders to
be
counted against the customer's credit limit.     Can anyone tell me where
I
would look to make this modification?    I'm hoping Mapics had the
foresight
to place the logic in a single program somewhere.    I would love to be
able
to use a user exit, but that's probably pushing the envelope.   :-) Any
assistance would be greatly appreciated.

Bud Roble
(805)794-3027

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



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



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