Dear Sun Fen,
Thanks for your reply. This confirms what I was thinking. Although it looked promising a combination of fields that determine the tax group. I have not looked at the code yet. I first want to check whether it is a known problem or related to initialization issues like parameters. I am running axapta 3.0 SP3 including all hot fixes with no customization on the sales order. At least not in that area. When the tax group of a customer who has outstanding orders is changed, the outstanding order header and line tax group should not be changed. As a result of only changing the tax group in the customer record it does not. That is working correctly. For a customer with no outstanding orders when I type in the customer account code in the sales order header the tax group in the header is overwritten with the new tax group. I personally do not find this accepted behavior. Users can make mistakes. I find it correct when a new customer account is selected. Now in my environment the tax group is not overwritten for a customer with outstanding orders. But when I enter a new order for this customer the tax group is not defaulted from the customer but from somewhere else. Is someone running 3.0 sp3 with all hot fixes who experiences the same problem. regards, Danny --- In Axapta-Knowledge-Village@yahoogroups.com, "sunfen" <[EMAIL PROTECTED]> wrote: > Hi Danny, > > The sales tax group is defaulted from Customer master only and not from any setups such as > terms of deliveries. There must be something wrong with your code. > > > Regards, > Sun Fen > -----Original Message----- > From: "Danny Gaethofs" <[EMAIL PROTECTED]> > To: Axapta-Knowledge-Village@yahoogroups.com > Date: Thu, 27 Jan 2005 17:37:56 -0000 > Subject: [Axapta-Knowledge-Village] Re: Tax group not properly defaulted > > > > > > > Girish, > > > > All of it happens in the sales order. > > Even before something has been done with the sales order. > > That is why I am surprised. > > > > What I also notice is that when you are in the sales order header > > and go to the customer record, change the tax group. Then in the > > order header type in the customer code again the tax group is not > > defaulted. To me this seems to work correct, in that sense that I > > believe that values ones defaulted should not be overwritten. Unless > > another customer is selected. However in standard it overwrites the > > defaults when the customer code is entered again. Now in my > > customer's environment it does not. > > > > And when I create a new order it is not defaulting the value from > > the customer record, which I changed, but takes the old value. > > > > Can you elaborate a bit on the way it works with the terms of > > delveries. Is there somewhere a table that has the combination of > > tax group and delivery term? > > > > regards, > > Danny > > > > > > --- In Axapta-Knowledge-Village@yahoogroups.com, Girish B > > <[EMAIL PROTECTED]> wrote: > > > Hi danny, > > > Hope you have updated the tax group on the Customer > > > master. if you create the new sales order (manually) > > > for the customer then i am sure it picks up from the > > > customer master. But if you use the copy from journal > > > functionality then it would copy from the the order > > > which is used to copy. > > > Have you set the delivery terms? here we specify > > > the place of taxation and this also sometimes > > > determines the tax, depending on the conditions set.. > > > > > > hope these point will help you solve the problem. > > > > > > cheers, > > > Girish > > > > > > > > > --- Danny Gaethofs <[EMAIL PROTECTED]> wrote: > > > > > > --------------------------------- > > > > > > Dear all, > > > > > > When creating sales orders the tax group of a customer > > > is not > > > correct defaulted when there are existing orders for > > > the customer. > > > > > > When orders exist for a customer and the tax group is > > > changed in the > > > customer record, I noticed that when creating a new > > > order the tax > > > group is not defaulted from the customer record. It > > > looks as if it > > > is taken from existing orders which however seems > > > unlogic. > > > > > > > > > Has someone noticed this error before. Could it have > > > something to do > > > with caching. > > > > > > We are running axapta 3.0 with service pack 3 and all > > > hotfixes > > > installed. > > > > > > regards, > > > Danny Gaethofs > > > > > > > > > > > > > > > > > > Sharing the knowledge on Axapta. > > > > > > > > > > > > --------------------------------- > > > Yahoo! Groups Links > > > > > > To visit your group on the web, go to: > > > http://groups.yahoo.com/group/Axapta-Knowledge-Village/ > > > > > > To unsubscribe from this group, send an email to: > > > [EMAIL PROTECTED] > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! > > > Terms of Service. > > > > > > > > > > > > > > > > > > > > > ___________________________________________________________ > > > ALL-NEW Yahoo! Messenger - all new features - even more fun! > > http://uk.messenger.yahoo.com > > > > > > > > > > > > > > Sharing the knowledge on Axapta. > > Yahoo! Groups Links > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> What would our lives be like without music, dance, and theater? Donate or volunteer in the arts today at Network for Good! http://us.click.yahoo.com/Tcy2bD/SOnJAA/cosFAA/kGEolB/TM --------------------------------------------------------------------~-> Sharing the knowledge on Axapta. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Axapta-Knowledge-Village/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
