Including Sales Orders and Purchase Orders in Stock Returns

BlueBox2.0 has an automated stock returns module which allows you to return stock to a supplier via the GRN which received the stock, or to return stock from a customer via the Despatch Note that shipped the stock.

Recently added has been the ability to do that one document further up the chain, namely via the Purchase Order or via the Sales Order. These 2 new additions, complete with 'quick action' buttons in the views of each document type, are a logical starting point when wanting to process a supplier or customer return, and will make the returns process even easier to handle.

The new quick link on the Purchase Order view screen.

The new quick link on the Sales Order view screen.

BlueBox Despatch Notes - Including Backorder Status

Despatch Notes in BlueBox2.0 have been upgraded to include backorder status of items relating to the parent Sales Order if one exists. The Despatch Note has also had all financial info removed from it, and purely relates to item and qty despatched.

Note: if you want to access the financial view of the despatch note (ie the old view) you can still do so by using the special view in the Output menu.

BlueBox General Ledger Document Map Conditions

The GL in BlueBox is driven by  set of document maps. These are essentially a set of GL account instructions which tell the GL which account to credit or debit for each document in the document layer of BlueBox. 

So, for example, the document map for 'Creditors Invoices' tells the GL to credit the Liabilities account called 'Accounts Payable' and to debit the Expense account called 'Cost of Sales'. It also includes a 3rd instruction for the VAT/Tax account. The sum of all 3 'movements' balances the double entry for each line in the document being processed.

There are times when you may want a different set of movements depending on what has been entered into the document. For example, you may want to debit or credit a different account depending on which business unit the document was captured in.

Document and line conditions are the way to achieve this. These conditions are evaluated for each document map and, as their names suggest, are evaluated at 'header' or 'document' level, or at 'line' level.

The most basic way of entering a condition is to simply include the field name that you are evaluating. This implies that if that variable exists in the data being posted it will be seen as applicable.

Most likely though, will be the case where you require an evaluation of the value being passed through a field, and for this we need a bit more syntax.

The correct syntax for evaluated conditions is:

eval:$conf[fields][SESSION_business_unitISbb_business_unitsID]==2

Note the eval: which triggers the evaluation, and the double =='s which are programatical for ='s

In this case you would replace the 2 with the ID you required.

Also: Doc Maps require that ALL entries for that specific doc type need a condition if any of them have one... this way it eliminates which ones to ignore, so for the 'general one' you will need a condition like this:

eval:!in_array($conf[fields][SESSION_business_unitISbb_business_unitsID],array(2,4,6)) 

Note: it starts with a ! which means 'not' and the list of ID's mentioned in the other lines needs to be comma separated in the array at the end.