5 Replies Latest reply on Apr 21, 2014 5:12 PM by Dmitriy Kolasnikov-Oracle

    CSS 1 sync message generation question


      What logic is used in CSS to determine when to send an Add vs modify message to 1sync?  My belief is that when we send an "initial load" vs "new" we would see modify vs add messages respectively, but our testing would indicate its more dependant upon whether CSS has a prior transaction for this GTIN - sender - receiver combination.  If that's the case, what does the selection of "initial load" vs "new" actually do functionally?  Thx

        • 1. Re: CSS 1 sync message generation question
          Dmitriy Kolasnikov-Oracle

          The initial load/new selection is an indicator on a publication that is being sent to a retailer. Usually, initial load needs to be selected if that spec already exists in a retailer's system and was communicated outside of 1SYNC - this happens often during initial on-boarding to 1SYNC; new needs to be selected if it is a brand new spec that you want to communicate to a retailer. Some retailers care about this indicator and some don't.


          The entire message generation is probably easier to explain with the following message flow (I'll omit some messages that are happening within GDSN for simplification).

          Consider a scenario where you have 2 trade specs (a case containing a consumer unit as a next lower level item) that you want to send to Walmart.

          1. The system generates an add message for the case and CU.

          2. The system also generates a link message to show relationship between case and CU.

          3. The system generates publication message for case to indicate that you want to send this information to Walmart. This message will contain initial load/new indicator.

          4. 1SYNC uses add and link messages to validate specs and ensure that these specs do not exist in GDSN based on GTIN and supplier. If everything is correct, it stores the data in its system and sends success messages back to our system.

          5. As it receives the publication message, 1SYNC generates a notification message containing both case and CU and sends it to Walmart.

          6. Walmart reviews it and sends accept message back to 1SYNC.

          7. 1SYNC sends accept message back to our system.

          8. -You want to send the same specs to Kroger, so you went and created a new tip to send to Kroger.

          9. The system checks if the add messages were successful (they were) so it only generates a new publication message that indicates that the case needs to be sent to Kroger.

          10. Upon receiving publication message, 1SYNC generates a notification message containing both case and CU and sends it to Kroger.

          11. Kroger doesn't want this spec hierarchy so it sends back a reject message to 1SYNC.

          12 1SYNC sends reject message back to our system.

          13. -There was a change in the spec so you created new issues for both specs and created new tips to Walmart and Kroger.

          14.  The system checks again if add messages were successful and will generate a modify message for both newly issued specs.

          15  Upon receiving the modify message, 1SYNC generates a notification message containing both case and CU and sends to all retailers that accepted the data (Walmart in this case).


          Hope this helps,


          • 2. Re: CSS 1 sync message generation question

            Thank you - very helpful.  I have a few more questions:

            If the item was already added to 1sync, but the TIP is added for the first time in PLM4P, is there a way from the UI to send a modify vs an add?  Scenario is this - we migrate to using CSS for a GLN that was using a legacy tool.  What is the best approach to load moving forward?  Add messages will fail.


            Similarly, at times we see a failure after the add message at the TU level.  A good example is that the TU was added but the CU was not because a required field was missing or incorrect in the CU that validation did not catch.  Does the system keep track of the TU and CU results so the next TIP gets a modify at the TU level and an Add at the CU level?  Is there a proper way to handle these kinds of issues i.e. should we just delete the TIP and start over or workflow it to cancelled or some terminal step?


            Is there a way to see historical TIPs propogate through the up-issuing of TU specs?  Scenario - we may make packaging spec changes to a TU which is not an event which would trigger a new TIP to the data recipient.  We up issue the TU but the TIP doesn't carry forward.  We wish to have visibility to the historical TIP that was created at issue 001 and still active through issue 003.  If we did send a new TIP in 003, are we supposed to go back to TIP on issue 001 and move to cancelled or some other terminal step in the CSS workflow?



            • 3. Re: CSS 1 sync message generation question
              Dmitriy Kolasnikov-Oracle

              I think most customers script-in cssTransactions as successful adds and links based on the list of GTINs they get from 1SYNC. This way all subsequent messages will be sent as modifications for these items.

              The system can issue correct add modify commands as long as the error received back from 1SYNC is not a duplicate GTIN error. Just workflowing the TIP back to staged for syndication should be sufficient in most cases. When 1SYNC responds with "item already exists" error message you would need to fix the cssTransaction in the database so that the system thinks that the add was successful. I think most customers utilize "Third Party Action" TIP workflow status to track these types of changes.


              The only thing I can think of out of the box that will show you historical TIPs is an EQT search based on GTIN in CSSPortal. The report in BI publisher would be a good fit to get this information. Maybe we can include this type of report in the future solution packs for reporting.

              • 4. Re: CSS 1 sync message generation question

                Thank you for the answers.  Just a few more questions I promise


                1. Still curious about the proper way to maintain TIP "housekeeping".  If we published to a recipient in issue 001 and to a second recipient in issue 003, these are incremental updates, correct?  Meaning, we would not go back to issue 001 and move that TIP to cancelled or a terminal step in the CSS workflow, correct?  Should it be workflowed to some other status?
                2. We have used CSS for many years and have thousands of TIPs in various statuses in CSS.  I'd like to clean anything up that is not in "staged for syndication", syndication, or "Active".  Any concerns with mass workflowing TIP's in other statuses to cancelled?
                3. Do you have a list of system actions and 1sync commands sent for the various default workflow statuses that I am not familiar with?
                  1. Active Accepted
                  2. Active Rejected
                  3. Third Party Action

                Does the system do any automatic transitions to these stages based on response messages received?

                • 5. Re: CSS 1 sync message generation question
                  Dmitriy Kolasnikov-Oracle

                  1. I always thought that keeping in Active Accepted and Active Rejected is enough in most cases. This gives you a picture of what product retailers are interested in. Active Rejected probably can be moved to inactive, archived.

                  2. You can move to any statuses as long as you don't delete any TIPs. The only statuses you need to be careful with are Syndication, Awaiting Response and Active.

                  If you have a TIP in Syndication status that means that the message is currently is being generated or the generation process crashed, while Awaiting Reponse status means that we never got a response from 1SYNC. In both cases you will need to investigate to see if the data has been registered in 1SYNC to avoid synchronization issues.

                  Active status is a special status that synchronization process uses to move a tip to either Active Accepted or Active Rejected based on a message from 1SYNC.

                  3. The system will move to Active Accepted from Active status when it gets an accept message from 1SYNC. See step #7 from the earlier post. The system will move to Active Rejected from Active status when it gets an accept message from 1SYNC (step #12 from the earlier post). Also, there is another reconciler called StandardTimedReconciler that is not configured out of the box that will move a TIP from Awaiting Response to Third Party Action if it did not receive a response within a particular time interval.