Document types are a hassle!

abc123

Active Member
In a sense that is. I understand and appreciate how document types work, but having to train your sales order entry people to know which document type should be used in each circumstance is a pain.

In addition, we have sales orders that are set up to handle transfers or regular sales orders. These require different applications to start. We also have different offsetting purchase order types that need to be created when the order is created for transfers. This requires a different application for each document type.

Now you can see what the users have to go through to enter sales orders. In our situation, we have about 8 different sales order applications that the user could open to enter a sales order. They each depend on who will be on the other end of the phone when they pick it up.

Even if we had one application for all orders, why are we still forced to enter a document type? In my opinion, it should default in based on the customer or customer group that is being selected in the sales order.

Does anyone else have this problem? I’d like to hear your opinions, good or bad, regarding this.
 
abc123,
you don't really have 8 different applications to enter your sales orders. there is actually only one sales order entry program: P4210.
the different menu options that have been set up for you actually have been set up so the program will run differently based upon what the user is going to do and it will also default in various information for the situation the user is in.
the reason for different document types is pretty simple. different document types go through different steps. for example, you probably would not ship something when you try to issue a simple credit order.
if you like you could give users one menu option for all order types. the system will allow you to override the order type but i think your users would find it to be much more work to do it that way.
Dave
 
abc123,

If you're willing to do a little development, you could create a single simple application that your Sales group can use, which would ask the questions necessary to determine the type of SO to create. Then, once they've entered the information (e.g. whether it's a transfer order, customer #, etc.), your application can call the appropriate version of P4210, based on this entered information. Just a thought.
 
you don't really have 8 different applications to enter your sales orders. there is actually only one sales order entry program: P4210. ****I am aware of that. I probably should have used the word application versions instead of applications. In real world speak, it is 8 applications.****

the different menu options that have been set up for you actually have been set up so the program will run differently based upon what the user is going to do and it will also default in various information for the situation the user is in.
the reason for different document types is pretty simple. different document types go through different steps. for example, you probably would not ship something when you try to issue a simple credit order. ****I understand why doc types exist. You need to look at this from the end user perspective, not the programmer perspective. If you were a user entering sales orders, I guarantee this setup would be very cumbersome for you to give quick customer service with.****

if you like you could give users one menu option for all order types. the system will allow you to override the order type but i think your users would find it to be much more work to do it that way. ****Unfortunately, we couldn't do it that way. You see the the P4210 application has something called processing options that are required to be defined before the application is opened. These are the options that handcuff our users into this network of sales order apps.****
 
I wanted to contribute my two cents worth on this one. I agree totally that
JDE missed the boat by not adding the ability to default in the sales order
type by customer. It seems like it would be an easy, productive
enhancement. But, in the meantime, there are techniques to consider that
might help.

1. Have you thought about using Flex Sales Accounting? This allows you to
book revenue and cost by customer category code values to different sub
accounts. I've seen a lot of situations where the client has document types
purely for accounting reasons. If so, then Flex AAIs will reduce all those
document types to just one.

2. Have you thought about using the Next Order Status Preference? This
allows you to setup slightly different order flows for different
combinations of customer number/item number. For example, if you had some
orders that needed an acknowledgement printed, you could use this preference
to bump these orders to a different status, and wouldn't need different
document types.

I think this is a great topic that affects hundreds of clients. If anyone
has any thoughts about how to reduce the number of document types, let's
hear them!

Andy Klee
www.JDEtips.com

PS. The processing option setup for document type is optional and you can
leave it blank. But it still isn't a good idea to require users to enter
the correct document type.



Andy Klee
www.JDETips.com
 
abc123, Eight different sales order doc's seems a bit much on the surface. It also sounds as if there is not a clear understanding of the doc types purposes, a training issue. Here are some hints that may ease some of your pain. If you have customers who regulary use a specific document type, create a customer list with their normal doc type that your CSR's can have available. This becomes an easy look up function. You may also want to assign speciific customers to specific CSR's. This helps enhance cumtomer satisfaction and response time (fewer questions, faster entry). Part of the implementation process is always review. Is it possible to route calls to CSR's based on customer needs (International vs domestic)? Ask your CSR's what they like and what needs improvement. Have them not only propose problems and issues, but also how they would solve the problem.

abc123 <[email protected]> wrote:you don't really have 8 different applications to enter your sales orders. there is actually only one sales order entry program: P4210. ****I am aware of that. I probably should have used the word application versions instead of applications. In real world speak, it is 8 applications.****the different menu options that have been set up for you actually have been set up so the program will run differently based upon what the user is going to do and it will also default in various information for the situation the user is in. the reason for different document types is pretty simple. different document types go through different steps. for example, you probably would not ship something when you try to issue a simple credit order. ****I understand why doc types exist. You need to look at this from the end user perspective, not the programmer perspective. If you were a user entering sales orders, I guarantee this setup would be very !
cumbersome for you to give quick customer se!
rvice with.****if you like you could give users one menu option for all order types. the system will allow you to override the order type but i think your users would find it to be much more work to do it that way. ****Unfortunately, we couldn't do it that way. You see the the P4210 application has something called processing options that are required to be defined before the application is opened. These are the options that handcuff our users into this network of sales order apps.****
--------------------------
To view this thread, go to:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=53730
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World® / XE mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards®

+ - - - - - - - - - - - - - - - - - - - - - - - -+


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.


World, OW B733X and Xe
 
All,
I agree with abc's underlying statement about switching applications: the end user can't stay on the same screen for all their data entry - this presents a challenge.
Using the same definition we used to have some 16 or so doc types - basically combinations of four dimensions: line of business (transfer, direct ship, ex-warehouse), affects cost of goods (for adjustments), affects sales price (for adjustments), affects inventory.
We challenged this and brought our total to four - primarily by using line type, to drive accounting, and advanced pricing (to zero costs and prices).
That said, we still have end users ask "why isn't there simply a drop down box at the top of the screen where I choose my doc type?". And our only answer to this point: "because that would be a major modification."

Cheers,
--Malcolm.
 
Re: RE: Document types are a hassle!

1.Have you thought about using Flex Sales Accounting? This allows you to book revenue and cost by customer category code values to different sub accounts. I've seen a lot of situations where the client has document types purely for accounting reasons. If so, then Flex AAIs will reduce all those document types to just one.
**** We have different doc types so we can separate and report our sales information, distinguish between sales orders and transfer orders, and accounting reasons. We also have a RBU preference set up for two of the order versions. Our order activity rules are different on just about every order type. Some of them need order quantity checks because they are uploaded from a subsystem and others have an invoice print step.

I’m not complaining about the value of the document type, it just seems to me that the program was written in a way that makes it cumbersome to use them from the end user perspective.****

2. Have you thought about using the Next Order Status Preference? This allows you to setup slightly different order flows for different combinations of customer number/item number. For example, if you had some orders that needed an acknowledgement printed, you could use this preference to bump these orders to a different status, and wouldn't need different document types.
**** 50,000 customers and 600 items. Sounds like a lot of work to set up. I imagine that you would set up a master document type and have it skip through different steps of the rules. Can this be done multiple times to the same order? For example, let’s say I create an order and want it to skip the second status and the fourth status, but hit the first, third, fifth and sixth. Can that be done? ****
 
Re: RE: Document types are a hassle!

The way the Next Order Status preference works (as far as reducing the number of tdocument types) is as follows:
1. It is only executed in Order Entry.
2. You can interweave different order flows as follows:

520 Sales Order Entry 540
520 Sales Order Entry 541 (for the orders bumped by the preference)
540 Pick Slip 560
541 Pick Slip 561
560 Ship Confirm 580
561 Ship Confirm 620
580 Invoice Print 620
620 Sales Update 999

So you can automatically bump certain customers orders so that Invoice Print is skipped, for example. A little awkward, but it works.

Andy Klee
www.JDEtips.com
 
Mike_Dupaix...

Eight different sales order doc's seems a bit much on the surface. It also sounds as if there is not a clear understanding of the doc types purposes, a training issue. **** A training issue? Everyone using our sales order entry system understands why there are different document types set up, what they don’t understand is why the system can’t determine which doc type to use based on the customer selected. Understanding why something works the way it does doesn’t make it right. ****

Here are some hints that may ease some of your pain. If you have customers who regularly use a specific document type, create a customer list with their normal doc type that your CSR's can have available. This becomes an easy look up function. **** The minimum size of a customer group for us is about 500. That wouldn’t be a fun list to do a lookup on. Nor is it the only problem. The problem is also that they have to spend time opening and closing applications to get to the right screen to start their entry. Asking them to open eight applications at the start of the day is just a work around. ****

You may also want to assign specific customers to specific CSR's. This helps enhance customer satisfaction and response time (fewer questions, faster entry). ****That’s an easy suggestion to make on the surface, but we’re a small shop in that sense. It is important for each of our reps to be able to handle any type of SO. ****

Thanks for the thought.
 
Re: RE: Document types are a hassle!

Andy,

Interesting concept. I'll put some thought into whether this will help us pare down our doc types. Although we will still be handcuffed in our sales reporting needs. I'll say again that I like the idea of having different doc types only after the original sales order has been created.

Marc
 
Re: RE: Document types are a hassle!

Have you thought about using Flex Sales Accounting? This allows you to book revenue and cost by customer category code values to different sub accounts. I've seen a lot of situations where the client has document types purely for accounting reasons. If so, then Flex AAIs will reduce all those document types to just one. ****I just reviewed this and determined that with the number of GL accounts that we use and how we use them, Flex accounting will not work for us. The object account isn't capable of flexing.****
 
RE: RE: Document types are a hassle!

Marc,

If you need to distinguish your ordertypes because of reporting requirements you may also have a look at a preference like 'end use' or one of the three 'user price codes'. These can be filled using the preference profiles or manually.
Use data selection in your reports on these attributes, might save also one or more document types.

Kind regards,

André Jille

Deloitte & Touche
Management & ICT Consultants
The Netherlands
 
Back
Top