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.

Endpoint
Picture

Description of the core workflow

  1. Check whether the customer already exist in Go, and if needed create or update the customer information to Go

  2. 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

  3. 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.

  4. 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.

Create and send invoice:

If needed, the integrating party can trigger the process of creating and sending invoices, fully automating the process of transferring sales orders and invoicing them. 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. Triggering this, require a special privilege that you will need to contact the API-team to get access to.

When triggering the sending, you set the voucher date (ie the invoice date), the invoice delivery type, and optionally an override/fallback e-mail address and an optional override of what the invoice due date will be.

Description of the delivery types:

  • Pdf by email: The invoice will be delivered as a pdf to the invoice e-mail address of the customer the sales order relate to. If an email address is set in the request, this will override any email set on the customer and the email set in the request will be used.

  • Pdf print for download: This delivery type will trigger the creation of the invoice voucher, post the voucher and generate a pdf invoice document, but the document will not be delivered from Go. The general usecase for this option is for situations where the integrating party will get the pdf and ensure delivery of the invoice to the end customer. To get the pdf, the VoucherDocumentation endpoint (LINK I FRAMTIDEN) must be used.

  • Auto: This option will automatically trigger the optimal delivery method, based on available information in Go. In general the following will apply:

    1. Factoring will be used if set on the customer (applies only for cases where the client have a factoring integration)

    2. EHF delivery will be used if applicable for company customers (the system will identify whether the customer is registered for EHF receival or not)

    3. eFaktura/AvtaleGiro will be used if applicable for person customers

    4. If none of the above apply, the invoice will be sent as pdf by email, to the provided email address in the request or the email address registered on the customer object.

We generally recommend that the "Auto" option is used, and that the fallback email address is included in the send request. Consequently, the integrating party need not concern themselves with the invoice delivery settings of the customer objects and/or how the invoice will be sent - Go picks the optimal route automatically. The prerequisite for this, is that any custom sync from the integrating system to the client includes sufficient data, specifically these recommended fields:
The following information are recommended to include when creating or updating customers to Go:

  • First- and last name (if customer is a person)
    Name (if customer is a company)

  • Full address

  • Phonenumber

  • e-mail address

  • Vat number (if customer is a company)

  • Contact person (if customer is a company)

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:

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.