Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Script BASIC / ScriptBasic Core Windows 32 bit Install
« Last post by John Spikowski on May 25, 2021, 02:34:41 AM »
The attached ScriptBasic Windows install is a core distribution with the essential extension modules included. A User Guide is included as a Windows .CHM help file. The following posts to this thread are examples that are also included with the install program.



Core Extension Modules
  • COM/OLE Automation
  • cURL Library
  • ODBC
  • SQLite
  • Dynamic FFI
  • Asynchronous / Synchronous Threading

ScriptBasic User Guide

ScriptBasic SandBox Repository

ScriptBasic Download Attached
22
Open Forum / Re: WELCOME
« Last post by Root on October 04, 2018, 09:36:10 PM »
Thanks for joining us gracie!

Are you interested in COM/OLE automation as an open API interface to 100 internals?

Have you install Script BASIC yet?

I hope more Sage consultants join us to provide customers with affordable enhancements.
23
Open Forum / Re: WELCOME
« Last post by gracie on October 03, 2018, 01:41:03 PM »
I have a feeling this will be a quiet site, but FWIW, it's already been helpful to me. I'm an experienced developer but new to Sage, so it's great to see some documentation and examples.
24
Open Forum / Re: OrderTrack - A sales order/shipping management solution
« Last post by John Spikowski on May 29, 2018, 06:55:32 PM »
Wow!

Amazing job and an excellent example of what can be done using Sage's 100 / MAS90 open API (BOI) interface and industry standard tools.
25
Open Forum / OrderTrack - A sales order/shipping management solution
« Last post by mkaney on May 29, 2018, 12:10:41 AM »
So let me just start with the basics.  The system was designed to coordinate and automate the business processes between sales and shipping.  It begins in PostgreSQL, where I have the mirrored Sage 100 data, as well as some tables that store additional information that are linked to the keys in the Sage 100 data, e.g. salesorderno.   The interface was created entirely in Microsoft Access, because Access has some very special features.  First, it is very easy to create bound forms and datagrids.  Second, it is very easy to link to a variety of database sources and use them together very easily.  In fact I hardly even use the native database features of Access at all.  Most people's impression of Access applications comes from seeing some really poorly designed GUIs, and I cannot blame them for being skeptical.  However, the potential of Access is astounding.   I created some classes in VBA to deal with the Sage 100 BOI, and that's how I update orders directly from OrderTrack

I have added a screenshot of OrderTrack to this post, though I don't appear to be able to embed an image unless it is at a url.  I will get into more of the details about how OrderTrack works in a followup to this post tomorrow.  For now here is a short list of some of the features:

- Allows sales manager to review and approve orders that have been entered into Sage 100.  Accepting an order takes the order off hold, sets its priority (a UDF field), and calculates and updates the shipping date. 
- Allocates available inventory to accepted orders.  Also allows overriding allocation and a tool for staging orders (which is manual allocation that will reserve inventory for those orders)
- Provides an interface for sales to see ALL open orders, where they are in the queue, whether they meet various criteria for shipping (e.g. some orders for international customers are not selected for shipment until the total value of the allocate inventory for ALL of their open orders exceeds a certain threshhold, to save shipping costs.  Also allows drill down so they can see what items are short.
- Includes tools that provide information on expected availability of items not allcoated
- Provides an interface for shipping to work directly from.  Allows communication between shipping and sales, preventing constant phone calls and questions that reduce productivity.
- Prints barcoded picking slips

There are ton of other features, but hopefully that short rundown gives folks a better idea of what it does.
26
Open Forum / Re: WELCOME
« Last post by mkaney on May 28, 2018, 11:48:35 PM »
I do believe there are a growing number of us out there.  There is a lot of potential to expand the capabilities of Sage 100 and make it useful for more businesses.  With a little creative tinkering, it has the potential to provide an enormous amount of capability for a for a fraction of the cost of some of the larger ERP players.  Sage's insistence on keeping information locked down and pandering to their thoroughly untalented Master Developers seriously limits that potential, though.  They are shooting themselves in the foot with this approach.  With the subscription model play, I think they may actually be digging Sage 100 a grave.

That being said, the limitations of Sage 100 have created a lot of opportunity for me. By figuring out ways around these limitations I have provided a lot of value as an employee of the companies that I've worked for.  My ability to sync business processes with the ERP has allowed me to grow from "database manager" at my current employer into the corporate controller.   

But my work would have been a heck of a lot more enjoyable if there was a community with which I could have shared ideas and challenges with.  I think this might be an opportunity to grow such a community.  You have a great domain name, your approach is one of openness, and you also have brought the added value of your Script BASIC to the table.  In the next post I'll introduce one of my front-end systems for Sage 100, and then in the open source forum I'll post a message with some details on my program that mirrors the Sage 100 data in PostgreSQL.   I wrote (VB.NET) and compiled it using SharpDevelop, an opensource clone of Visual Studio and of course it is designed to work with PostgreSQL which is also open source.
27
Open Forum / Re: WELCOME
« Last post by John Spikowski on May 28, 2018, 09:27:40 AM »
Thanks for joining and introducing yourself. It was getting pretty lonely here and I was beginning to wonder if my efforts to take advantage of Sage's open API interfaces was justified. The biggest problem I've found is Sage Master Developers have established a price fixing buddy network over the years and don't want anyone messing in their realm with BOI scripting and upsetting the apple cart..

One of the big surprises I ran into doing this is PHP is a great BOI interface if extending 100 to a browser UI interface.

28
Open Forum / Re: WELCOME
« Last post by mkaney on May 28, 2018, 09:14:31 AM »
Not too much activity yet but I am excited to find this site.  I have been working since Sage 100/200 since 1999, when I became a consultant for a CPA firm that was a Sage Reseller.  It was my first introduction into the closed, proprietary world of Sage and immediately inspired me to find creative solutions to challenges facing Sage 100 (then MAS 90) users that used more open technologies.  The life of a reseller was not for me though, and I eventually took my newly acquired skills into IT and accounting positions working directly for companies using Sage 100.   Since then I have written a number of useful tools that implement business processes and better user interfaces on top of Sage 100.  I look forward to sharing some of my work and collaborating with others here.
29
Script BASIC / BOI ACL
« Last post by John Spikowski on January 30, 2018, 04:28:23 PM »
The following is an example of the Sage 100 BOI API instantiating a ACL AR_Customer lookup.

Code: Script BASIC
  1. ' BOI - ACL AR_Customer
  2.  
  3. IMPORT BOI.sbi
  4.  
  5. oscript = BOI::CREATE(:SET, "ProvideX.Script")
  6. BOI::CBN oScript, "Init", :CALL, "C:\\Sage\\Sage 100 Standard\\MAS90\\Home"
  7. osession = BOI::CBN(oscript, "NewObject", :SET, "SY_Session")
  8. BOI::CBN osession, "nSetUser", :CALL, "JRS", "MyPassword"
  9. BOI::CBN osession, "nsetcompany", :CALL, "ABC"
  10. BOI::CBN osession, "nSetModule", :CALL, "A/R"
  11. mdate = BOI::CBN(osession, "sModuleDate", :GET)
  12. BOI::CBN osession, "nSetDate", :CALL, "A/R", mdate
  13. BOI::CBN(osession, "nSetProgram", :CALL, BOI::CBN(osession, "nLookupTask", :CALL, "AR_Customer_ui"))
  14. ocust = BOI::CBN(oscript, "NewObject", :SET, "AR_Customer_bus", osession)
  15. oui = BOI::CBN(oscript, "NewObject", :SET, "AR_Customer_ui", osession)
  16. BOI::CBN(oui, "nInvokeLookup", :CALL, "AR_Customer", retval)
  17.  
  18. PRINT retval,"\n"
  19.  
  20. BOI::CBN ocust, "DropObject"
  21. BOI::CBN osession, "DropObject"
  22. BOI::RELEASE oscript
  23.  


C:\ScriptBASIC\BOI>scriba acltest.sb
01SAGE
C:\ScriptBASIC\BOI>

30
Documentation / ProvideX.Script (PVXCOM)
« Last post by John Spikowski on November 15, 2017, 09:24:21 PM »
Six methods are available for use with ProvideX.Script:
  • Init(path) - Called before accessing any other method in the script engine in order to set the working directory for the server and perform binding to the PxPlus dll layer. The path should be set to the desired working directory or blank to indicate the current directory. (In most cases, the current directory will be the system directory.)

  • Execute(stmt) - Invoked to execute any PxPlus command statement.

  • Evaluate(expr) - Evaluates and returns the expression provided and returns its value as a variant. (It can be used as either a numeric or string.)

  • Run(prog) - Runs the specified program. This method does not return until the program ends.

  • Reset( ) - Closes all local files and clears variables (executes a BEGIN).

  • NewObject(name, params ...) - Creates a new object of the specified name and returns an object reference (see Additional Properties below).
Three properties are also associated with the interface:

Instance - Returns a unique string to identify the server during its lifetime.

State - Returns the state of the server: 0 (zero) - Uninitialized; 1 - Initialized.

Parameter - Read/write property used to access the specified PxPlus parameter.


Additional Properties

To create an object within the OLE Server, the method NewObject is used. It returns an object identifier to the ProvideX object that was created. Along with the ProvideX defined properties and methods, the OLE server adds the following properties:

Instance - Returns a unique identifier of the ProvideX.Script object that was used to create the automation object. This is important because the automation object cannot be passed to another ProvideX.Script server.

ScriptObject - Returns the parent ProvideX.Script object.

CmdHandle - Returns the ProvideX handle to which the automation object is tied.


Naming Conventions

Be aware that COM is generally data-type insensitive; i.e. it does not support the $ or % suffix. This can cause a problem when dealing with ProvideX via the OLE Server, since in ProvideX, you can have Cust_no$ and Cust_no (as two unique data variables).

To avoid this issue, the OLE Server mandates that all property references indicate the property type in the first character of the property name:

s - For string variables

n - For numeric variables

i - For integer variables

o - For object variables (required)


Example:
Code: [Select]
Cat$ becomes sCat, Dog becomes nDog , and Pig% becomes iPig.

These prefixes are only for use by programs using the OLE Server, not by the ProvideX application itself. This means that the property Cust_no$ in ProvideX would be sCust_no when referenced by the OLE Server, and the property Cust_no in PxPlus would be nCust_no, etc.

Note:  Do not use these prefixes in the property definition. Use of the o prefix allows the specification of properties and/or methods within ProvideX objects to be declared themselves as objects.

 
Pages: 1 2 [3] 4 5 ... 10