Dyncraft

Souce Code 

VS Continue without code

select the project 

get letest version(icon click)

https://www.c-sharpcorner.com/article/different-types-of-action-results-in-asp-net-mvc/

------------------------

Task 1235023 SER 1177947: Remediate Investigate path forward and refine stories. (azure.com)

https://stackoverflow.com/questions/3708348/the-execute-permission-was-denied-on-the-object-xxxxxxx-database-zzzzzzz-s

SELECT CURRENT_USER; 

PACCAR-NA\Mohammad.Chowdhury

InnerException {"The EXECUTE permission was denied on the object 'Hose21mGetStations_SELECT', database 'DataApps', schema 'dbo'."}

System.Exception {System.Data.SqlClient.SqlException}

USE zzzzzzz;
GRANT EXEC ON dbo.xxxxxxx TO PUBLIC

------------------------

C:\Application Support All\feature-AppSupportWeb-PlatformVersionFilter\AppSupportWeb\Views\AppSupport\Application.cshtml

 <h3 id="modelName">@Model.Name</h3>

 <td>@Html.TextAreaFor(x => x.Note, new { @onkeyup = "LiveChange()", @rows = 2, @cols = 50, @class = "form-control" })</td>

C:\Application Support All\bug-AppSupportWeb-ApplicationNameNotSavedInCert\AppSupportWeb\wwwroot\js\site.js

function LiveChange() {

    

    $('#modelName').html($('#Note').val());

}

Load Project/ Delete files from IISExpress / EWI Assembly

C:\Users\mohammad.chowdhury\Documents\IISExpress\config

Insert Data

="('"&A1&"',"&B1&",'"&C1&"'),"

BOM বা Bill of Materials বাংলায় হলো:

উপাদান তালিকা বা উপাদান বিবরণী

এটি একটি ডকুমেন্ট বা তালিকা যা কোনও পণ্য তৈরি করতে ব্যবহৃত সব উপকরণ, অংশ, উপাদান এবং সাব-অ্যাসেম্বলি (অংশবিশেষ) এর নাম, পরিমাণ এবং অন্যান্য বিবরণ অন্তর্ভুক্ত করে। এটি পণ্য তৈরির জন্য প্রয়োজনীয় সবকিছু বিস্তারিতভাবে উল্লেখ করে।

সহজভাবে বলতে গেলে, BOM হলো একটি পূর্ণাঙ্গ তালিকা যা বলে দেয় কোন পণ্য তৈরি করতে কি কি কি উপাদান দরকার এবং সেগুলোর পরিমাণ কত।

In SAP ECC, a manufacturing BOM (Bill of Materials) lists all the components and quantities needed to produce a finished product or assembly, and it's crucial for production planning and procurement. 

In SAP ECC, an Engineering Bill of Materials (eBOM) is a structured list of components and materials needed to build a product, primarily from an engineering perspective. It focuses on the technical details and design aspects of the product, rather than production or manufacturing processes. The eBOM is typically developed during the product design phase, often using CAD or EDA tools. 

Truck Chassis BOM originates from the truck plant.  It will say they want a truck that has generic callouts of items to go on the truck. 

VOG - (View Only Graphics) Tool used by the shop floor to view engineering drawings.

Dynacraft BOM - Similar to the Truck Chassis BOM with the specific part numbers and subassemblies that Dynacraft will sell the truck plant

Aspect	Truck Chassis BOM	VOG (View Only Graphics) Tool	Dynacraft BOM
Origin	Originates from the truck plant.	Used on the shop floor as a viewing tool.	Created by Dynacraft to specify exact parts to sell to the truck plant.
Purpose	Defines a truck with generic callouts of items to be included on the truck.	Allows shop floor personnel to view engineering drawings for reference.	Lists specific part numbers and subassemblies Dynacraft will supply to the truck plant.
Content	Generic item descriptions and callouts without detailed part numbers.	Engineering drawings and graphics in a read-only format.	Detailed BOM with exact part numbers and subassemblies tailored for Dynacraft’s products.
Users	Truck plant engineering and planning teams.	Shop floor operators, assemblers, technicians.	Dynacraft’s manufacturing, sales, and supply chain teams, as well as the truck plant receiving Dynacraft parts.
Functionality	Provides a high-level specification of truck requirements.	Provides visual reference to assist assembly and quality checks.	Provides detailed instructions for ordering, manufacturing, and supplying parts and assemblies.
Modification	May be more conceptual and subject to updates from truck plant.	View-only; no editing capability.	Detailed and controlled document updated as per Dynacraft’s product changes.
Example	“Include suspension system,” “Add frame rails,” without specific part numbers.	Viewing CAD drawings showing how parts fit together on the chassis.	Specific part numbers for suspension components, fasteners, and subassemblies sold by Dynacraft.

---

Summary

• Truck Chassis BOM: A generic, high-level list from the truck plant defining what items should be on the truck, often without detailed part numbers.
• VOG Tool: A shop floor visualization tool used to view engineering drawings for assembly guidance, with no part listing or editing abilities.
• Dynacraft BOM: A detailed and specific BOM from Dynacraft containing exact part numbers and subassemblies that Dynacraft supplies to the truck plant.

This distinction helps ensure clear communication between the truck plant and Dynacraft, with the VOG tool supporting the shop floor during assembly

--------------------------------------------------------------------------

Workflow to Manage Truck Chassis BOM, VOG Tool, and Dynacraft BOM

1. Truck Plant (Truck Chassis BOM Origin)

• Create and maintain the Truck Chassis BOM with generic callouts/specifications for the truck.
• Share the Truck Chassis BOM with Dynacraft and other suppliers to define requirements.
• Update the Truck Chassis BOM as design or specification changes occur.

2. Dynacraft (Detailed BOM Preparation)

• Receive Truck Chassis BOM from the truck plant.
• Develop the Dynacraft BOM with specific part numbers and subassemblies that will be supplied.
• Ensure Dynacraft BOM aligns with Truck Chassis BOM requirements but adds detailed sourcing and part specifics.
• Share Dynacraft BOM with the truck plant procurement and manufacturing teams.
• Update Dynacraft BOM with engineering changes or new product versions and communicate updates promptly.

3. Shop Floor (Using VOG Tool)

• Use the VOG (View Only Graphics) Tool to access up-to-date engineering drawings, assembly instructions, and exploded views.
• Reference VOG during assembly to verify correct placement and orientation of parts from Dynacraft and other suppliers.
• Report any discrepancies observed between physical parts and drawings to engineering or quality teams.

4. Change Management

• Changes initiated at the truck plant (Truck Chassis BOM) are communicated to Dynacraft.
• Dynacraft updates their BOM accordingly and shares revised BOM with the truck plant.
• VOG drawings are updated to reflect engineering changes and made available on the shop floor.
• Maintain a version control log for BOMs and VOG documentation.

---

Documentation Template Example

Document Name	Description	Owner	Audience	Update Frequency	Format
Truck Chassis BOM	Generic list of items required on the truck with callouts	Truck Plant Engineering	Dynacraft, Truck Plant Manufacturing	As required	Excel/PLM System
Dynacraft BOM	Detailed BOM with specific part numbers and subassemblies supplied by Dynacraft	Dynacraft Engineering	Truck Plant Procurement, Manufacturing	As changes occur	Excel/PLM System
VOG Drawings	Read-only engineering drawings and exploded views for shop floor	Engineering/IT Team	Shop Floor Operators	As changes occur	CAD Viewer/PDF
Change Log	Record of all changes to BOMs and VOG drawings with dates and approvals	Quality/Engineering	All relevant stakeholders	Continuous	Excel/Database

---

Benefits of This Approach

• Clear roles and responsibilities between truck plant and Dynacraft.
• Accurate and detailed BOMs for procurement and manufacturing.
• Visual guidance through VOG reduces assembly errors.
• Controlled change management ensures all teams stay updated and aligned.
• Improved communication and traceability between engineering, manufacturing, and shop floor.
• --------------------------------------------------------------------------

• Below are Excel template samples and a detailed SOP document draft you can use and customize for your teams.

  ---

  1. Excel Template Samples

  A. Truck Chassis BOM Template

  Item No	Description	Generic Callout	Quantity	Remarks
  001	Frame Rail	Structural Frame Part	2	Standard frame rails
  002	Suspension System	Leaf Springs	4	Generic suspension
  003	Brake System	Air Brake Assembly	1	Callout only, no part#
  004	Steering Components	Tie Rods, Knuckles	2	Basic steering parts

  ---

  B. Dynacraft BOM Template

  Item No	Part Number	Description	Quantity	Supplier	Subassembly	Remarks
  001	DC-1001	Frame Rail - Dynacraft	2	Dynacraft	Chassis	Matches Truck Chassis BOM
  002	DC-2005	Leaf Spring Assembly	4	Dynacraft	Suspension	Complete assembly
  003	DC-3003	Air Brake Assembly	1	Dynacraft	Brakes	Specific to Dynacraft product
  004	DC-4007	Steering Knuckle	2	Dynacraft	Steering	Custom part

  ---

  C. Change Log Template

  Change ID	Date	Description	Affected Document(s)	Initiator	Approval Status	Remarks
  CHG-001	2024-06-01	Updated Leaf Spring part number	Dynacraft BOM, VOG Drawings	Engineering	Approved	Implemented 2024-06-05
  CHG-002	2024-06-10	Added new suspension subassembly	Truck Chassis BOM	Truck Plant	Pending	Under review

  ---

  2. SOP Draft: Using VOG Tool & Managing BOMs

  ---

  Title: Standard Operating Procedure for Managing Truck Chassis BOM, Dynacraft BOM, and Using VOG Tool

  Purpose:
  To establish a clear process for managing BOMs and effectively using the VOG tool on the shop floor for assembly accuracy.

  Scope:
  This procedure applies to engineering, manufacturing, procurement, and shop floor personnel involved in truck chassis assembly projects.

  ---

  Procedure:

  Step 1: Truck Chassis BOM Preparation

  • Truck Plant Engineering creates the Truck Chassis BOM with generic callouts.
  • This BOM is shared with Dynacraft for detailed part specification.

  Step 2: Dynacraft BOM Development

  • Dynacraft Engineering develops a detailed BOM with specific part numbers and subassemblies.
  • Dynacraft BOM is reviewed and shared with the truck plant procurement and manufacturing teams.

  Step 3: Shop Floor Usage of VOG Tool

  • Shop floor personnel log into the VOG tool daily.
  • Select relevant vehicle model or assembly line drawings.
  • Use the tool to view exploded views, assembly instructions, and part fitment during production.
  • Report discrepancies immediately to engineering or quality teams.

  Step 4: Change Management

  • Any changes initiated by truck plant or Dynacraft are documented and communicated.
  • Update Truck Chassis BOM, Dynacraft BOM, and VOG drawings accordingly.
  • Communicate updates to all relevant parties promptly.
  • Log all changes in the Change Log document.

  ---

  Responsibilities:

  Role	Responsibility
  Truck Plant Engineering	Create and update Truck Chassis BOM
  Dynacraft Engineering	Develop and maintain Dynacraft BOM
  Shop Floor Operators	Use VOG tool for assembly guidance
  Quality Team	Verify assembly accuracy and report issues
  Change Control Team	Manage and communicate BOM and drawing changes

  ---

  Revision History

  Revision	Date	Description	Author
  1.0	2024-06-15	Initial SOP Release	Your Name

  ---

  Next Steps

  • Customize these templates with your actual parts and data.
  • Distribute SOP to all relevant teams and conduct training sessions.
  • Set up regular review meetings to monitor BOM accuracy and VOG tool usage.

 

Materials in Trucks:

• Definition: Materials refer to the raw substances or basic components used to manufacture parts of a truck.
• Examples: Steel, aluminum, rubber, plastic, glass, copper wiring, leather, fabric, etc.
• Role: Materials determine the physical properties of truck components, such as strength, flexibility, weight, and durability.
• Example in context: The steel used for the truck’s frame, rubber used for tires, or plastic used for interior panels.

Assemblies in Trucks:

• Definition: Assemblies are groups of parts or components put together to form a functional unit within the truck.
• Examples: Engine assembly, transmission assembly, suspension assembly, brake assembly, cab assembly.
• Role: Assemblies combine multiple materials and parts into a complete system that performs a specific function.
• Example in context: The engine assembly consists of many parts made from different materials (steel, aluminum, rubber seals) put together to power the truck.

Clean Architecture

 Clean Architecture is an architectural design approach that emphasizes separation of concerns, maintainability, and testability in software development. It was popularized by Robert C. Martin (Uncle Bob) and provides several benefits when applied to a software project:

1. Modularity and Separation of Concerns: Clean Architecture enforces a clear separation of concerns among different parts of the application. It divides the codebase into distinct layers (e.g., presentation, application, domain, and infrastructure), ensuring that each layer has a specific responsibility. This modularity makes it easier to understand, extend, and maintain the code.

2. Testability: Clean Architecture promotes testability by isolating business logic in the inner layers of the application. This allows you to write unit tests for the most critical parts of your software without the need for complex integration tests. Testing becomes more straightforward because you can mock or stub dependencies in the outer layers.

3. Flexibility and Maintainability: Since Clean Architecture reduces coupling between components, it becomes easier to make changes to one part of the application without affecting the others. This flexibility simplifies maintenance and makes it less risky to add new features or refactor existing ones.

4. Technology Independence: The innermost layer of Clean Architecture, known as the "core" or "domain" layer, should be technology-agnostic. This means that your business logic isn't tied to a specific framework or technology. This independence can be valuable when you want to switch to a different database, user interface framework, or other technology.

5. Better Code Quality: Clean Architecture encourages the use of SOLID principles and good coding practices. It enforces a clear and consistent structure, making it easier for developers to follow coding standards and maintain a high level of code quality.

6. Improved Collaboration: Clean Architecture provides a well-defined structure for your project, making it easier for multiple developers to collaborate effectively. Developers can work on different layers or components of the application in parallel without interfering with each other.

7. Business Logic Preservation: The core business logic is at the heart of Clean Architecture and is protected from external concerns and details. This ensures that the most critical and valuable part of your application remains clear and maintainable.

8. Reduced Technical Debt: By maintaining a clean and organized codebase, Clean Architecture helps to prevent the accumulation of technical debt. This reduces the cost of maintaining and enhancing the software over time.

9. Easier Adoption of New Technologies: With the clear separation of concerns, it's easier to integrate new technologies or frameworks into your application as the need arises. You can do so without affecting the core business logic.

10. Enhanced Scalability: Clean Architecture supports scalability because you can optimize and scale different layers of your application independently. For example, you can scale the data access layer to handle more traffic without affecting the core business logic.

While Clean Architecture offers numerous benefits, it's important to note that it may introduce some initial complexity, and not every project may require the same level of architectural rigor. The choice to adopt Clean Architecture should be based on the specific needs and goals of your project.

Clean Architecture is an architectural approach that can be applied to a wide range of software projects, but its adoption should be based on the specific needs and goals of the project. Here are some common needs and goals that Clean Architecture can address:

1. Maintainability: Clean Architecture provides a clear separation of concerns and a structured way to organize code. This makes it easier to maintain and extend the software over time, reducing the cost of long-term maintenance.

2. Testability: Clean Architecture encourages the development of highly testable code by isolating business logic from external dependencies. This leads to improved software quality and reliability.

3. Flexibility and Adaptability: Clean Architecture allows for easier adoption of new technologies and frameworks. This is especially valuable when your project needs to evolve or adapt to changing requirements or technologies.

4. Scalability: The architectural separation in Clean Architecture allows for the independent scaling of different parts of the application. You can scale the data access layer, business logic layer, and presentation layer as needed to handle increased traffic or demand.

5. Technology Independence: The core business logic is technology-agnostic in Clean Architecture, reducing the risk of vendor lock-in and allowing you to choose the best tools and technologies for each part of your application.

6. Reduced Technical Debt: By adhering to best practices and SOLID principles, Clean Architecture helps prevent the accumulation of technical debt. This results in a more maintainable codebase and lower long-term costs.

7. Clear Separation of Concerns: Clean Architecture enforces a strict separation of concerns, making it easier to understand the codebase and manage complexity. Developers can focus on specific responsibilities within the application.

8. Business Logic Preservation: Clean Architecture prioritizes the protection and clarity of the core business logic. This ensures that the most critical and valuable part of your application remains well-maintained and understandable.

9. Team Collaboration: Clean Architecture provides a well-defined structure for your project, making it easier for multiple developers to collaborate effectively. Teams can work on different parts of the application concurrently without conflicts.

10. Quality Assurance: The emphasis on testability and maintainability in Clean Architecture leads to higher code quality and fewer defects. This results in a more reliable and secure software product.

11. Compliance and Security: Clean Architecture can facilitate the implementation of security measures and compliance requirements by isolating sensitive operations and data access in well-defined layers with clear boundaries.

12. Code Reusability: The modular structure of Clean Architecture allows for the reuse of components across different parts of the application or even in other projects, improving development efficiency.

13. Long-term Viability: Clean Architecture helps ensure that your software remains viable and adaptable for years to come, reducing the risk of obsolescence.

It's essential to evaluate the specific needs and goals of your project to determine whether Clean Architecture is the right fit. Not every project may require the same level of architectural rigor, and simpler architectures might be more appropriate for smaller or less complex applications. Clean Architecture is a tool that should be applied judiciously based on the unique requirements of your software development endeavor.

While Clean Architecture offers many advantages, it's important to be aware of potential disadvantages and challenges associated with its adoption:

1. Complexity: Implementing Clean Architecture can introduce additional complexity to your project. Maintaining and understanding the architectural layers and their interactions can be challenging, especially for smaller or less complex applications.

2. Overhead: The clear separation of concerns in Clean Architecture may lead to some level of overhead. It can take more time and effort to set up and maintain the architecture, which might not be justified for simple projects.

3. Learning Curve: Clean Architecture can be unfamiliar to developers who are new to the concept. It may require additional training or a learning curve for your development team to fully understand and apply the principles correctly.

4. Initial Development Time: Building a project with Clean Architecture may require more upfront planning and development time. While this investment can lead to long-term benefits, it might not be suitable for projects with tight deadlines.

Clean Architecture Structure for Scalable .NET Projects

Say hello to the Clean Architecture Project Structure — your roadmap to building robust, testable, and scalable applications!

🧱 What Is Clean Architecture?
Clean Architecture is a timeless software design pattern that emphasizes separation of concerns and dependency inversion.

Your application becomes:
✅ Highly Maintainable
✅ Easily Testable
✅ Scalable & Flexible
🔍 Core Layers Explained

📌 1. Domain Layer (💛 Heart of your system)
Holds your core business logic — entities, value objects, enums, exceptions, etc.
🧠 No external dependencies here!

📌 2. Application Layer (❤️ Brain of your system)
Contains use cases, application services, and interfaces for external communication.
Examples: Commands, Queries, Abstractions, Contracts

📌 3. Infrastructure Layer (💙 The Hands)
Deals with technical details like databases, messaging, jobs, services.
Implements interfaces defined in the Application layer.

📌 4. Presentation Layer (💚 User Interface)
The face of your application — includes controllers, middlewares, DTOs, and optionally ViewModels or Endpoints for minimal APIs.
📊 Visual Breakdown (Diagram)

Here’s a clear and simplified view of how everything connects and communicates 👇
🔄 Outer layers depend inward, never the other way around.
📷 (Attached Image: Clean Architecture Layers + Folder Structure)

🎯 Why You Should Use This Structure
🔹 Promotes SOLID Principles
🔹 Enhances team collaboration
🔹 Ideal for enterprise-grade .NET solutions
🔹 Keeps logic decoupled, testable, and easy to scale