Summary

It should be possible to import Stock, Customer, Supplier and Customer Addresses – all of which are static header files from any externally produced .csv file. This importing will require mapping and once happy that the data fields being imported match the attributes of the Prelude Desktop files the import can take place.

It should also be possible to import transaction files from external sources with certain considerations. For example a sales order which has header details and line details may have been partly processed – there are field in Prelude Desktop to take this into account – DSOFA – delivered to date & CSOFA – Collected to date – both of which are cumulative quantities. There is also ISOFA – Invoiced to Date. Prelude Desktop will then know how much to invoice for goods delivered but not invoiced and what quantity is still to be delivered or collected. The same fields exist within purchase orders. It may well be that in the importing structure there are different fields that may need to be manipulated first before you can import to these cumulative fields – possibly a third child table.

The transaction structure for a Sales Order can be sent to an inter-company (Or any company where they both use the same version of Prelude Desktop) and be processed using AUTOMATION to create or update a Purchase Order – effectively EDI (updating where there is more than one delivery). Whilst there is a lot of mapping within AUTOMATION this only has to be done once by Prelude Desktop and the user need not be aware of it.

Sales Invoices can also be sent in this way and will create a transaction by updating the Purchase Order in the receiving company and posting the details to the Purchase Ledger. This will only work for invoices created using sales order processing. The sales invoice should not be processed until the goods have been received and will be rejected if this is not the case.

Sales Credit Notes must have an impact on the Sales Order – either quantity or price for the amendment to be reflected in the receiving company’s purchase order.

Sales Receipts and Payments can be sent in the same way and a corresponding Purchase Payment and Receipt created in the Receiving company’s ledger – providing the receiving company’s bank account details are known and probably for faster payments only to avoid outstanding amounts in the Bank Reconciliation. This facility would need careful consideration before utilisation and is not readily recommended.

Sale and Purchase Ledger Matching is only possible where the submitter company sends a statement and the receiving company pays that statement in full – before the next statement is due.

Expenses from an external source will be difficult to import because of the sheer numbers of nominal codes and expenses invariably need checking for VAT errors. Any consideration of this and journals will always be internal.

The creation of payroll imports is feasible but only worthwhile if there are different companies, departments and multiple payment types that make journal preparation and posting onerous.

B2B identifies whether a manually-entered transaction will automatically generate the reciprocal transaction in the destination company. This is effected by creation of the relevant SLAVE CSV.