I have a problem with circularity in BOM.
I want use same Item number with different Color in BOM.
Is this possible?
Is there any way in AX2012 to handele BOM like this?
It's important to have same Item Number In Metalproduction and in Paitshop. Only property Color shold change...
should be included in
Should not be an issue, as Color is a product dimension. When you have a different color specified, this is treated as a distinct product variant -> meaning Item 100 RED is not the same as Item 100 BLUE etc. So, you can have distinct BOMs for each, referencing different variations.
It is not possible in AX to use an item in the BOM of the same item. The 2 major issues are the BOM circularity check and master planning, which both do a circularity check purely on itemId, not on dimensions.
We've been struggling with this since years in situations where e.g. metal strips of length X are cut from metal strips of length Y, where both are variants from the same item with different size dimension. Other example is exactly the setup described above where the color of a piece is changed through overpainting...
By the way, the fact that AX does not include dimensions in the circularity check also has a huge performance impact if you have lots of variants of the same item, each variant with its own BOM (e.g. generated by product builder)...
We've developed modifications in AX2009 to overcome this, but very complex and not yet migrated to AX2012. I did however try the circularity in AX2012 and the limitations are exactly the same as in earlier versions.
Regarding the modifications to AX2009. Is it possible you can post them?
I think you should consider to create such databases as *metadatas*, where each item self registred all datas needed from creation to system execution. The tinking over that type of management is to compress datas *volubility* of a system that simplify writing, reading, execution and displays from binary datas over Hard Disk (most of the time, datas are stored and execute from that device), where, primary datas are sectorized and fragmented. In other words, consider that allowing a metadata to contain all datas needed to be interpreted by actual systems is maybe one of the best way to prevent systems failures, errors, or just datas modifications or corruptions. And, in this meaning, I require you to create your own metadatas, from *sheets calculator* as Excel or, if your more effecient with programming, use .txt metadatafiles from notepad that you merge to .dll (more proefficient way to execute by systems) . But the more information needed to a perfect system execution you put in that type of datas, writed in the most comprehensible langage by your computer system, you will soon find that there is a complete system decompression of datas, even if you have compressed self executive datas from hard disk or, in a more valuable way, from devices that allow storage and execution others from bytes disk encryption. I suggest you to ask your business professional with hardware and your local programmor to merge these kind of technologies. And, when your writing BOM (actually known as Binary Object Modal or, as I suggested, Binary Object Metadatas), you should use sans serif character policy and avoid using characters or objects (like Bullets) that do not enter in standard Microsoft Runtime Library (library of binaries executives to system commands executives). It seems difficult to understand at the first time, but your business will be granted from creating and executing BOM...!
Line 8 error : you should read "datas modifications or corruptions by systems"
Line 15 error : you should read "from bytes disk inscription"
Attached are the modifications to the BOM circularity check from AX2009. In the mean time we've migrated this to AX2012. The hierarchy check is still the same (AX classes have not really changed), but an awful lot of issues have come up in master planning. The problem is that we already have several different versions of that depending on installed hotfixes (MS have released quite a lot of hotfixes around master planning). With every hotfix we had to change the circularity logic to keep it working. so we do not have one "final" version of circularity handling in master scheduling. I would not recommend anyone to use circular BOMs in AX, although we do (we didn't have a choice because the customer had customizations in AX2009 to do this).
In brief, this is what what we did (hopefully the descripition will allow you to apply the logic to any version/hotfix):
- we assign a "relative BOM level" to variants (manually, we haven't automated the process of assigning relative BOM levels). The relative BOM level is the BOM level of the variant relative to the highest level where the item is used. Most of the time the "standard" (stock) variants are level 1 and the make-to-order variants that are manufactured from the standard variants are level 0
- we modifed the circularity check in master planning to not only check itemid but also include the dimensions. The location of this check has been moved around over versions, but you will run into it the first time you try to run a master plan with circular BOMs.
- we changed the level analyzer (reqcalc\addCovDimIdAsTask() ) to add dependencies between covdims of the same item, based on the relative BOM level. This forces AX to treat variants in the "right" order.
- we changed the futures task of master planning (reqcalc\futurescalcitem): the receipts side of the task is disabled (levelState == ReqLevelState::FuturesReceipts) and the issues side of the task handles the receipts AND the issues of a specified dim in one go. This is needed to propagate futures from one variant to another.
- Actions will no longer work. We have not done any effort to get this going... Also there may no item in between two levels with variants of another item. Variants of an item must be on consecutive levels. But is has never been a real limitation.
Don't consider the attached XPO as a ready-to-use solution, because there may be other customizations in it. Rather use it as a reference. Good luck!
The circularity only happens if the parent is 100 and the item in the BOM is 100. Is that really the question?
If the question is to have 100 as a component in the BOM and the parent define the colour component used then the basic configuration group and configuration dimension would handle this.