Project Purchase Orders

A Project Purchase Order can be created directly from the Project form: click Project>Projects>Item task button>Purchase Order.

On Project Purchase Orders, the project number is populated. This seems a minor difference, however a lot of other consequences are triggered by this fact.

The issue inventory transaction generated for a Project Purchase Order is a virtual inventory transaction (Reference is Transaction).

It means the item never arrives in stock. This has import consequences:

• The item cannot be used in Shipment functionality. As it never arrives in stock upon posting the purchase packing slip, it cannot be added to a Shipment.
• The item ordered with a Project Purchase Order will never cover a requirement. So if you have a project item requirement and you create a project purchase order for it, the MRP run will still propose a planned purchase order for the item.

These are major disadvantages of using Project Purchase Orders. Nevertheless there are some advantages of using them:

• The project number allows for easy filtering. Also it is clear for the purchase department for which project the purchase order is intended.
• Upon posting the purchase packing slip, the item consumption is automatic: no need to post a separate transaction to have the item consumption on the project.

Purchase orders

Another way of buying items for a specific project, is using ‘normal’ Purchase Orders.

You can create a ‘normal’ Purchase order from your project item requirement by clicking the Functions button > Create Purchase Order.

A second way is to run the MRP, which will generate a Planned Purchase Order for your project item requirement. You can Firm this Planned Purchase Order into a ‘normal’ Purchase Order. Just make sure you have marking activated during firming.

Both generate a ‘normal’ Purchase Order which is marked to your project item requirement.

This has some advantages compared to a Project Purchase Order:

• No virtual transactions are generated for such a Purchase Order. The item arrives in stock upon posting the purchase packing slip. As such the item can be used in Shipment functionality.
• The Purchase Order will be seen by MRP as a coverage for your project item requirement, avoiding generation of a new Planned Purchase Order. Important to notice here is the condition: it is the Marking which should be activated upon firming.
• Still, the item consumption on the project can be done rather automatic: upon posting the purchase packing slip, a question will be popped up asking if the consumption should be booked right away on the project.
  
   
  Important –again- to notice here is that Marking should be activated upon firming.

Minor disadvantage here:

• Project number is not populated on such ‘normal’ Purchase Orders, so it is less clear for the purchase department to which project the Purchase Order belongs to. Some minor modifications (a new custom field which stores the ProjId) can solve this issue easily.

Solution: Specify manually the proxies Directory

The problem is apparently that the process wasn’t able to find the directory for deploying the proxies. So I specified the directory manually and pressed the second Generate button on the form (in group File System Directory) and everything ran fine.

In most cases the proxies directory will look like this: C:\inetpub\wwwroot\wss\VirtualDirectories\80\App_Code\Proxies.

Solution: Add a checkbox custom filter

The solution is elaborated by means of an example. Suppose you want to provide the end user with an easy filtering on the customer form to show only customers with active Projects (Projects not in the Project Stage Completed).

To achive this, you can follow these steps:

1. Duplicate the CustTable form and add a checkbox control ctrlCustActProjs to it for the filtering purposes. Set the AutoDeclaration property of the checkbox to Yes.
2. Add the ProjTable data source to the form and link it to the CustTable data source.
3. Override the executeQuery method of the CustTable data source as follows:
   

   public void executeQuery()
   {
       QueryBuildDataSource qbdsProjTable = 
       this.query().dataSourceTable(tableNum(ProjTable));
       QueryBuildRange qbrProjStatus;
       ;
   
       if (ctrlCustActProjs.value() == NoYes::Yes)
       {
           qbdsProjTable.enabled(true);
           qbrProjStatus = 
               SysQuery::findOrCreateRange(qbdsProjTable, 
                            fieldnum(ProjTable, Status));  
           qbrProjStatus.value(
               Global::queryNotValue(
                                 ProjStatus::Completed));  
       }
       else
       {
           qbdsProjTable.enabled(false);
       }
       super();
   }

   
   

By toggling the checkbox only customers with active Projects will be shown or not.

Enabling the qbdsProjTable QueryBuildDataSource based on the checkbox links or removes the ProjTable to the CustTable in the form query.

The search for only active Projects is achieved by adding or finding the qbrProjStatus QueryBuildRange. Use the Global::queryNotValue to look up values different from a base Enum value.

Solution: Adapt class SalesTableType

A small X++ code fix can solve this problem in class SalesTableType, method syncPurchTable.

if (_salesTable.fieldChanged(fieldnum(SalesTable, SalesType))) 
{ 
    switch(salesTable.SalesType) 
    {

        case SalesType::Subscription    :   
            axPurchTable.parmPurchaseType(
                            PurchaseType::Subscription); 
            break;
  
        case SalesType::Sales           :   
            axPurchTable.parmPurchaseType(
                            PurchaseType::Purch);        
            break;
  
        case SalesType::ReturnItem      :   
            axPurchTable.parmPurchaseType(
                            PurchaseType::ReturnItem);   
            break;
  
        case SalesType::Blanket         :   
            axPurchTable.parmPurchaseType(
                            PurchaseType::Blanket);      
            break;
  
        // BEGIN: intercompany chain for item requirements
        case SalesType::ItemReq         :   
            axPurchTable.parmPurchaseType(
                            PurchaseType::Purch);        
            break;  
        // END: intercompany chain for item requirements


        default : 
            axPurchTable.parmPurchaseType(
                            PurchaseType::Journal);

    }  
}

Upon creating an Intercompany Purchase Order, it won’t be of type Journal anymore and the Intercompany Sales Order in the vendor company account will be created automatically too.

For a switch statement you add the default section as follows:

switch (_variable)
{    
    case value1:        
        some code;
        break;
    case value2:
        some code;
        break;
    default:
        throw error(strFmt("@SYS23396",funcName()));
}

For an if else statement:

if (value1)
{
    some code;
}
else
{
    throw error(strFmt("@SYS23396",funcName()));
}