.svg){kind=small}
Transferring Sales Orders
Workflows > Endpoints > Sales Orders > Transferring Sales Orders
Purpose: Transferring sales orders to Go
This workflow is typically used in cases where sales orders are generated in an external system, but invoicing are to be done from PowerOffice Go. The purpose of the flow is to generate sales orders in Go (invoice drafts), so that the sales order can be sent (invoiced) from Go to the receiving customer. When the invoice is sent from Go, the sales order is transformed to an invoice voucher and the sales transactions are generated and posted as part of the sending process in Go.
Typical usecases:
This workflow can be the usecase for webshops, point of sale system, CRM systems or any custom system handling the sales order information, where there is a need to use Go for the invoicing process. This need can be present if the sales order system does not have functionality for invoicing, or in cases where Go provides invoice delivery methods not supported by the sales order system (eFaktura/EHF, for instance).
Important distinction:
Note that if the external integrating system can and do deliver invoices (invoices are already generated and delivered to end customer from the external system), a different workflow should be considered, involving either the OutgoingInvoiceVoucher or Import (v1) endpoints.
Description of the core workflow
Check whether the customer already exist in Go, and if needed create or update the customer information to Go
Check that the products that will be transferred on the invoice draft lines exist in Go, and if needed create or update the product information with Go
Transfer the invoice draft with the customer and appropriate lines including products
The sales order object consist of information of the invoice header (customer, references, delivery terms and delivery address etc), and a collection of the sales order lines
The sales order lines is usually set as sales lines with a product. When and if the invoice is created and sent at a later point in time, the sales lines will be posted as an accounting entry (sales transactions posted)
The sales order lines can also be set as text lines to supplement information on the line level.
We highly recommend that the field <externalImportReference> is used and set on the sales orders transferred. This field can be used as a techical reference to the external system, but most importanly, the field act as a duplicate check as only one instance of the reference can be present on any sales order object in Go.
The sales order can be saved to Go with either the state draft or confirmed, and can then be sent as an invoice by a user in Go or by the api endpoint for sending the invoice.
Prerequisites
The Go Api's consist of endpoints for each separate entity. An invoice draft transferred will consist of at least two sub-entities, Customer and Product, that must exist in Go before transferring the invoice draft. All sub-entities in use must be created and updated using their separate endpoints.
The integrating party need access priveliges to the api's that are to be used. The Go clients the integrating party is transferring to, need have active subscriptions of relevant modules in Go. Inactive clients or clients without the appropriate modules, will result in the error "400 Bad Request/Invalid client" message. Client priveliges can be retrieved using this endpoint.
Required steps when transferring invoice draft:
Creating or updating the Customer related to the order.
Creating or updating the Products to be used on the order lines.
Note that Sales Accounts and Vat is not set directly on the invoice draft lines, but handled indirectly via the product level.
Optional steps (situational):
Creating or updating general dimensions relevant for the invoice draft
Creating or updating notes related to the invoice draft
Adding or removing attachments to the invoice draft
Invoicing the sales orders (sending the invoices) from Go
Related workflows:
Reporting payment details from Go
Dictionary/Terminology:
An sales order and an invoice draft are the same concept in Go (same base entity, same functionality, except sent/posted state). We consequently use the term sales order in our documentation.
The draft vs confirmed status: Draft state imply that the invoice draft can be edited (by users in the GUI or via the api endpoint). Confirmed draftes are locked for edits and considered an "ready" order (unless reopened for edit by changing the state to draft). Invoice draft objects are presented in two different lists in the GUI (separated draft and confirmed tabs). Regardless of the state: The object sales order is an invoice draft in terms of being unsent and the voucher transactions unposted.