Due to a recent surge in the amount of Anonymous comment spam, I am disabling anonymous comments. If you'd like to leave a comment, you will need to register with blogger.com.
Sorry for this inconvenience.
DB
Monday, November 05, 2007
Monday, October 08, 2007
AXUG Summit 2007
As our post-implementation deployment is wrapping up, I am going to make a point of posting more to this blog now that my time is freeing up to do other things. On October 15-17, I will be attending the AXUG Summit in Orlando, FL. There appears to be some great tracks to attend. I will be attending the performance track to see if I can't return with some knowledge on how to speed up some slowness in our invoicing process. If any of you will be attending, let me know and I'll be looking to speak to you.
Just to fill you in now that things have calmed down, here's our implementation story:
My lack of posts for the last four months have not been because I was too lazy but rather because of being overwhelmed with work. Our implementation was rocky but we made it work and persevered as a result. We have a VP who in my opinion is always a stellar performer. He's the sort of guy that even if everyone is looking at doom and gloom, his head is still held very high. If you ever see this guy looking down you better cover your head because the sky is surely falling. In my opinion he had a lot to do with the project's success. When all seemed as if it were about to fall apart, he was there to encourage all of us on the project and cheer us towards success.
My shop is pretty small, less than eight regular IT employees and due to some recent departures is even smaller now. I was and am the only full-time developer for AX in our company during our implementation. I also have been the only person to become technically fluent with AX from installation to configuration to troubleshooting, etc. Why was our implementation this way? To some extent I can blame it on a lean budget but I can also point to our partner.
Hind sight is always 20-20, of course.
We were new to AX. I had just been hired in February 2006 and had the VPC of AX 4.0 Pre-Release given to me in June, no manuals, no documentation, just a job of learning it. Our Project Team was a who's who of the shining stars in the company, one from each functional area of the company. Not one of them had ever heard of AX, and only two or three had ever worked with or knew what an ERP system was. I was the black sheep being from a technical environment and actually having a two month head start on learning it.
Our partner rolled in and immediately setup a project timeline and a go-live date, which we ultimately missed and had to reschedule three times. All seemed as if it were going well until we began official software modification in October. Developer resources from the partner were not cutting it. Each of the three guys who all in total spent less than two weeks with us seemed to have no real idea what was going on. These guys were asking me questions about AX... a scary thought. But the more scary thought was that I actually had the answers. As a result we determined very quickly that either the seasoned resources were tied up (as we were being told, although each of the three guys we received were 'Senior Developers', or seasoned developers did not exist - my personal belief). Before long into the development/modification phase, we hired a previous contractor of another in-house developed system and cut a lower hourly wage for me to teach him AX and X++ and have him at our disposal as needed. This turned out to be a better decision than the partner's own developers.
In the end, we were still allowing our partner to make architectural decisions since they werethe experts. They made decisions that I even knew were terrible although my experience in AX was lacking. At the time those design decisions were made, we accepted them and moved forward. Now looking back we all wished we had challenged their solutions.
I share a glimpse into our implementation to convey a notion to you if you are the customer: Know AX.
While I'm sure most implementations are packaged deals (like ours) where a team arrives and educates you first and then immediately begins the project, I suggest a different approach. If you can work it out, install the product first, allow your technical people and key functional people access to it and all of the training manuals for no less than a month. They need to understand what the product is, how it works in its pure state. Then and only then start the implementation project. If you as the customer rely on your partner 100% you, too, will experience modifications/business processes that were implemented but not fully thought out. The ramifications can be from as simple as a quick rewrite of a function to a complete overhaul in the next major AX release.
If you are a partner, I encourage you to encourage your client to learn what AX has to offer and how it works from the beginning. Even if the Sales Order process looks nothing like what your customer will expect in the end, still encourage them to create an Item that they sell, create a customer, create the ledger accounts, execute a sales order. Make them understand how AX works before you begin consulting them on Architectural changes. In the end you will profit from a long-lasting business relationship rather than a continous finger-pointing who-did-what-wrong conflict.
And in the end, isn't your goal a happy customer and continuous reference?
Hope this helps those of you either in or preparing to enter an AX implementation, or for that matter any ERP or large-scale software implementation project.
DB
P.S. Are we happy with AX? Of course we are, but we weren't there on July 1st, the day we went live. Much massaging, cleanup, multiple phone calls to Fargo, several 36 hour+ days, and six weeks of no weekends or weekdays off had to be experienced before happiness was achieved but all in all we have learned from our mistakes and it has made us a better shop in the end.
Just to fill you in now that things have calmed down, here's our implementation story:
My lack of posts for the last four months have not been because I was too lazy but rather because of being overwhelmed with work. Our implementation was rocky but we made it work and persevered as a result. We have a VP who in my opinion is always a stellar performer. He's the sort of guy that even if everyone is looking at doom and gloom, his head is still held very high. If you ever see this guy looking down you better cover your head because the sky is surely falling. In my opinion he had a lot to do with the project's success. When all seemed as if it were about to fall apart, he was there to encourage all of us on the project and cheer us towards success.
My shop is pretty small, less than eight regular IT employees and due to some recent departures is even smaller now. I was and am the only full-time developer for AX in our company during our implementation. I also have been the only person to become technically fluent with AX from installation to configuration to troubleshooting, etc. Why was our implementation this way? To some extent I can blame it on a lean budget but I can also point to our partner.
Hind sight is always 20-20, of course.
We were new to AX. I had just been hired in February 2006 and had the VPC of AX 4.0 Pre-Release given to me in June, no manuals, no documentation, just a job of learning it. Our Project Team was a who's who of the shining stars in the company, one from each functional area of the company. Not one of them had ever heard of AX, and only two or three had ever worked with or knew what an ERP system was. I was the black sheep being from a technical environment and actually having a two month head start on learning it.
Our partner rolled in and immediately setup a project timeline and a go-live date, which we ultimately missed and had to reschedule three times. All seemed as if it were going well until we began official software modification in October. Developer resources from the partner were not cutting it. Each of the three guys who all in total spent less than two weeks with us seemed to have no real idea what was going on. These guys were asking me questions about AX... a scary thought. But the more scary thought was that I actually had the answers. As a result we determined very quickly that either the seasoned resources were tied up (as we were being told, although each of the three guys we received were 'Senior Developers', or seasoned developers did not exist - my personal belief). Before long into the development/modification phase, we hired a previous contractor of another in-house developed system and cut a lower hourly wage for me to teach him AX and X++ and have him at our disposal as needed. This turned out to be a better decision than the partner's own developers.
In the end, we were still allowing our partner to make architectural decisions since they were
I share a glimpse into our implementation to convey a notion to you if you are the customer: Know AX.
While I'm sure most implementations are packaged deals (like ours) where a team arrives and educates you first and then immediately begins the project, I suggest a different approach. If you can work it out, install the product first, allow your technical people and key functional people access to it and all of the training manuals for no less than a month. They need to understand what the product is, how it works in its pure state. Then and only then start the implementation project. If you as the customer rely on your partner 100% you, too, will experience modifications/business processes that were implemented but not fully thought out. The ramifications can be from as simple as a quick rewrite of a function to a complete overhaul in the next major AX release.
If you are a partner, I encourage you to encourage your client to learn what AX has to offer and how it works from the beginning. Even if the Sales Order process looks nothing like what your customer will expect in the end, still encourage them to create an Item that they sell, create a customer, create the ledger accounts, execute a sales order. Make them understand how AX works before you begin consulting them on Architectural changes. In the end you will profit from a long-lasting business relationship rather than a continous finger-pointing who-did-what-wrong conflict.
And in the end, isn't your goal a happy customer and continuous reference?
Hope this helps those of you either in or preparing to enter an AX implementation, or for that matter any ERP or large-scale software implementation project.
DB
P.S. Are we happy with AX? Of course we are, but we weren't there on July 1st, the day we went live. Much massaging, cleanup, multiple phone calls to Fargo, several 36 hour+ days, and six weeks of no weekends or weekdays off had to be experienced before happiness was achieved but all in all we have learned from our mistakes and it has made us a better shop in the end.
Tuesday, July 10, 2007
AIF Email Survey
As you may know, my company went live on AX on July 1st. As we are still working to fully stabilize AX and clean up any loose ends, I am still working to tweak AIF and am 90% toward our goal. As with any application, you can test like there's no tomorrow, test large loads, small loads, erroneous loads, and everything in between but there's no substitute for real life.
I'd like to conduct an email survey for anyone this is applicable to and willing to share usage statistics. I'd like to know how your company is fairing with AIF in a live environment. I'm looking for AIF data only, no Commerce Gateway or custom asciiIO/commaIO input/output processes.
If you're interested in participating, please send an email to: david.bowles@yahoo.com. In the subject line, please put 'AIF Survey', without the quotes. In the body, please copy and paste this template with the information you're willing to share filled out:
***************************
Months Running Live on AIF:
Number of Actions Live on AIF:
Number of 'Out of Box' Actions Live on AIF:
Number of 'Customized From Scratch' Actions Live on AIF:
Number of Sales Order-based Actions on AIF:
Number of Purchase Order-based Actions on AIF:
Number of Production-based Actions on AIF:
Number of Inventory-based Actions on AIF:
Number of Accounting-based (AR/AP/GL) Actions on AIF:
Number of external Systems interfacing AX through AIF:
Using AIF to communicate via EDI? Yes or No
If Yes, What EDI Format and Version do you use:
If Yes, also what Message Brokering/Transformation software do you use, if any:
On a daily average, how many errors do you encounter in your AifQueueManager needing correction?
On a daily or monthly average (please specify which) how many AX AIF transactions do you receive? Inbound _____ Outbound _____
What frequency do you process AIF transactions? Minutely, Quarter Hourly, Hourly, Bi-Daily, Nightly, Monthly
How would you classify the performance of AIF in producing/consuming transactions? Slow, Medium, Fast
Based upon your answer above, does AIF's speed meet your expectations? Yes or No
If AIF's speed is Slow or Medium or it's speed does not meet your expectations, have youworked with a DBA on optimizing database transactions during AIF execution to speed upthe transactions?
If so, in comparison prior to the optimization, does AIF run faster, slower, or the same?
What type of business are you?
***************************
I'd like to thank you in advance for sharing this. After a week or so, I'll post the results of the survey. You're welcome to send this to me totally anonymously. I will not be posting any information regarding the submitter. I'm interested in how many implementations are actually using AIF and to what extent as I'm sure all of you who are using it are interested as well.
DB
I'd like to conduct an email survey for anyone this is applicable to and willing to share usage statistics. I'd like to know how your company is fairing with AIF in a live environment. I'm looking for AIF data only, no Commerce Gateway or custom asciiIO/commaIO input/output processes.
If you're interested in participating, please send an email to: david.bowles@yahoo.com. In the subject line, please put 'AIF Survey', without the quotes. In the body, please copy and paste this template with the information you're willing to share filled out:
***************************
Months Running Live on AIF:
Number of Actions Live on AIF:
Number of 'Out of Box' Actions Live on AIF:
Number of 'Customized From Scratch' Actions Live on AIF:
Number of Sales Order-based Actions on AIF:
Number of Purchase Order-based Actions on AIF:
Number of Production-based Actions on AIF:
Number of Inventory-based Actions on AIF:
Number of Accounting-based (AR/AP/GL) Actions on AIF:
Number of external Systems interfacing AX through AIF:
Using AIF to communicate via EDI? Yes or No
If Yes, What EDI Format and Version do you use:
If Yes, also what Message Brokering/Transformation software do you use, if any:
On a daily average, how many errors do you encounter in your AifQueueManager needing correction?
On a daily or monthly average (please specify which) how many AX AIF transactions do you receive? Inbound _____ Outbound _____
What frequency do you process AIF transactions? Minutely, Quarter Hourly, Hourly, Bi-Daily, Nightly, Monthly
How would you classify the performance of AIF in producing/consuming transactions? Slow, Medium, Fast
Based upon your answer above, does AIF's speed meet your expectations? Yes or No
If AIF's speed is Slow or Medium or it's speed does not meet your expectations, have youworked with a DBA on optimizing database transactions during AIF execution to speed upthe transactions?
If so, in comparison prior to the optimization, does AIF run faster, slower, or the same?
What type of business are you?
***************************
I'd like to thank you in advance for sharing this. After a week or so, I'll post the results of the survey. You're welcome to send this to me totally anonymously. I will not be posting any information regarding the submitter. I'm interested in how many implementations are actually using AIF and to what extent as I'm sure all of you who are using it are interested as well.
DB
Friday, June 01, 2007
No, I haven't abandoned this blog...yet! :-)
Hello All,
I apologize for my nearly two month delay on posting any new updates to the blog. I've been incredibly busy, but isn't everyone? We pushed back the go-live to July 1st due to some 'technical' difficulties - not AX related. In the meantime I've been doing a lot of testing and developing some 'new requirements' also.
To top it all off, I have also been preparing for a wedding as I'll be hanging up my bachelor's cap once and for all on June 16, therefore, I'll be out of contact from June 15 through June 24. Once I get back to the states, I'll be sure to respond to any messages you email to me. The week of June 24th I will be preparing for our July 1st go-live, so I'll be unavailable mostly that week and the week following. Once we get AX stabalized I will be back on board making regular posts.
I can't really think of anything new to talk about in terms of Dynamics AX 4.0. I have been working on some simple data exports outside of AIF using the standard asciiIO/commaIO classes. I am finding that AIF works better with smaller amounts of records rather than larger. We have a couple of outbound files that exports more than 60,000 records. We are seeing minutes worth of difference between AIF and asciiIO exports. I'm hoping that Microsoft realizes an opportunity to optimize the AIF for larger record loads in a later release of AX.
Also, I want to thank everyone for their support. I get emails and instant messages daily from you guys and I'm glad to help as much as possible. I look forward to talking to each of you soon!
David Bowles
I apologize for my nearly two month delay on posting any new updates to the blog. I've been incredibly busy, but isn't everyone? We pushed back the go-live to July 1st due to some 'technical' difficulties - not AX related. In the meantime I've been doing a lot of testing and developing some 'new requirements' also.
To top it all off, I have also been preparing for a wedding as I'll be hanging up my bachelor's cap once and for all on June 16, therefore, I'll be out of contact from June 15 through June 24. Once I get back to the states, I'll be sure to respond to any messages you email to me. The week of June 24th I will be preparing for our July 1st go-live, so I'll be unavailable mostly that week and the week following. Once we get AX stabalized I will be back on board making regular posts.
I can't really think of anything new to talk about in terms of Dynamics AX 4.0. I have been working on some simple data exports outside of AIF using the standard asciiIO/commaIO classes. I am finding that AIF works better with smaller amounts of records rather than larger. We have a couple of outbound files that exports more than 60,000 records. We are seeing minutes worth of difference between AIF and asciiIO exports. I'm hoping that Microsoft realizes an opportunity to optimize the AIF for larger record loads in a later release of AX.
Also, I want to thank everyone for their support. I get emails and instant messages daily from you guys and I'm glad to help as much as possible. I look forward to talking to each of you soon!
David Bowles
Thursday, April 12, 2007
Two 'Colorful' Blog Entries of Notability
I have been extremely busy lately with getting ready for our tentative go-live date of May 1, but tonight I took a few minutes to look around at other AX blogs out on the net and I found two entries from two different outstanding AX community contributors that I wanted to pass on to you in case you do not check their blogs often enough (which I highly advise to do daily):
Kamal's entry on Graph creation in AX:
http://casperkamal.spaces.live.com/blog/cns!9138ED475277CD63!262.entry
Arijit's entry on Color-coding Grid Lines in AX:
http://daxguy.blogspot.com/2007/04/coloring-grids-in-dax.html#links
I will be implementing both of these HowTo's in our implementation once I get my head above water to begin doing some aesthetically pleasing mods to AX.
Thank you Kamal and Arijit in sharing these helpful tips. These explanations are things that I would never have thought to ask the possibility about, mostly due to my tunnel vision toward May 1 :-).
DB
Kamal's entry on Graph creation in AX:
http://casperkamal.spaces.live.com/blog/cns!9138ED475277CD63!262.entry
Arijit's entry on Color-coding Grid Lines in AX:
http://daxguy.blogspot.com/2007/04/coloring-grids-in-dax.html#links
I will be implementing both of these HowTo's in our implementation once I get my head above water to begin doing some aesthetically pleasing mods to AX.
Thank you Kamal and Arijit in sharing these helpful tips. These explanations are things that I would never have thought to ask the possibility about, mostly due to my tunnel vision toward May 1 :-).
DB
Sunday, April 01, 2007
MVP Award
I want to thank anyone who participated in my nomination as a Microsoft MVP in Dynamics AX. I am very thankful and gracious to have been awarded such a prestigious honor especially regarding a product that I have thoroughly enjoyed working with. I hope over the last year from my early beginning in Dynamics AX in June through my gained experience in AIF Configuration and Modifications that I have enlighted each and everyone who has viewed my blog in some shape or another. If I haven't, I will continue to strive to bring information forward so that everyone may benefit. And as with any project, you never stop learning and I am as happy to give knowledge as I am to receive it.
Thank you,
David Bowles
Thank you,
David Bowles
Thursday, March 29, 2007
XML File Size limitation using FindList AIF Actions
If you develop a findList Action in AX AIF and your dataset is going to be bigger than about 3MB, you will need to follow some steps within the AX 4.0 release notes. Search through it and find and execute the steps to add/modify the 'maxbuffersize' registry key.
Thursday, March 22, 2007
Passed!
I passed the AX 4.0 Development Intro exam. There were a couple of questions that made me sweat but for the most part it was everything most developers would deal with on a daily basis.
DB
DB
Testing Today...
Sorry for the delay since my last entry, I've been tied up working on this last stretch of testing and development before we go live. I needed a slight break today so I scheduled an exam at lunch. I will be taking the MB6-508 AX 4.0 Development Introduction Exam. I'm excited and ready to get this one behind me and will be hoping for Prometric to release the AX 4.0 MorphX Solution Development Exam soon...
David
David
Tuesday, March 06, 2007
Setting AIF To Output All Documents on Outbound Transactions
If you develop an outbound AIF transaction and determine when you execute it that not all the records you are expecting are exporting, check the 'Limit Number of Documents' field in your AIF setup.
This field can be found by first opening the 'Endpoints' form in Basic->Setup->Application Integration Framework, then highlighting the Endpoint in question, clicking 'Action Policies', highlighting the outbound action in question, clicking the 'Configure' button, and clicking the 'Setup' tab.
By default, this field is set to 'Yes', which means that AIF will only output the first 1000 records of any AIF outbound transaction where there are more than 1000 records.
Setup Tab of Action Policies Configure Form
This field can be found by first opening the 'Endpoints' form in Basic->Setup->Application Integration Framework, then highlighting the Endpoint in question, clicking 'Action Policies', highlighting the outbound action in question, clicking the 'Configure' button, and clicking the 'Setup' tab.
By default, this field is set to 'Yes', which means that AIF will only output the first 1000 records of any AIF outbound transaction where there are more than 1000 records.
Setup Tab of Action Policies Configure FormMicrosoft product screen shot(s) reprinted with permission from Microsoft Corporation.
Wednesday, February 07, 2007
Installing Dynamics AX 4.0 RTM Side-By-Side with 4.0 SP1
I haven't seen any real documentation on how run 4.0 RTM and 4.0 SP1 side-by-side, so I will address the steps that I took to make this happen. I don't believe that this configuration is supported by Microsoft, so you should only do this in a test or development environment (like I am doing) and make sure you have a backup before proceeding with these steps:
1.) Backup the DB of the environment you are trying to duplicate and upgrade to SP1.
2.) Backup the entire Application folder of the environmnet you are trying to duplicate and upgrade to SP1. If you don't know what or where your Application folder is, you probably should proceed any further.
3.) If you have a 4.0 RTM client on the server where your AOS and File Server is located, you must install it.
4.) Make a copy of your Common Folder in the Microsoft Dynamics\4.0\Server\Common location and call it 'Common RTM'. This will allow you to still configure the 4.0 RTM server environments. Otherwise, you will have problems with the new configuration applet saving the RTM configs correctly since SP1 introduces new Clustering settings.
5.) Install Dynamics AX 4.0 SP1, using the steps in the Microsoft Dynamics AX 4.0 SP1 Upgrade Documentation, specifically page 8 and page 9. (Note only installing the Object Server and File Server and possibly the Dynamics AX 4.0 SP1 client if you want to be able to open ONLY the Dynamics AX 4.0 SP1 environment). Note that on Page 9, point #3, you should not include the axsys.aod file in the files you move to Application\Appl\Standard\Old - this will stop you from being able to create an Upgrade Project.
6.) Before Starting the AOS Service, open the Dynamics AX Server Configuration Utility and import/create a new server configuration that puts the new 4.0 SP1 upgraded environment on a different port than your Dynamics AX 4.0 RTM environment.
7.) Start the AOS Service as indicated on the Microsoft Dynamics 4.0 SP1 upgrade document on page 9 point #5. You can continue on with Microsoft's approved steps from this point.
The biggest two points that I can stress about attempting this is:
A.) BACKUP, BACKUP, BACKUP
B.) Don't forget to make a copy of the Common Folder. as stated in #4 above. If you forget this step and try to open a Dynamics AX 4.0 RTM Server configuration file with the Dynamics AX 4.0 SP1 Server configuration applet and save it, you will hose up your server service the next time you stop and start that server service.
Remember, Microsoft does not endorse my steps. These steps worked great for me but may not work so great for you. Please backup and plan accordingly for issues. Please do not take your issues with these steps to Microsoft.
1.) Backup the DB of the environment you are trying to duplicate and upgrade to SP1.
2.) Backup the entire Application folder of the environmnet you are trying to duplicate and upgrade to SP1. If you don't know what or where your Application folder is, you probably should proceed any further.
3.) If you have a 4.0 RTM client on the server where your AOS and File Server is located, you must install it.
4.) Make a copy of your Common Folder in the Microsoft Dynamics\4.0\Server\Common location and call it 'Common RTM'. This will allow you to still configure the 4.0 RTM server environments. Otherwise, you will have problems with the new configuration applet saving the RTM configs correctly since SP1 introduces new Clustering settings.
5.) Install Dynamics AX 4.0 SP1, using the steps in the Microsoft Dynamics AX 4.0 SP1 Upgrade Documentation, specifically page 8 and page 9. (Note only installing the Object Server and File Server and possibly the Dynamics AX 4.0 SP1 client if you want to be able to open ONLY the Dynamics AX 4.0 SP1 environment). Note that on Page 9, point #3, you should not include the axsys.aod file in the files you move to Application\Appl\Standard\Old - this will stop you from being able to create an Upgrade Project.
6.) Before Starting the AOS Service, open the Dynamics AX Server Configuration Utility and import/create a new server configuration that puts the new 4.0 SP1 upgraded environment on a different port than your Dynamics AX 4.0 RTM environment.
7.) Start the AOS Service as indicated on the Microsoft Dynamics 4.0 SP1 upgrade document on page 9 point #5. You can continue on with Microsoft's approved steps from this point.
The biggest two points that I can stress about attempting this is:
A.) BACKUP, BACKUP, BACKUP
B.) Don't forget to make a copy of the Common Folder. as stated in #4 above. If you forget this step and try to open a Dynamics AX 4.0 RTM Server configuration file with the Dynamics AX 4.0 SP1 Server configuration applet and save it, you will hose up your server service the next time you stop and start that server service.
Remember, Microsoft does not endorse my steps. These steps worked great for me but may not work so great for you. Please backup and plan accordingly for issues. Please do not take your issues with these steps to Microsoft.
Quick Tip Regarding DB Synchronization Errors
I'm sure most Dynamics AX admins/developers are aware of this but I decided to post it anyway. I didn't know how to fix this error when I encountered it during an attempted upgrade to 4.0 SP1 and also one of the Dynamics AX Technical contractors I worked with on setting up Dynamics AX back in August 2006 also didn't know how to fix the problem and he had worked with Dynamics AX since 2.5 was released.
If you encounter Synchronization errors, view the Application Event Log to determine what caused the error. In my case, there were two tables that contained duplicate data in key fields within multiple records. Because this data was part of the DMO company and there were no other records that were part of any company in use, I simply deleted the tables and re-synchronized. If your records are part of live data, I would advise attempting to correct the anomolies within the database and re-synchronizing.
Hope this helps!
Monday, January 29, 2007
X12 EDI 857/856 Documents
Is anyone utilizing 857 or 856 ASN with their EDI processes in AX/Axapta? It appears that BizTalk doesn't support this out of the box and neither does Covast EDI Accelerator. If so, please send me an email and tell me how you implemented this document to integrate seamlessly with your AX install.
Thanks in Advance!
David
Thanks in Advance!
David
Monday, January 22, 2007
Miscellaneous Topics
I haven't posted much because of my lack of time since we're so close to go-live, but I wanted to at least add one tonight. I don't have much but here's a couple of things I have found since I last posted:
Microsoft released an AIF Whitepaper in December that covers just about everything I have posted on my blog regarding AIF configuration. I'm posting the link here because I haven't seen any postings about it on other Dynamics blogs: https://mbs.microsoft.com/customersource/support/documentation/whitepapers/DAX_AIF_Config.htm
We have almost finished all of our AIF development. Now we are concentrating on developing the Invoice output process but finding a slight difficulty due to our interaction with X12 EDI. The X12 version 4010 857 Advance Shipment Notice / Invoice requires that the ASN information appear in a hierarchical format that is similar to:
Shipment
Order
Pallet
Item
The complications with translating to this data structure is that the AIF produces a relational data structure, of which is based upon a Sales Table header, Sales Table detail, and Shipment detail record. For logistical efficiency purposes, the 857 is setup to be hierarchical because you could have a single line item split among one or more Pallets because of a physical limitation on the nunber of items that will fit on one pallet. In order to accommodate for the hierarchical structure, you have to modify AX's functionality, specifically the Shipments table. Within this table you have to add Trailer, Bill Of Lading, Pallet, Item, and Quantity data.
Due to the lack of direct support for X12 4010 EDI Transaction Sets from BizTalk, we decided to utilize MessageWay Solutions MessageWay Managed File Transfer application. It's been a great fit for us since it already has all X12, EDIFACT, and SWIFT EDI formats already integrated into the product. With minimal BASIC programming experience, you can extend the mapping capability past it's basic drag and drop functionality. This also worked much better for us because we wouldn't need a .NET programming on-site to develop C# or VB.NET mapping/translation applets for BizTalk. Although I was not able to get on the testing list, BizTalk 2006 R2 is in Beta now and it reported has all the EDI transaction sets integrated in it.
Finally, I registered for Convergence on Friday. I'm looking forward to attending as this will be my first time. On top of attending MS Convergence, I will also be attending the AXUG Pre-Conference taking place on Sunday afternoon. I encourage everyone to either join AXUG personally or encourage their company to become active in AXUG and attend their regional events.
Microsoft released an AIF Whitepaper in December that covers just about everything I have posted on my blog regarding AIF configuration. I'm posting the link here because I haven't seen any postings about it on other Dynamics blogs: https://mbs.microsoft.com/customersource/support/documentation/whitepapers/DAX_AIF_Config.htm
We have almost finished all of our AIF development. Now we are concentrating on developing the Invoice output process but finding a slight difficulty due to our interaction with X12 EDI. The X12 version 4010 857 Advance Shipment Notice / Invoice requires that the ASN information appear in a hierarchical format that is similar to:
Shipment
Order
Pallet
Item
The complications with translating to this data structure is that the AIF produces a relational data structure, of which is based upon a Sales Table header, Sales Table detail, and Shipment detail record. For logistical efficiency purposes, the 857 is setup to be hierarchical because you could have a single line item split among one or more Pallets because of a physical limitation on the nunber of items that will fit on one pallet. In order to accommodate for the hierarchical structure, you have to modify AX's functionality, specifically the Shipments table. Within this table you have to add Trailer, Bill Of Lading, Pallet, Item, and Quantity data.
Due to the lack of direct support for X12 4010 EDI Transaction Sets from BizTalk, we decided to utilize MessageWay Solutions MessageWay Managed File Transfer application. It's been a great fit for us since it already has all X12, EDIFACT, and SWIFT EDI formats already integrated into the product. With minimal BASIC programming experience, you can extend the mapping capability past it's basic drag and drop functionality. This also worked much better for us because we wouldn't need a .NET programming on-site to develop C# or VB.NET mapping/translation applets for BizTalk. Although I was not able to get on the testing list, BizTalk 2006 R2 is in Beta now and it reported has all the EDI transaction sets integrated in it.
Finally, I registered for Convergence on Friday. I'm looking forward to attending as this will be my first time. On top of attending MS Convergence, I will also be attending the AXUG Pre-Conference taking place on Sunday afternoon. I encourage everyone to either join AXUG personally or encourage their company to become active in AXUG and attend their regional events.
Subscribe to:
Posts (Atom)