Cathy Raissouni
member
Reged: 09/24/07
Last on: 06/18/09
Posts: 4
|
|
I am looking for information on how companies handle scenarios where the ship to address is overridden, but the geocode is not auto-updated to reflect this. How does your company, or a company you know of, deal with this scenario, so that tax is calculated correctly for each order without relying on the user to find the correct code? Any information would be greatly appreciated.
|
jjanowski
member
Reged: 01/03/02
Last on: 08/30/10
Posts: 109
Loc: USA/Michigan
|
|
The user has to verify the new address is an appropriate taxing jurisdiction. An address does NOT automatically equal a geocode. (It would be nice if it did)
You can always modify applications or API's to pull the first geocode but I would advise against this without challenging the business requirement.
--------------------
OneWorld B7333 -> EnterpriseOne 812, Qsoft, OnDemand/UPK, Vertex
#include <iostream.h> main(){cout << "Thanks";return 0;}//jjj
|
Tracy Gray
member
Reged: 11/28/05
Last on: 07/02/10
Posts: 6
|
|
Hi Cathy-
We are in the process of implementing Vertex with JDE. We ran across the same issue you described in this post. Did you find a way to apply a geocode to overriden addresses when entering a sales order? If so, I would appreciate any insight you might have to this problem.
Thanks,
Tracy
|
ErpRob
member
Reged: 12/12/00
Last on: 08/09/10
Posts: 129
Loc: Dallas, TX
|
|
I have this process fixed. It is a complicated modification but it works very well.
I have a custom file which has the following fields.
ZTO -From zip code
ZTH -To zip code
ADDS -State
CTY1 -City
COUN -County
VVG -Geo Code
Since vertex uses zip code ranges in order to make life easy, I duplicate the from zip code to make the fetches simple.
Thus if I have for example 75090 to 75092 in vertex. The file would have
75090 75092 etc…
75091 75092 etc..
75092 75092 etc…
The file gets cleared and recreated each time we get a vertex monthly update. The file is reloaded using the following vertex files LOCCITY, LOCCOUNTY and LOCSTATE.
On the order entry screen the GEO code field is protected so the users cannot change the geo code. When the user clicks OK or goes into the drop shipment address screen. The shipping order address or the A/B address is pulled and checked against this table. I pull the geo code based on the address. If the address cannot be found in the custom GEO code table, the user gets an address error and it must be corrected before being able to exit the order address window.
I also run a program before the invoices are printed to be sure the right geo code is on the order and matches the address. If something is not right, I put it on TX i.e. TAX hold until the information can be double checked. This ensure the customer gets taxed properly and reduces the amount of credit and re-bills.
There are other special aspects within this mod for tax exempt customers. But this works properly and I get to validate the address so that helps with shipping before it gets to our shipping stations.
The modification is also in the address book when the tax information is selected for the customer.
If someone needs more information on this, you can email me and I can answer any questions.
Thanks
Rob
|
cschwobe
member
Reged: 01/24/01
Last on: 06/08/10
Posts: 66
|
|
Hi
Can you tell me what level of JDE you are running. We are using JDE ERP8 and have this same issue. would your modifications work for us? If so how code we look at those modifications
thanks for your help
Carol
--------------------
Carol Schwobe
One World ERP8
AS 400
|
ErpRob
member
Reged: 12/12/00
Last on: 08/09/10
Posts: 129
Loc: Dallas, TX
|
|
This modification is currently setup on OW version 8.10. However it should work on any release of JDE (World and Oneworld) because JDE and vertex use GEO codes to control everything. Geo codes have been around for a while.
Since the basic idea behind the modification is to program the system to pick the right GEO code based on the address (city, county, state & Zip) or the order address. Ensure the address is being validated against the custom table. The user is only responsible to ensure the right address is being entered. Since we get vertex updates every month with the GEO codes, we rebuild the custom table after the vertex tax updates are loaded.
As long if you create the custom table listed above, refresh it monthly, remove user control of the GEO code and validate all address information against it. This should all works out great for you.
Thanks
Rob
|
cschwobe
member
Reged: 01/24/01
Last on: 06/08/10
Posts: 66
|
|
You're right this should work for any level. I'm a little confused on your table. There is only 1 zip code entered with the address, how do I read this table to get the geo code. The table seems to have 2 zip codes on it.
--------------------
Carol Schwobe
One World ERP8
AS 400
|
ErpRob
member
Reged: 12/12/00
Last on: 08/09/10
Posts: 129
Loc: Dallas, TX
|
|
when creating the custom file used for searching/validation you need to use the following vertex file:
LOCSTATE (this file needs a new index for the builds)
LOCCOUNTY
LOCCITY
In LOCCITY, vertex uses zip codes ranges in fields XICZI00001
XICZI00002.
To make the searching easier from the JDE side. I simply explode the records. So in LOCCITY you have
75023 to zip 75026
The custom table would get for example the following after a rebuilt
JLZTO JLZTH JLADDS JLCTY1 JLCOUN JLVVG
75023 75026 TX PLANO COLLIN 440852310
75024 75026 TX PLANO COLLIN 440852310
75025 75026 TX PLANO COLLIN 440852310
75026 75026 TX PLANO COLLIN 440852310
The index would be
JLADDS
JLCTY1
JLCOUN
JLZTO
The file floats around 87,500 on any given month. This process has worked out great for us and eliminated a lot of drop shipment mistakes and customer setup errors in the address book.
If the address is not in this table, it cannot be used. If the user does not believe me, I have them check USPS web site to prove the address they have is not correct.
Rob
|
cschwobe
member
Reged: 01/24/01
Last on: 06/08/10
Posts: 66
|
|
thank you very much. One last question, do you do EDI orders? I'm thinking I would just put the mode in R47011 as well as the P4201
--------------------
Carol Schwobe
One World ERP8
AS 400
|
ErpRob
member
Reged: 12/12/00
Last on: 08/09/10
Posts: 129
Loc: Dallas, TX
|
|
Yes we have EDI and the EDI orders use the table on the inbound. But, because I do not want to stop the EDI process for a bad address, we have a special batch program that reviews all open orders (mostly for EDI) to ensure the orders have the right GEO Code. If no code is found or the wrong code is somehow entered because the user ignored the message (and forced close the OneWorld window), we put the order on Tax hold (i.e. TX hold). The order address must be corrected and the geo code pulled for a ticket to print. Otherwise if you just release the hold without fixing the order. The order will simply go back on hold on the next pick ticket run.
I hope this answers you question.
Rob
|
Previous
Index
Next
Threaded
Vertex Geocodes and F4006 Ship To Address Override - How To Handle So Order Is Correctly Taxed?
Edit
Reply
Quote
Re: Vertex Geocodes and F4006 Ship To Address Override - How To Handle So Order Is Correctly Taxed?
