Laddawn.com : Programming Doc - Create Orders from Checkout

Checkout – Creating Stock & MOD Orders

10/18/13

A new RPC will be created that will loop through shipment bundles in the SHOPPINGCART.USR and create multiple sales orders, separating stock and MOD items. A separate order will be created for each MOD item in the cart. Stock items could be bundled together, separately, or ride with a MOD item. The final rules for how the stock bundles will be handled as far as order creation have not been determined, so for now you will create a single stock order and a separate order for each MOD item.
New Program: LDLIB RPC$SHOPPINGCART_CREATEORDER

  1. Execute SYSS0122.1 to assign the next sequential sales order number. Every order created for this cart will have the same order number with an alpha prefix (even if only one order is created). Ie, 123456A, 123456B, etc.
  2. Loop through the items in SHOPPINGCART.USR building a list of the items that will make up each order. Since we aren't worried about bundling at this time, you will be using the item numbers and quantities in fields 1 and 2, and the quote# in field 6 for MOD items. Once you've established how many orders will be created, call the applicable order creation program, passing the order nbr (including alpha suffix) in KEY.
    1. If this is a MOD item (Quote# in SHOPPINGCART.USR<6> # ""):
    • Call RPC$CONVERT_QUOTE. This program reads the existing quote from QUHDR/QUDET, loads up additional RECORD/WORK data using SOP programs, then calls QUOS4001.1.
    • Make sure that the p/o# from the shopping cart is being written to the sales order. Today, this is entered when accepting the quote in QUO4000.
    • Make sure that the request date in SOHDR<12> is correct based on work center leadtime.
    • Missing fields have been added to the checkout screens for 'Remove Gauge' (SOHDR.USR<18>) and 'Allow Overrun' (SOHDR.USR<19>). These are Y/N fields that s/b written as 1/0. Please add dictionaries to SHOPPINGCART.USR for these fields and make sure data is transferred to these existing SOHDR.USR fields. These fields are for MOD items o

b. If this is a Stock Item Order:

  • Unlike MOD items that already have most information in QUHDR/QUDET to begin the RECORD/WORK layout, you will have to build up RECORD/WORK before calling the Avante order creation program SYSS0123.1. Create a new program to do this: RPC$CREATE_STOCKORDER. You can refer to RPC$CREATEORDER (lines 939+) as a map to building RECORD/WORK and its use of Avante program calls. In addition to the calls that you see in RPC$CREATEORDER, you may also choose to call:
    • SOPP4000.12 – Acknowledgement Name/Address
    • SOPS4000.9 – Shipto Customer Info
    • SOPS0066.1 – RECORD build
    • SOPS4000.7 – Credit Checking (not sure how we are going to handle this going forward)
    • SOPS0096.1 – Tax calculation
  • Call SYSS0123.1 (from DEV.DATA BP) to create the stock order
  • Make sure to retain the 'new drop ship customer creation logic' that is currently in RPC$CREATEORDER. When creating a new CUSTMST record, make sure that Ship Via is set to "BW" and not the FOB Code from this order.
  • If named param OPERATOR # '' (this s/b c/e's OER operator code if they are checking out on behalf of the contact), then this code should be written to SOHDR<82>. If OPERATOR='', then read the default 'web operator' code from SYSCON CONFIG.SETTINGS.LAD field 8. Make sure to strip off up to the space because there is a comment on that field.
  • New updating that hasn't been defined yet:
    • Addition of Shipping Comment Upcharges for Export Pallets, Inside Delivery, Tailgate, Liftgate, etc. These will be written as Revenue Charge Codes on the order.
    • When converting an ashad MOD item, automatically move forward any sales order header internal and external comments from the original order. W/O comments should automatically be moved forward via the configurator.

3. For stock and MOD orders, update a new file: MASTERORDER.USR. Please create the file and update the dictionary/SYS3002:

  1. Key = Order Number (without suffix)
  2. <1> = multi-valued order numbers for this master order (order nbr:suffix)

At some point we may be adding add'l fields for bundling.

12/20/13 - Creating Orders from Bundling & Adding Order Comments:
Starting with your base logic above where you were creating one order for all stock items and a separate order for MOD, here are the new rules for creating orders from bundles.  Multiple orders may be created from a single bundle (ike, ship and backorder), or multiple bundles may become a single order (Stock Item riding with a MOD Item) based on the following rules: 

  1. Each MOD Item will create a separate Sales Order
  2. Stock Bundle(s) - If the bundle has a different FOB or Ship Via, a separate order will be created
  3. Stock Bundle(s) - If the bundle has different Shipping Instructions (comments), a separate order will be created
  4. Stock Bundle(s) - If the bundle has a different Bundle Ship Date, a separate order will be created
  5. It's ok for stock orders to contain line items shipping from different warehouses

 Results: 

  • Ship and backorder line items would be broken up on different orders (because they would have different bundle ship dates)
  • Split shipment line items would be on the same order like they are today (single order containing multiple warehouses)
  • Must ship todays would be split onto separate orders because they would have different dates if one bundle is a must ship today and the other isn’t

Order Creation from Bundles Logic:

Bundles are multi-valued containing sub-valued item numbers/qtys.  An item number may be in multiple bundles (ship and backorder with bundles containing different dates and qtys) but will only be listed once in field 1 and 2.  Each bundle has its own Freight Terms (FOB), Ship Via, and Shipping Instructions.

  • To determine a MOD Item: using bundle item nbr in <53,x,y>, locate the item in <1>.  The associated multi-value in <6> will contain a quote# if this is a MOD Item.  If null, then this is a stock item.  For MOD items, continue to create a single order for each MOD Item
  • For stock items, merge together any bundle that has the same info so that a single order can be created:
    • Same FOB Code (freight terms) <52,m>
    • Same Ship Via Code <51,m>
    • Same Shipping Instruction(s) (comments) <55,m,s>
    • Same Bundle Ship Date <48,m>
  • If any of the above are different for the bundle, separate it onto a different order
  • If you find stock item(s) in a bundle with a MOD Item, split out the stock item(s) onto a separate order, using the FOB, Ship Via, Ship Date, and Shipping Instructions from the MOD bundle. For freight purposes, we allow stock items to ride with a MOD item, but on the Avante side these must be on different orders.

Writing Shipping Instructions to Orders:

For each order created, write the selected shipping instructions as external order header comments:

  • SOHDR.USR<25,next> = Comment Nbr (SHOPPINGCART.USR<55,X,Y>
  • SOHDR.USR<26,next> = Comment Input1 (SHOPPINGCART.USR<56,X,Y> *** this can be null
  • SOHDR.USR<27,next> = Comment Input2 (SHOPPINGCART.USR<57,X,Y> *** this can be null
  • Write the comment text to SOHDR<68>, replacing "\" (if any) with Input1 and Input2:
    • Read COMMENTS.USR using comment# and extract text from field 3
    • If input1 # '', replace first "\" with input1
    • If input2 # "", replace second "\" with input2

 

Writing 'Ship Complete' or 'Backorder' comments to orders:

Janice is in the process of changing what is written to SHOPPINGCART.USR<49,X> for each bundle to store a 'bundle date type' that reflects 1 of 5 bundle types.  She will send you the list of each type when this is done.  Please add an external order header comment to SOHDR<68> with associated comment# to SOHDR.USR<25> for the following 2 types of bundles:

  • If bundle date type = "2", write comment# 101 (SHIP COMPLETE) - no input1 or input2
  • If bundle date type = "1", write comment# 102 (BACKORDER) - no input1 or input2

Note:  We have to change the text on these two comments to say SHIP COMPLETE and BACKORDER - this will have to be done manually on live.data when we go live with new web (can't be changed before)

12/30/13 -

Writing 'SHIP WITH ORDER' comment to orders:

 When creating multiple orders from a single bundle (only when stock item(s) are riding with a MOD Item), add the following comment number on all orders created:

  • Write the 'ship with order' comment number (116) to SOHDR.USR<25>.  Read this comment# from SYSCON CONFIG.SETTINGS.LAD<10> - make sure to strip off the note at the end
  • Add the comment text to external header comment in SOHDR<68>
  • Reference all other orders being created with the same date as Comment INPUT1, replacing the "\" in the comment text.  If more than one other order, separate by comma

Writing Work Order Comments to Configurator for Pallets:

For all MOD orders created, write all selected Pallet comments to CFBLD/CFBLD.USR for printing on the W/O Traveler (for the production dept).  This includes: 40x48 Pallet (004 005), Export Pallets (006), x Packages per Pallet (007) and Max Pallet Height (008).  First, make sure that the comment# doesn't already exist in CFBLD.USR<25> (would be the case for 'ashads').  Using the config.rev in QUDET< 39> and the build number in CFBLDHDR<1>, read CFBLD & CFBLD.USR (config.rev.build#):

  • CFBLD.USR<25,next> = Comment Nbr (SHOPPINGCART.USR<55,X,Y>
  • CFBLD.USR<26,next> = Comment Input1 (SHOPPINGCART.USR<56,X,Y> *** this can be null
  • CFBLD.USR<27,next> = Comment Input2 (SHOPPINGCART.USR<57,X,Y> *** this can be null
  • Write the comment text to CFBLD<22>, replacing "\" (if any) with Input1 and Input2:
    • Read COMMENTS.USR using comment# and extract text from field 3
    • If input1 # '', replace first "\" with input1
    • If input2 # "", replace second "\" with input2

12/31/13 -

We have changed the way in which we will carry info from Avante to the Web.  We will now write info such as Operator Code, Contact#, Request Source, etc to the Avante TXX file.  The web will know which TXX file has the info based on two new NAMED PARAMS called PORT.MARKER (this is the key to the web info record in the TXX file) and PORT.NUMBER (this will determine which TXX file the info is stored in).  Change the logic that writes the Operator Code or SB User Id to sales order files:

  • If PORT.MARKER = '', set the Operator Code = "WEB".  This will be an indication that this order is being created by a customer.   ***At this time, the UI side isn't carrying around PORT.MARKER or PORT.NUMBER so the only way you will be able to test is by using a test plan and setting these two named params.
  • If PORT.MARKER # "":
    • Execute LDLIB FIND.AVANTE.WEBINFO.  Requires one argument to be passed.
    • The record that contains the Avante info will be returned in the argument list.
    • The Operator Code (operator initials from SYSTBL OER) s/b returned in field 3
    • Anywhere that needs the operator code, use this.  If SB User ID is needed, read this from SYSTBL OER*Operator Code, field 1

 

02/04/14:

There’s been a change in plans with this bundle type.  It makes more sense for you to determine which bundles need a SHIP COMPLETE or BACKORDER comment when you are creating orders (rather than Janice trying to figure it out as bundling is happening).  So here’s the logic to complete the SHIP COMPLETE and BACKORDER comments:

Loop through the items in the bundle, comparing the bundle quantity to the qty ordered in SHOPPINGCART.USR<2>:

Bundle quantities are in field 54

 Qty Ordered are in field 2

Bundle Dates are in field 48

Future Dates are in field 58

  • If all items in the bundle have a bundle qty = qty ordered AND Bundle Date >= TODAY+3 AND Future Date = null:  add the SHIP COMPLETE comment to this order
  • If all items in the bundle have a bundle qty < qty ordered AND Bundle Date >= TODAY+3 AND Future Date = null:  add the BACKORDER comment to this order

 

 

02/05/14 - Shipping Instruction Upcharges on Order:

Some shipping instructions (comment nbrs) have an additional upcharge that will be added to the order when it is created.  These additional charges will be placed on the order as header revenue charge codes and will be applied to the invoice when it is created.  These upcharges are associated with each bundle and will be written to the SOHDR that the bundle is written to.  In all cases except for the following, a bundle = an order so this logic will be clean:

  • A split shipment (shipping same day from 2 different warehouses) will be 2 bundles combined into a single order, as long as the ship via, fob code, and shipping instructions are all the same.  In this case, we should only put a single set of comments/revenue charge codes on the order.  These upcharges should be charged on each shipment of the order (when each warehouse ships) so the invoicing routine will have to be modified to handle this.  Currently, the invoicing routine only charges the revenue charge once.
  • A stock item riding with a MOD item - in this case 2 orders are created, but since they are shipping together, only the MOD order should have the revenue charge codes

The chargeable shipping instruction comments are as follows.  These are noted in COMMENTS.USR by having something in the Small Pkg and Flat Rate fields.  Comments with no charge don't need to be placed on the order as revenue charge codes.  Janice is in the process of writing WEB.CALC.CHARGES that will pass back the comment number(s) and associated upcharge amounts for each bundle.  You can call that routine to get the info by bundle, then decide which order(s) should have revenue charge codes/amounts assigned.  The following comments are for your info only ... Janice's program should be handling the rest:

  • 105 - INSIDE DELIVERY (FLAT RATE)
  • 107 - LIFT GATE DELIVERY (FLAT RATE)
  • 106 - TAILGATE DELIVERY (FLAT RATE)
  • 137 - RESIDENTIAL DELIVERY (LTL=FLAT RATE; SMALL PKG=RATE PER LB)
  • 104 - LIMITED ACCESS DELIVERY (FLAT RATE)
  • 006 - EXPORT PALLET (RATE PER PALLET - SUM OF ALL PALLETS ON THE ORDER, REGARDLESS OF HOW MANY SHIPMENTS)
  1. Call WEB.CALC.CHARGES and extract the multi-valued comment numbers, bundle numbers, upcharge amounts, Revenue Charge Codes and Revenue SPC Codes.
  2. As you are going through each bundle to create orders, grab the upcharge comments and write to SOHDR as follows.  Make sure that if you are creating a split shipment order (two warehouses on same order because they have same date and same ship via/fob code/shipping instructions) that you should only take one set of upcharge comments.  In order for these two bundles to be on the same order their shipping instruction comments had to match exactly.  If you are creating a stock order for stock item(s) riding with a MOD item, the charges only go on the MOD order.
    1. SOHDR<205> = mv Revenue Charge Codes
    2. SOHDR<206> = mv Domestic Upcharge$
    3. SOHDR<207> = mv Domestic Upcharge$ (this is the extension, but all quantities will be "1")
    4. SOHDR<208> = null (invoice update will update this field with amount charged)
    5. SOHDR<209> = mv for curr Upcharge$ (same as domestic)
    6. SOHDR<210> = mv for curr Upcharge$ (same as domestic - this is the extension in foreign currency)
    7. SOHDR<211> = '' (invoice update will update this field with amount charged)
    8. SOHDR<212> = mv Revenue SPC Code *** This is the same for all charges based on Customer Type. Readv SPC from SYSTBL "CTP*":CUSTMST<40>,3 for billto customer.
    9. SOHDR<213> = mv Quantity (always 1)
    10. SOHDR<214> = '' (invoice update will update this field with quantity charged)
    11. SOHDR<215> - <223> = mv 0 (these are all sales tax fields - we aren't charging tax on these upcharges)
  3. Invoice Update (SOPS4013.1) needs to be changed for these flat rate upcharges that should get charged on every shipment of an order (not just once). Please make the following change:
    1. In the revenue charge code area starting at line 921, you need to set variable FC.TO.CHG = DSOHDR<209,XX> if CHGCODE<4> = one of Laddawn's special charge code types.  These types are listed in SYSCON CONFIG.SETTINGS.LAD<15>.  Currently, only code 99 is there.  If not one of Laddawn's charge types, let it continue to set FC.TO.CHG = DSOHDR<209,XX> - DSOHDR<211,XX>.  Once this variable is set correctly to the charge amount, I believe it will charge that amount every invoice.  You will see revenue charge logic elsewhere in this program, but you do not need to make this change anywhere else.
  4. Modify the Revenue Charge Code Type validation program (SYSS0064.1) to allow the entry of Laddawn charge types (listed in SYSCON CONFIG.SETTINGS.LAD<15>) anywhere that charge types 1 and 2 can be used.  You will see this validation in the internal 400 routine starting at line 72.  To test that this change worked, try to enter a sales order with Order Charges (from F10-options on header).  Use charge code 905 (this is setup with 99 as a charge code type).

02/26/14 - Export Pallet - No Wooden Slats comment on orders and work orders:

When shipping instructions comment #006 (EXPORT PALLETS) is chosen on the shipping instructions screen, we need to add an additional comment as a sales order external comment as well as a work order comment.  This new comment will indicate that wooden slats should not be used.  There will be 2 conditions:

  • If export pallets comment# exists for the bundle and the rolls are being Boxed, the comment will say: DO NOT USE WOODEN SLATS - USE CARDBOARD
  • If export pallets comment# exists for the bundle and the rolls are being Cradlepacked, the comment will say: DO NOT USE SLATS
  1. Read the 'export pallet' comment# from SYSCON CONFIG.SETTINGS.LAD<14> and locate this comment# on the bundle.
  2. If the export pallet comment is found on the bundle:
    1. If MOD Bundle (quote# is not null), read the packaging from CFORDER<13,305> using QUDET<39>.  If packaging = 'Boxed' or 'Cases', add the comment# found in CONFIG.SETTINGS.LAD<12,1>.  If packaging = 'Cradlepacked', add the comment# found in CONFIG.SETTINGS.LAD<12,2>. 
    2. If Stock Bundle, add the comment# found in CONFIG.SETTINGS.LAD<12,1> (stock items are never cradlepacked).
  3. Write the Slats comment as an external order header comment:

    • SOHDR.USR<25,next> = Slats Comment Nbr
    • SOHDR.USR<26,next> = null (Comment Input1)
    • SOHDR.USR<27,next> = null (Comment Input2)
    • Write the comment text to SOHDR<68>:
      • Read COMMENTS.USR using comment# and extract text from field 3 
  4. Using the config.rev in QUDET< 39> and the build number in CFBLDHDR<1>, read CFBLD & CFBLD.USR (config.rev.build#):
    • CFBLD.USR<25,next> = Slats Comment Nbr
    • CFBLD.USR<26,next> = null (Comment Input1)
    • CFBLD.USR<27,next> = null (Comment Input2)
    • Write the comment text to CFBLD<22>:
      • Read COMMENTS.USR using comment# and extract text from field 3

 03/02/14 - Web Discount% on Stock and MOD orders (timeline 65-3):

The web discount% should be applied to both Stock and MOD Orders (SODET<7>) under the following circumstances:

  1. A customer is checking out a cart with stock and/or MOD Items
  2. CE is checking out a cart AND they have overridden the web discount% (in cases where customer is unable to order themselves due to site issues on their end or ours)

The UI side should be handling both situations above and setting named param WEB.DISCPCT appropriately.  So you should be able to use the value in WEB.DISCPCT to apply to Stock and MOD orders.

Change create orders (RPC$SHOPPINGCART.CREATEORDER) to use the value of WEB.DISCPCT for both Stock and MOD orders.  Remove any logic that you currently have for this purpose.

Also, please fix the setting of OPER when you read from SYSCON CONFIG.SETTINGS.LAD - you must always strip off up to the first space on these SYSCON's because we usually have a comment at the end.  We have orders being created with F82=WEB   ;* Default Operator Code

 

08/08/14 - Handling RTN.FLAG issue during Order Creation for Stock & MOD Orders (timeline 6-21 flagged as Phase 1.1):

In an attempt to catch order creation problems in LDLIB RPC$CREATE_STOCKORDER AND RPC$CONVERT_QUOTE, the following changes will be implemented:

  1. Create new file CHECKOUT.CART.USR:
    1. will have same dictionary as SHOPPINGCART.USR
    2. Create VOC pointer in DEV925
    3. Add to the Rolling to LIVE wiki page that we need to create this new file in TRN.DATA and LIVE.DATA as well as creating pointers in DEV925 and LIVE925. *** Tell Janice so she can update her program that refreshes the training account.
  2. Add three new fields to CHECKOUT.CART.USR and SHOPPINGCART.USR:
    1. MASTER.ORDERNBR
    2. PLACEORDER.TIMEDATE
    3. PLACEORDER.ERROR (multi-valued in sync with bundle#)
  3. At the start of RPC$SHOPPINGCART_CREATEORDER (write after user clicks 'PLACE ORDER':
    1. Write shopping cart record to CHECKOUT.CART.USR and delete from SHOPPING.CART.USR
    2. Write the master order# into the new field in CHECKOUT.CART.USR
    3. Write the current DATE*TIME to new field in CHECKOUT.CART.USR
  4. In RPC$SHOPPINGCART_CREATEORDER, check RTN.FLAG after calling both RPC$CREATE_STOCKORDER and RPC$CONVERT_QUOTE.  If RTN.FLAG is set, don't do any further updating for that order (because it wasn't created).  Capture an error message if possible and write to the new PLACEORDER.ERROR field (multi-valued in sync with bundle# you are working on).  If you can't capture an error message, write an error flag of "1".
  5. After all bundles have gone through order creation, check for errors:
    1. If any bundles had an error, DO NOT DELETE THE CART.  Write it so that we know which bundle(s) had an error.
    2. Send an email to itapplicationsupport (using SYS9021) stating that 'create order failed for shopping cart ":cart.name.  Include contact#, billto#, and owner.id
    3. Fix cart record and re-run:
      1. Tim or IT will figure out what went wrong with the updating and get a fix in place
      2. All bundles where orders were successfully created will be removed from the cart record, leaving only the error bundle(s)
      3. Copy cart back to SHOPPINGCART.USR and DELETE from CHECKOUT.CART.USR
      4. Run through checkout again as normal.  Order(s) s/b creating against the original Master Order# (see #6 below)
  6. When assigning the Master Order# in RPC$SHOPPINGCART_CREATEORDER, check to see if you are working on a cart with an error and use the original Master Order# instead of assigning a new one:
    1. If the new Master Order# field in SHOPPINGCART.USR isn't null, use this master order# instead of assigning a new one.  Read MSTRORDHDR.USR cross-ref to get the next alpha suffix to use.