How The Integration Works
5 min
outline the integration listens for returns being processed in refundid, then builds and completes the matching credit note in cin7 when a credit note is created a credit note is created once the return has been processed approved, partially approved, or closed with a mix of outcomes two cases are deliberately skipped returns that have only been lodged nothing is written to cin7 until you have processed the return, so a return that is later declined never produces a credit note replacement resolutions where the customer is being sent a replacement rather than refunded, no customer credit, gift card offset, freight deduction or payment is created refundid can instead create a zero value return in cin7 so the goods are still expected back, without a credit being issued both cases complete cleanly rather than raising an error, so you won't see integration errors for returns that were never meant to reach cin7 approved quantities only the credit note is built from what you approved, not what the customer asked for approved quantities are credited declined and cancelled quantities are excluded entirely on a partial approval, only the approved quantity and the value actually processed is credited if nothing at all was approved, no credit note is created finding the original order the order is found in cin7 using an exact match on the order reference, and the integration independently confirms that exactly one approved cin7 order matches before it builds anything if two orders share a similar reference, nothing is created and an integration error docid 2cjxjmvexrl9kpvc2nozd is raised rather than crediting the wrong order one credit note per return before creating anything, existing credit notes are checked for one already carrying this return's reference if one exists, the run stops this means a retry after a cin7 timeout, for example can never produce a duplicate credit note what the credit note contains branch or location your nominated returns holding branch, so returned stock lands somewhere separate from sellable inventory until it has been inspected lines one per approved item, with the approved quantity and the processed value comments the internal comments and customer report carry the sku, approved quantity and the primary return reason for each item free text customer notes, questionnaire answers and uploaded images are deliberately left out, so the credit note stays readable product comments the primary return reason for the item gl account the returned physical lines and the credit note header post to the refunds account you nominate, so returns are reportable separately from sales payment and completion once the credit note has been created and cin7 has calculated its totals a payment is created against the credit note for the refunded value, using the payment method you nominate zero value payments can be created too, so credit notes are never left sitting with an outstanding balance the credit note is approved and completed its stage is set to indicate the return is complete but the goods have not yet been inspected, so your warehouse team knows there is still something to check in currency where the order was placed in a different currency to your cin7 base currency, the exchange rate supplied with the return is used to convert values before they are written to cin7