软件售后协议（通用10篇）
乙方：(软件开发商)
甲乙双方经友好协商就“海格唯美短信群发管理软件”的售后服务达成以下协议：
一、为确保软件实施顺利进行、数据的安全及乙方在售后维护时准确判断问题之所在，甲方应提供以下配合：
1、为海格唯美短信群发管理软件”所需运行环境提供良好的硬件及正版系统软件；
2、为“海格唯美短信群发管理软件”提供专机专用，并为计算机配备不间断电源；
3、做好专门用机的管理工作，避免使用来历不明的光盘和磁盘，避免没有采取充分的安全措施连接到互联网，以免感染病毒；
4、在实施过程中，安排专人配合乙方工作；
5、严格按操作规程使用软件。
二、乙方为甲方提供以下售后服务：
1、安装调试
①首次安装调试“海格唯美短信群发管理软件”免费，以后如果甲方的硬件或网络设备出现故障导致需重新安装调试“海格唯美短信群发管理软件”，乙方将酌情收取安装费用； ②甲方的硬件或网络由乙方提供或安装调试的，乙方将提供一年的保用服务，具体条款另行商定；
③甲方的硬件及网络由第三方提供且在保修期范围的，乙方一般不提供维修维护服务，而由甲方与原供应商联系保修；
④乙方不为任何盗版软件提供安装、调试服务。
2、应用培训
乙方为甲方提供每套系统一定名额的免费操作培训，超出免费名额部分收取费用，但计算机基础的培训（如：WINDOWS2003操作系统）不属免费培训的范围。
①单用户版软件，每套免费培训二人；网络版软件，每个站点免费培训一人； ②由乙方安排上课时间，甲方派员到乙方培训部门接受培训。
3、运行维护
①服务内容
A、主机、打印机等计算机设备变更带来的环境适配调整；
B、操作系统、各类汉字系统与“某管理软件”适配带来的调整工作；
C、用户机器感染病毒带来的清理病毒、修复数据、环境重新调整；
D、用户非正常操作导致数据紊乱带来的修复、调整工作。
②服务实施
A、自购买软件之日起一年内，乙方为甲方提供上述服务内容第1、2款的免费维护服务；
B、第3款的服务按每次300元的标准收费；
C、第4款的服务首次免费，以后将根据每次工作量的大小，收取300—600元维护费；③服务方式及响应时间
A、服务方式有电话、传真、E-mail、远程通讯维护、信函及上门服务；
B、乙方将先以电话的方式了解甲方需要解决的问题，并为甲方提出处理的办法，引导甲方自行解决，实在无法解决时，乙方派员上门解决；
C、自购买软件之日起一年内，在接到甲方的故障信息并确认需上门服务时，将区别缓急予以响应，处于人机并行阶段二天内到达现场，脱离手工阶段在一天内赶赴现场。
4、“海格唯美短信群发管理软件”保修与版本升级
① “海格唯美短信群发管理软件”退换保修
A、正常使用时造成“海格唯美短信群发管理软件”的损坏给予保修；不当使用造成的损坏，酌情收取一定费用；
② “海格唯美短信群发管理软件”版本升级
A、同一运行环境的软件升级，按补差价（新旧版有差价时）或收服务费的方式提供升级服务；
B、在初次设计程序中将在基础功能上免费升级3项业务功能。
三、本协议作为销售合同的附加协议，壹式两份，甲乙双方各执壹份，具有同等法律效力。
甲方：
近年来, 随着Internet不断的发展变化出现很多新的需求, 人们开发新的协议和算法来满足这些变化的需求。由于网络协议是抽象的, 很多人不易理解, 所以用仿真软件的设计与实现来了解网络协议。
本论文采用了Win Pcap驱动对链路层数据帧进行高效捕获, 并针对四种具体协议ARP、IP、TCP、UDP进行协议分析。借助Win Pcap来研究Windows平台下的网络协议仿真技术, 这不仅能促进网络嗅探系统的改进和发展, 还能促进Win Pcap本身的发展。
2 网络协议及协议仿真技术
2.1 网络协议
2.1.1 OSI七层参考模型
在网络历史的早期, 国际标准化组织 (ISO) 和国际电报电话咨询委员会 (CCITT) 共同出版了开放系统互联的七层参考模型, 即应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。每一个层次上运行着不同的协议和服务, 并且上下层之间互相配合, 完成网络数据交换的功能。然而, OSI模型仅仅是一个参考模型, 并不是实际网络中应用的模型。实际上应用最广泛的商用网络模型是TCP/IP网络参考模型, 将网络划分为四层, 每一个层次上运行着不同的协议和服务。
(1) TCP/IP参考模型
TCP/IP参考模型被称作因特网分层模型、因特网参考模型 (Intemet Reference Model) 。TCP/IP协议被设计成四个层次, 其中应用层对应于OSI模型中的应用层、会话层、表示层, 传输层和网络层分别对应OSI中的相应层, 网络接口层对应于OSI中的数据链路层和物理层。
(2) OSI模型与TCP/IP模型的比较
与OSI参考模型不同, TCP/IP协议并不完全符合OSI的七层参考模型, 如表2-3所示。TCP/IP参考模型更侧重于互联设备间的数据传送, 更注重实用性, 而不是严格的功能层次划分。OSI参考模型在解释互联网络通信原理上比较适合, TCP/IP在实用性上面比较好, 因而成为了互联网络协议的市场标准。
2.2 仿真技术简介
本文所做的网络协议仿真软件实际是嗅探器, 嗅探器是指运行在TCP/IP协议、以太网协议、IPX协议或者其他协议的网络上, 可以获取网络信息流的软件或硬件。现在的嗅探器一般都是指软件意义上的, 而不是硬件意义上的, 软件嗅探器成本要比硬件嗅探器低得多, 并且使用方便, 但是在性能方面会比硬件嗅探器差, 后者一般是用在要求比较高的地方。
2.3 Win Pcap 简介
Win Pcap是由意大利的Fulvio Risso和Loris Degioanni等人实现的应用于Win32平台数据包捕获与分析的一种驱动软件包, 并提供了在Windows操作系统下的开放源代码, 是一套高性能API封装库, 有一套标准的抓包接口专门用于网络数据包的截获, 并在其基础上增加了自定义数据包的发送能力以及针对Win32平台的扩展函数, 独立于Windows操作系统的协议栈。
3 详细设计
3.1 系统功能模块图
软件主要由以下几部分构成:
界面 (CaptureP acket Dlg类) ——减少用户等待程序启动时枯燥的时间, 同时显示作者和版本信息。
网卡选择 (Adapter Select类) ——选择主机上的某一张网卡, 并与之绑定, 设之为混杂模式, 为后续抓包的基础。
过滤规则选择 (Filter类) ——选择用户感兴趣的协议类型进行抓包, 本系统支持tcp, udp, arp, icmp.ip协议, 并且具有良好的扩展性
数据包处理和显示 (Packet Info类) ——这是整个系统的核心部分。主要的作用就是将捕获到数据包根据不同协议, 进行数据包信息的展示, 数据内容和数据包数量的显示, 界面友好。同时为了避免长时间没有数据包到达而产生的堵塞情况, 本系统使用了创建子线程来对数据包进行处理。
数据保存 (CFile类) ——将数据保存成xml形式, 以供将来查看。帮助文件 (已编译的HTML文件) —帮助第一次使用此软件的用户。
3.2 系统流程
程序在执行过程中有两个核心的工作, 一是调用Winpcap函数库实现下层抓包。二是对抓到的包文进行分析。下面分别列出两个核心过程的基本算法与相关的实现代码。
抓包算法:
第一:初始化Winpcap开发库
第二:获得当前的网卡列表, 同时要求用户指定要操作的网卡
第三:获得当前的过滤规则, 可为空
第四:调用库函数, pcap_loop, 同时并指定其回调函数, 其中其回调函数为数据包分析过程。
分析算法:
第一:得到数据包, 先将其转存到内存里, 以备以后再用。
第二:分析当前的数据包, 分析过程如下:
数据包的前14个字节 (Byte) 代表数据链路层的报文头, 其报文格式是前6Byte为目的MAC地址, 随后的6个Byte为源Mac地址, 最后的2Byte代表上层协议类型这个数据很重要, 是我们分析上层协议的依据。
第三:结束本次分析。
3.3 详细设计
3.3.1界面实现
(1) 菜单部分
菜单部分有四项:操作、设置、数据管理、帮助。
操作下面有启动、暂停、退出三个选项。
启动用于开启捕获数据包;暂停用于暂停数据包的捕获;退出用于退出本系统。
点击关闭按钮不会立即退出, 而是以系统托盘的形式在后台继续运行。
(2) 选择网卡
这个功能采用winpcap的pcap_findalldevs () 函数来实现, 它返回一个pcap_if结构的链表, 每个pcap_if结构含有一个网卡适配器的信息。其中name和description这两项分别包含了响应网卡的名称和描述, 使我们更清楚地了解网卡的信息, 增加了易读性。
(3) 过滤规则
也许我们只对一些特定的服务或者端口的通信感兴趣, 如我们想监听FTP服务的2l端口, 或Http服务的80端口, 我们把一些价值不大的包都过滤掉, 只留下我们想看到的数据包, 这就是数据包过滤模块的作用。此处使用了Win Pcap的两个关键函数pcap_compile () 和pcap_setfilter () 。
(4) 数据包捕获
上面我们已经设置好了数据的过滤规则, 然后就要使用pcap_dispatch () 或pcap_loop () 函数进行捕获。这两个函数功能非常相似, 区别是pcap_dispatch O当超时时间到了会返回, 而pcap_loop () 直到数据包被捕获才会返回。
(5) 数据包分析
数据在网络上传输的时候, 首先经过打包的一个过程, 每经过一层就会加上这一层的头部, 然后经过物理线路传输到另一台主机, 再进行解包, 即数据是先经过从上到下的一个封装, 然后再经过从下到上的一个解封的过程, 实现了计算机之间的数据交换。下面是数据包的协议解析流程。
1) 协议分析-以太网数据链路层帧类的实现
对于以太网的链路层数据帧来说, 前14个字节代表数据链路层的帧头, 其中前6个字节为目的网卡地址, 后面的6个字节为源网卡地址, 再后面的2字节代表数据帧所承载的上层协议类型, 提取出这两个字节的数据, 我们就可以得到上层协议的类型。
2) 协议分析-ARP帧类得实现
以下是ARP帧的结构, 根据ARP帧结构所涉及的类实现的部分代码如下:
3) 协议分析-IP数据包类的实现
IP头结构如表所示, 根据IP包结构所涉及的类得部分代码如下:
通过以上的设计过程实现了一个网络数据报抓包软件, 可以自定义过滤规则, 显示捕获数据包的列表, 以协议树的形式显示数据报的协议层次。
4 系统测试
测试环境的构建, 需要一台集线器, 三台计算机, 并都已经连接到因特网。网络抓包软件能完成预期的要求, 进行数据包截获、分析, 显示出分析结果。通过测试结果还可以观察到捕获模块能够实现将网络接口设置为混杂模式, 同时捕获局域网内的数据包。
5 结束语
本文主要通过对数据包的抓捕与分析机制进行研究, 参考了大量有关抓捕数据包的专业文献, 由此了解国内以及国际上主要的抓捕分析数据包的技术方法, 并通过制作一个共享环境下的的数据抓包软件的具体实现以对该机制进行深一步的了解, 实现了一个网络协议仿真软件, 经过实际测试证明可以比较高效地捕获到设定的数据包,
参考文献
[1]尤晋元, 史美林等著.Windows操作系统原理[M].北京:机械工业出版社, 2001.08.
[2]韩新宇, 章惠君.Windows下实现网络数据包捕获[J].维普资讯网.
[3]李久进.MFC深入浅出.MFC设计到MFC编程[M], 武汉:华中理工大学出版社, 1999.06.
[4]丁勇, 黄凌云, 蒋朝根.深入剖析嗅探器[J].微计算机应用, 2003.
[5]陈千, 马剑锋, 焦政.Sniffer技术在网络管理中的应用和研究[J].计算机工程与设计, 2004.
关键词：IEEE802.15.4协议；ZigBee协议；无线键盘
中图分类号：TP212.9
1 ZigBee协议及其应用
ZigBee协议底层是基于IEEE802.15.4无线通讯协议。ZigBee规范是由半导体厂商、技术供应商和其他公司组成的一家非营利工业协会（即ZigBee联盟）制定的。联盟当前的成员规模不断广大。ZigBee规范致力于利用IEEE802.15.4所提供的特性，ZigBee适用于低速率、低功耗的应用环境。
ZigBee是部署无线传感器网络的新技术。它是一种短距离、低速率无线网络技术，是一种介于无线标记技术和BlueTooth之间的技术提案。ZigBee一词源自蜜蜂群在发现花粉位置时，通过跳ZigZag形舞蹈来告知同伴，达到交换信息的目的。借此称呼一种专注于低功耗、低成本、低复杂度、低速率的近程无线网络通信技术。
2 开发环境
2.1 硬件环境
JN51XX芯片是英国Jennic公司推出的高性能、低功耗的一系列无线SoC芯片，该系列芯片完全兼容，封装与管脚也完全一样，用户能够很容易的在该系列的产品中进行平台移植。JN5139与JN5121相比较，天线的灵敏度更高，功耗更低，通讯距离更远。
2.2 开发板
JN51XX-Z01-MXX模块：JN51XX-Z01模块是基于JN51XX芯片所开发的一系列表帖形式的模块产品。该系列模块集成了所有的射频组件和无线微控制器。采用模块进行开发可以大大的减少开发人员的工作量，缩短产品的开发周期。这一系列的模块包含下列不同的型号：JN51XX-Z01-M00内置陶瓷天线；JN51XX-Z01-M01带有SMA天线连接接口；JN51XX-Z01-M02带有功率放大器和SMA天线连接接口。
开发包中的主要部件就是传感器板，之所以叫做传感器板是因为每一个板子上都集成了相应的温湿度一体传感器，这样用户就可以直接利用传感器板进行一些应用的测试和开发。传感器板包含的部件如下所介绍：
JN51XX模块板载温湿度传感器RS232接口：用于编程或者连接其他的串口设备JN51XX的I/O扩展端口，RS485 J1 CMOS Program，J2 Prog Run，J3 Flash，J4 I/O脚，J5 RS232/Program Port，J6 J1和J5编程/串口选择，J7 RS485端电阻，J8如图标注，SW1，SW2可编程按键，SW3开关（可选择外供电或电池），PWR电源指示灯LED1，LED2可编程LED。
2.3 软件环境
ZigBee开发环境有多种平台，在设计过程中主要使用了Jennic的设计平台Code：：Blocks，它是一个全功能的，开放的免费提供的IDE，基本包含代码开发编译工具、程序下载工具等基本组成部分。其中，代码编译工具包括以下几个内容：CodeBlocks IDE、Jennic Cygwin、ZigBee stack和MAC stack、Jennic Debugger Tools；第二个部分则是Jennic Flash Programmer的安装。
3 程序的设计和实现
3.1 方案设计
此方案有硬件有五部组成：传感器板子，控制器板子，一个普通的键盘，一个5V电源，连接线。可以实现通过键盘输入字符，此字符先转化为二进制代码，并打包分批传递到传感器板子，传感器板子通过无线网络发送给控制板子，控制板接受数据后将二进制代码还原为字符，并通过屏幕显示出来。
3.2 程序设计流程
根据性能和作用的分析，可以把这两块代码执行的情况用流程图表示出来。传感器板应用程序软件的主要任务有三个：读PS2总线，传输一个字节的键盘码，接受到一个确定。传感器板把键盘传过来的键码一个一个的发送给控制板，等待控制板的确认信息，收到确认后接着发送下一个键码，没有收到且超时就重新发送一次。在无线键盘应用程序的设计中最主要的是把应用程序中断和协议栈中断分开。控制板应用程序在整个流程中显得很简单，只接受到键盘码序列，然后翻译成ASCII码，再将其显示到LED，然后发送一个确认给等同的应用程序。既控制板那边就是不停检测是否收到数据，如果收到，首先判断收到的数据是否在有效范围内，如果是就翻译，然后把翻译后的数据显示在LCD显示屏上，如果不是就接收下一个数据。
3.3 程序调试、下载和运行结果
打开Jennic CodeBlocks，打开ZigBeeKEyboardEndDevice工程目录，并鼠标右键选择Build options，选择合适的调试器，用同样的方法对ZigBeeKeyboardCoord工程目录执行同样的操作，具体步骤同上。然后对ZigBeeKEyboardEndDevice工程下的PS2socket.c文件，ZKBgetKey.c文件，ZKBsensor.c文件进行编译和链接，选择ZigBeeKEyboardEndDevice后点击build按钮。编译ZigBeeKEyboardEndDevice。编译完成后您将在工程目录下找到一个 JN5121_Build目录，将在这个目录下找到ZigBeeKeyboardEndDevice.bin文件，同样的方法编译ZigBeeKeyboardCoord在JN5121_Build 目录同样也生成相应的bin文件，下载和编译应用程序如下所示：
第一步：保证工程目录存在于
第二步：使用在当地Build目录下提供的MakeFile文件，Build应用程序。或者是提供Code：：Blocks工程文件 （.cbp文件）。
第三步：下载已经生成的二进制文件到板子上。
（1）下载ZigBeeKeyboardCoord.bin 到Jennic控制板上；
（2）下载ZigBeeKeyboardEndDevice.bin到Jennic控制板上。
4 结束语
通过ZigBee技术，以其高效的传输速率、良好的可靠性、网络组建方便、节点容量大和功耗小等优点无线网络设备中扮演着重要角色。通过以上对无线键盘系统的设计得出其在当今网络通信领域的特点：首先网络连接方便，有多种网络结构可以选择：星型网络适合实现对键盘设备的几种无线控制；树型网络则适合于分级控制；网格型网络适合对无线通信系统的交错控制；其次采用编码技术，提高了信息传输过程中的可靠性；路由技术应用提高了连接的节点数量，并且保证可靠信息传输路径，延长了传输局距离、拓展了控制范围；增加了传输信道；并且保证了在每一个节点都能工作在节点模式下。
参考文献：
[1]雷亚平，沈春林，杨忠.嵌入式系统的组成、设计与调试[J].航空计算技术，2003（03）.
[2]斯托林斯.无线通信与网络[M].北京：清华大学出版社，2004：453-462.
[3] 参考文献有问题 改成：关宇东，李泽鲲.基于CAN总线的无线通信技术研究[J].工业控制计算机，2004（10）.
作者简介：吕晓芳（1983.11-），女，河南郑州人，本科，助教，学士学位，研究方向：计算机应用技术。
软件售后服务规范
一、适用范围
一、服务要求
原则：礼貌、热情、周到、细致、耐心
1、服务前充分了解用户的服务需求，并作出合理承诺；
2、服务时要切实解决用户遇到的问题，使用户能够继续无忧地使用；
3、服务后要适时检验是否真的完全解决了用户的问题；
4、任何时候不能说“不行”、“不知道”、“不清楚”；
5、任何服务人员都不得指责用户的使用方法，要委婉指出；
6、要站在客户的立场考虑问题，在服务政策允许的范围内为用户提供最大的方便；
7、在接听电话时态度要亲切、语言要温和；
8、回答用户问题时要专业、自信；
9、严禁使用不文明的用语；
10、严禁相互推托责任。
二、培训服务规范：
1、按售后服务协议中的服务承诺提供服务；
2、培训管理员在培训前，编制培训计划，做好培训环境的准备工作，准备好培训资料
和考试资料，培训期间保证培训设施的正常运行和培训的后勤保障工作，组织好培训考核，培训后做好培训工作总结；
3、培训教员根据培训计划做好培训教案和培训讲义，以保证培训的教学质量，确保用
户对培训内容的掌握程度达到85％以上，并能正确使用《YYY系统》；
4、在用户培训过程中，服务监督员要进行培训质量监督，培训工作结束后要做好培训
质量调查。
三、热线服务规范
（一）热线服务要求
1、按用户数2‰的比率设置热线服务值班岗位及电话，并将服务热线电话告知用户；
2、服务期间必须保证电话畅通，热线值班人员要做好热线值班记录（记录包括用户单
位名称、地址、电话、联系人姓名、用户反映问题的具体内容及处理情况），服务
期间不得擅自离开工作岗位；
3、热线值班人员回答用户问题时必须热情、耐心和有礼貌，不得说任何与解答问题无
关的话；
4、无法用电话解决的问题，应在接到用户电话24小时内安排服务人员上门解决；
5、服务满意度应大于85％。
（二）行为规范
1、值班经理必须提前半天安排好热线值班工作。
2、热线值班工程师必须按公司规定的上班时间准时到岗就坐，10分钟内做好值班准
备（记录单、电话、笔、环境整理）。
3、工作时间不得随意走动，未经许可不得擅自离岗。
4、电话铃响三声内必须接听。
5、完成电话咨询必须立即挂好电话，保持电话畅通。
6、每个来电必须记录。
（三）答询规范
1、接听电话第一句话“您好，XX公司，我是x x号值班员。请您留下您的联系电话
以便以后联系，记录好单位名称、地址、电话、联系人之后，“请问您有什么问题？”
2、用户叙述问题时不得打断用户叙述，未听明白时，“对不起，我没听清楚，请您再
说一遍好吗？”。
3、用户问题必须耐心、热情，不得说任何与解答问题无关的话。
4、电话中无法解决时，“对不起，您的问题电话中无法解决，我们三天内派人上门解
决可以吗？”。
5、用户同意，询问用户“这三天内您都在单位吗？”，填“现场服务请求单”。
6、用户不同意，并提出具体要求，“您的要求我记下了，我请值班经理为您安排，值
班经理安排好后，会电话通知您。”
7、用户要求当日上门和次日上门的请求，必须马上交值班经理，值班经理必须在一
个小时之内回电话。
四、上门服务规范
（一）服务要求
1、按售后服务协议中的上门服务承诺提供服务；
2、服务工程师上门服务必须挂牌；
3、服务满意度应大于85％。
(二)服务规范
1、确认：接到派发的服务单后，确认服务单上记录的问题自己能否解决，用户的地址
自己是否知晓。如不能确认，须向热线值班工程师请教或查清用户地址后方
可上门。
2、挂牌：到达用户场所，在见到联系人之前，将公司的服务标识牌挂在胸前。
3、敲门：找到用户办公室后，轻轻叩门三声，等主人允许后进门，并礼貌地询问：“对
不起，打扰了，我是XX服务工程师，请问XXX先生（女士、小姐）在吗？”
4、介绍：见到用户联系人后，证实联系人身份，介绍自己：“请问，您是XXX先生
（女士，小姐）吗？（朝前拿起服务标识牌说）我是XX服务工程师，我姓
X叫XX，很高兴能为贵单位服务。”如是多次服务的熟人，可免去自我介绍
过程、直接说：“很高兴能再次为您服务。”
5、问题：向联系人询问，核实服务单上记录的问题和故障，以及使用过程中遇到的其
它问题和疑惑，并请用户开机演示问题和故障。
6、解决：首先做好用户文档和数据备份，然后查找原因、解决问题，排除故障，解答
疑惑。如遇自己无法解决难题时，一面向用户歉意地解释问题复杂，解决需
要花费一定时间，取得用户谅解，一面即刻向热线值班经理请求支持，尽快
拟定方案，予以解决。
7、试运：请用户操作试运行软件系统，当面检验解决结果。
8、讲解：向用户详细讲解问题和故障产生的原因，排除和解决的方法，以及今后使用
中应注意的事项。
9、签字：请用户在服务单上签字认可本次服务，并对服务质量进行评价。
10、辞别：向用户告辞。规范用语为：“今后有问题，请随时打服务热线电话联系，再见。”
五、技术支持规范
1、必须以书面的方式（可传真）向XXX公司提出请求支持，服务请求要盖有服务商公
司公章和服务代表签字。
2、提出申请后必须向XXX公司确认是否收到技术支持请求（以免这些资料在传递过程
中丢失导致问题无法得到及时的解决）。
3、获得了问题的解决方案后，服务人员应立即告知用户，必要时再次上门对用户进行现
场服务，直至问题完全解决。
4、各地服务商的热线值班人员和现场服务工程师要定期整理《YYY系统》常见问题及解
原则：谁销售谁提供售后服务
甲方的义务：
一.免费为乙方培训维修人员，培训地点由甲方决定。
二.及时提供维修技术资料，将产品设计改进和采用新技术的信息通知乙方。
一.向乙方及时提供合格的维修配件。保修期内免费提供。保修期外以优惠价格供应。
二.对于乙方确实无能力解决的问题，甲方积极协调解决。
三.不定期走访乙方，听取乙方的意见和建议，对乙方反映的工作中问题及时有效处理。
一.提取合同期内实际年销售额的1%作为服务考核保证金，乙方达到甲方的服务规范，甲方向乙方返还保证金，第二年返还第一年，第三年返还第二年，以此类推。
甲方的权利：
一.有权对乙方的售后服务质量进行检查、考核。
二.有权从乙方处获得用户档案，维修台帐。
三.有权对售后服务体系和政策根据需要作出相应的调整。
乙方的权利：
一.有权对甲方当地营销代表的工作进行监督，并向甲方总部反馈。
二.甲方每年在经销商中评选优秀服务代表进行额外奖励。
乙方的义务：
一.按照甲方的“心级”服务规范以及“十免”服务承诺服务于消费者，并请用户详细填写回执联。
二.乙方须根据回执联建立用户档案，维修台帐。
三.乙方须有固定的维修调试人员，所有维修调试人员需经过专业技术培训，持有甲方或者政府有关部门认可的培训机构发放的上岗证书。
四.乙方有义务不在任何媒体上发布美安净水器的价格。
五.乙方在服务中不得使用与产品技术要求不符的零配件。
保修事项
保修期限：主机保修2年。
服务标准：美安净水机“心级”服务规范：双百，三免，四不。
双百：100%为用户安装调试，100%保证可靠的服务质量。
三免：免费为用户安装调试，并提供技术咨询;一年内免费更换零部件，终生为用户免费上门维护保养。
四不：进用户门不抽烟不吃饭;安装保养时不影响家庭环境卫生;用户要求安装维修时不超过规定时间到位;不向用户收小费;
“心级”服务六要素：信息登记，电话预约;穿上鞋套，清洁入户;按时上门，礼貌待客;耐心细致，了解情况;解决问题，示范操作;清洁机器，整理现场。
美安净水机“十免”服务承诺：免费上门安装;免费调试;免费上门设计;免费回访征求意见;免费技术咨询;免费维修保养;免费送货上门(市区内);一年内免费更换零配件。
保修凭证：在保修期内的美安净水机因产品质量问题造成的故障，用户凭产品保修卡保修，如无保修卡以产品出厂日期作为保修期计算日。
下列情况不属于保修范围，可以实行收费服务：
1.消费者因使用维护，保管不当造成损坏的。
2.由于自行运输，拆卸，移位或者非特约售后服务点拆卸造成损坏的。
3.因不可抗力，自然灾害造成损坏的。
4.无保修卡及有效发票或购买证书的。
5.保修卡不符合或者涂改的。
6.乙方在为保修期外和非保修范围的用户提供正规的收据或发票。收费标准按照《沈阳美安净水设备有限公司配件价格表》执行。
乙方：
为了配合手机提高销售，做好手机售后服务工作，甲乙双方本着平等互利、高效合作、共同发展的原则，除履行双方各自的权利和义务外，依据《手机国家三包法》，经友好协商就售后服务事宜达成以下补充协议：
本店为线下销售店面无专业检测仪器只对客户故障机外观双方进行磨损和刻痕确认，手机内部是否有问题(进水，老化，零件脱落等)人为或非人为不予检测和保障此类问题以售后工程师检测为准;
1、机身外观是否完好：
2、手机存在问题：
甲方：
乙方：
1 系统概述
即时通讯 (Instant Messaging, 简称IM) 是一个终端服务, 允许两个或多人使用网络即时地传递文字信息、文件、语音与视频交流。它是一种使人们能在网上识别在线用户并与他们交换消息的技术。本系统的设计旨在实现异地文字、文件信息的实时互通。本文基于XMPP协议的IM通讯客户端在实现了用户账号登录、显示联系人名单及状态、向联系人发送纯文本消息、向已有联系人收发文件、增加联系人等基本功能的基础上。它还可以很方便地移植到移动设备上。一个简易的即时通讯原理图如图1所示。在本文中主要研究A和B等客户端应用程序的开发, 实现客户端与IM服务器的交互, A与B则采用点对点的通信方式, 很大程度提高网络通讯的质量。
2 系统设计与实现
系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了软件系统的质量。本系统的实现使用了C++语言、Qt开发库。使用QXMPP开源库作为程序的XMPP通信模块。
(1) 系统的层次模型
客户端软件主要是能够为希望进行即时通讯的网络用户提供实时信息交换, 其主要功能模块包括:用户登录、联系人名册获取、实时状态更新、添加删除联系人、文本消息聊天和文件传输。本系统的层次模型如图2所示。
(2) 系统中各功能模块设计与实现
登录功能设计与实现
登录功能即登录验证, 是对试图登录的客户端进行权限验证。验证过程为:服务器获得客户端发送来的用户名和密码, 然后查询数据库的相应的用户列表, 如果该用户不存在或用户名与密码不匹配服务器将验证失败的结果通过XMPP协议发还给客户端, 验证过程终止。如果验证通过, 登录验证服务会将数据库中的用户状态由离线转变为在线, 然后将验证成功的结果发还给客户端。
对于客户端而言, 就是要向服务器发出连接请求, 建立连接后发送登录请求, 等待服务器回应, 发送登录所需验证信息, 再根据服务器端返回的XML流判断是否登录成功。登录功能的流程如图3所示。登录的过程中, 包括了TLS流验证、SASL握手、资源绑定和会话建立几个阶段。通过这几个阶段的完成, 保障了通信过程的安全性。
获取联系人名册功能设计与实现
获取联系人名册功能如图4所示:获取联系人名册是在用户登录到服务器上后即刻发生的服务, 此功能的目的通过查询得到自己的联系人名册列表 (包括其好友的在线状态) 。服务器以登录用户的ID为参数在好友列表查找其好友的ID。然后根据查询数据库得到的好友信息结果中的好友ID, 查询他们的在线状态然后将这些信息组合成XMPP协议的XML流返回给用户。用户将好友及其状态列表在客户端显示出来。
增删名册中的联系人功能设计与实现
添加删除名册中的联系人使用户可以随意修改自己的好友列表。客户端首先向服务器端发送需要添加或删除的用户ID, 然等待服务器端的回复信息, 确定该好友是否存在, 以便确定能否进行此项操作。进行添加操作时如果好友已存在, 或进行删除操作时好友不存在则接收相应的错误信息, 以便进行下一步的处理。图5为增删名册中的联系人功能流程图。
文本消息的收发功能设计与实现
用户想要跟某一好友进行即时消息的发送时, 首先与服务器建立连接, 查看好友是否在线, 在好友在线的情况下直接向好友发送即时讯息, 在互相发送消息的过程中不需要经过服务器的中转而是以P2P的方式在两个用户之间进行消息的传送。如果好友不在线, 则可以选择由服务器进行消息的转发。
用户成功登录后, 可以通过点击主窗口中的联系人列表, 打开聊天窗口, 对某个联系人发起对话。发送信息时, 在聊天窗口输入的信息会被传递到XML包中进行发送;收到信息时, 如果该联系人的聊天窗口已打开, 则直接显示在聊天框内, 否则会在系统托盘中提示收到了新消息。具体实现流程如图6所示。
文件传输功能设计与实现
已登录用户除了可以跟联系人发送纯文本信息外, 还可以通过XMPP的扩展协议[XEP-0096]SI File Transfer发送二进制文件。用户发送文件时, 会首先发送文件传输的请求, 联系人确认后开始进入传输, 如果联系人拒绝, 文件传输会中止。联系人向用户发送文件时也需要经过确认, 否则不会开始传输。要求用户确认文件传输时, 系统会在系统托盘区和程序主界面显示请求提示。文件传输流程如图7所示。主要功能是能够连接Google Talk的服务器, 并完成用户问即时消息的传递, 软件主要包括以下的几个主要功能:Gmail账号登陆;获取联系人名册;即时文本消息的互相传递;用户在线信息的订阅等。在完成这些基本功能的同时, 本系统还具有以下优点:
系统设计了基于中心服务器模式的P 2P客户端, 在客户端与服务器建立连接完成以后, 通讯在用户与好友间直接进行, 从而大大减轻了服务器端的负荷。
系统采用了TLS加密和SASL验证措施, 以保证通信中数据的私有性和完整性, 防止信息被篡改或窃听。
客户端设计中为了使其具有较好的可移植性和可扩展性, 采用了模块化的设计, 并且在通讯协议的设计上也不依赖与任何已有平台。
3 系统设计总结
本文的工作目标定为设计研究设计一个在3G智能平台下, 能与基于开放式即时通讯协议XMPP的Google Talk实现互通的客户端软件。所设计的即时通讯客户端
摘要：本文选择研究设计一个基于XMPP协议的P2P即时通讯客户端软件, 采用跨平台的Qt框架实现, 使其可以方便的运行在各种操作系统平台上。其可以方便地与基于XMPP协议的Google Talk通讯。本文在UbuntuLinux平台上利用C++/Qt和开源的QXmpp通信库编写了一个开放的XMPP客户端, 实现客户端用户上下线、添加好友、客户端与Google Talk的文本消息交换和二进制文件共享传输。
关键词：XMPP协议,互联网,即时通讯,P2P技术,Google Talk
参考文献
[1]W.Richard Stevens著;谢希仁, 范建华, 等译.TCP/IP详解卷1[M].北京:机械工业出版社.2 0 0 0.4
[2]吴洁.XML应用教程[M].北京:清华大学出版社.2007
[3]Jasmin Blanchette, Mark Summerfield著;闫锋欣, 曾泉人, 等译.C++GUI Qt4编程[M].北京:电子工业出版社.2 0 0 8
甲方：
乙方：
乙方购买甲方的“视频监测监控系统”，甲方作出包修一年、终身保修的售后服务承诺，经甲、乙双方协商，就售后服务达成以下协议：
1、产品售出之日起，甲方对此销售产品（设备）实行一年免费维修，终身保修的承诺，并免费帮助乙方培训1—2名系统操作人员。
2、甲方在接到乙方通知后24小时内响应，72小时到达现场，一周内修好。
3、乙方人为损坏和不正确使用损坏以及自然因素损坏设备等，则不属于保修范围，甲方有权向乙方收取一定的差旅费、手续费和配件费。
4、产品使用一年后，甲方继续为乙方售后服务，乙方应向甲方支付一定的差旅费、手续费和配件费。
5、甲方技术人员给乙方安装或售后服务时，乙方应确保甲方技术人员的声明和财产安全。如发生甲方技术服务人员人身伤害事故或财产损失等，由乙方负全部责任。
6、以上协议经双方签字、盖章之日起生效，双方各执一份。
甲方：乙方：
法人代表：法人代表：
委托代理：委托代理：
项目联系人：
联系方式:
通讯地址：
电 话： 传 真：
电子信箱：
乙方：
项目联系人：
联系方式 ：
通讯地址：
电 话： 传 真：
电子信箱：
根据《中华人民共和国合同法》及相关法律、法规，甲乙双方协商一致，就甲方向乙方购买乙方的《__》达成以下条款，以求共同恪守：
一、合同概要:
甲方向乙方购买乙方的一套《__》使用权(以下简称“__”)，来为甲方的 提供服务。
二、甲方的权利和责任:
1、甲方同意向乙方购买一套“__”使用权，来为甲方的 提供服务。
2、甲方同意不得转卖“__”的使用权;
3、甲方同意只在本合同约定的期限内使用“__×”;如果本合同到期或者失效，甲方需要在一周内移除 “__”代码;
4、甲方不得将购买的“__”使用权以任何的形式转让、出租和(或)赠送及其他任何形式给第三方;
三、乙方的权利和责任:
1、乙方拥有“__”的所有版权及相关知识产权;
2、乙方同意向甲方提供必要和合理的服务;
3、乙方同意协助甲方安装和调试“__”;
4、在甲方付清软件购买款项后，乙方为甲方开通“__”约定的使用功能。
四、版本和功能:
甲方向乙方购买一套“__”使用权。功能约定如下：
1、最大同时在线的管理人员数量为 人;
2、免费升级;
3、使用期限：从 年 月 日 至 年 月 日;
4、甲方在使用“__”的过程中的产生的数据在服务器上仅保留365天。
五、费用:
甲方向乙方每年以现金、转账、电汇、支票等方式支付一次一年的“__”托管使用费用，此即为本合同总金额。费用支付后乙方向甲方提供服务。具体合同金额及汇款信息见合同签订附页。
六、技术支持和售后服务定义:
1、乙方保障“__”服务器的正常工作。
2、如出现以下情况，甲方不得追究乙方的责任：
A、“__”服务器所在的机房停电或突发事故;
B、“__”升级过程中导致服务中断;
C、“__”服务器重新启动时或者维护时服务中断;
如因以上问题导致客户8小时以上无法使用“__”(非客户自身原因)，乙方将为甲方的服务期限进行顺延处理(顺延时间与本次无法使用的时间一致)
3、因软件服务中断导致软件用户自身业务的经济损失，乙方不承担任何责任。
七、保密条款
1、合同任何一方对在合作过程中所获知的对方的商业秘密等均负有保密义务，未经对方书面许可，任何一方不得将其泄露给第三方，否则应承担违约责任并赔偿损失;
2、合同终止之后，各方仍需遵守本合同之保密条款，履行其所承诺的保密义务，直到对方同意其解除此项义务为止。
八、法律效力:
1、变更本协议条款中的任何内容，需有双方签字的正式书面文件。
2、甲方在使用“__”使用期限期满后，本合同自行终止，到期后可以续签。
3、本合同经双方签字盖章即生效。本协议一式两份，甲乙双方各执一份，未尽事宜双方协商解决。
甲方(公章)：_________ 乙方(公章)：_________
法定代表人(签字)：_________ 法定代表人(签字)：_________
_________年____月____日 _________年____月____日
ARINC615协议[1]定义了一种机载计算机高速数据加载器,基于ARINC429总线完成对机载计算机的数据上传和下载功能。在以AFDX[2]网络为主干网络的航电网络中,以AFDX网络为核心,外围通过远程数据接口单元挂载ARINC429总线设备,航电网络加载器一般是基于AFDX通信来完成航电网络数据的加卸载功能,导致对ARINC429总线设备的加载需要通过基于AFDX通信的网络加载器来完成,针对此问题,本文将ARINC615协议加载端移植到基于AFDX通信的航电网络加载器上,提出一种基于AFDX的跨总线ARINC615协议软件设计实现方法,并设计应用层的加卸载方案,实现了航电网络加载器和目标机的数据文件加卸载功能。
1 ARINC615协议概述�
ARINC615协议是基于ARINC429总线的数据加卸载协议,其加载端和目标机均需支持ARINC429基本数据通信,在ARINC429基本通信的基础上,ARINC615协议定义了一系列的规则,通过握手-响应-确认机制来完成数据在加载端和目标机的传输过程。
1.1 基本协议层交互定义
429总线上传输的数据单元长度为32位,因此ARINC615协议的命令及数据传输均是基于32位的数据包进行。ARINC615协议的数据通信的交互命令定义如表1所示。
如表1所示,ARINC615协议交互命令分为初始字命令、中间字命令和结束字命令三种。三种命令数据格式中第32位为奇偶校验位,第1到8位为429的Label号标识,第30和31位区别三种类型的命令。初始字命令用于数据传输前的命令交互握手,其数据格式中第23位到第29位标识不同类型的初始字命令,RTS命令用于发送请求命令,其9到15位标识本次发送请求要发送的记录个数;CTS命令用于对RTS命令的响应,其9到15位标识可接收的记录个数;DF命令表明开始数据传输,其16到22位标识当前传输的记录序号,9到15位标识当前传输的记录的总字节数;ACK和NAK命令标识对数据接收的确认,其16到22位均标识其确认的记录序号;SYN命令用于加载端和目标机的同步;HDR命令通过第16到22位的命令字段来发起包括读数据块、写数据块、加载完成、进入自动模式等命令;加载端发送POL命令来探测有可能的自动下载操作。中间字主要用于传输数据,DATA命令中第8到24位为数据段,包含两个字节的数据信息。结束字用于每个记录传输完成后的数据校验和传输。
表1 ARINC615协议数据交互命令(参见下页)
1.2 配置文件定义�
在ARINC615协议的加载端,需定义配置文件CONFIG.LDR,用于对加载端上传和下载操作进行定义和描述。CONFIG.LDR文件中配置参数格式描述如下:
parameter_id=parameter_value
其中parameter_id为一个变长字段,包含了要定义的配置参数名,配置参数名中可包含一个数字'n',标识所定义的参数为第几条总线参数,n的范围为1～8,如B1P用于定义第一条总线的优先级。parameter_value为具体的配置参数值,对于有多个参数值的配置参数,参数值之间用逗号隔开。
CONFIG.LDR配置文件主要配置参数的定义及其含义如表2所示。
表2中给出了CONFIG.LDR文件中主要参数的定义,包括总线属性定义、总线优先级定义、总线发送文件定义及总线接收文件定义等。
1.3 协议功能定义
ARINC615协议将要上传或下载的文件分为多个块(block),每个块大小由CONFIG.LDR中BnT属性定义,默认每个块大小为1024字节,在每次数据传输过程中,将块又细分为记录(record),对于上传操作,每个记录大小范围为0～252字节,对于下载操作,每个记录大小为0～254字节,每次数据交互以一个记录为单位进行。
协议的功能基于基本交互命令实现,协议的主要功能定义如下:
(1)通信初始化。加载器读取配置文件的内容,根据配置文件的信息选择上传或下载操作,发送初始化命令,收到目标机响应后,进入上传或下载操作;
(2)上传操作。上传操作分为通信初始化后直接上传、控制模式文件选择上传、控制模式下上传。
通信初始化后直接上传:总线配置文件的上传文件是目标机端需要的,在通信初始化完成后,直接向目标机上传文件。
控制模式文件选择上传:总线配置文件的上传文件不是目标机端需要的(或者未定义上传文件),目标机端发起控制模式命令,加载器进入控制模式。在控制模式下,目标机需要在指定文件后进入直接上传模式,加载器向目标机上传文件。
控制模式下上传:总线配置文件的上传文件不是目标机端需要的(或者未定义上传文件),目标机端发起控制模式命令,加载器进入控制模式。在控制模式下,目标机控制整个数据传输过程,目标机指定需要的文件,从加载器读取数据。
(3)下载操作。下载操作分为通信初始化后直接下载、控制模式文件选择下载、控制模式下下载。
通信初始化后直接下载:总线配置文件的下载文件是目标机端需要的,在通信初始化完成后,加载器等待目标机传输文件,当目标机准备好后,向加载器发送数据文件。
控制模式文件选择下载:总线配置初始化为自动上传或自动下载,目标机发送控制模式命令,进入控制模式,在控制模式下,目标机打开文件进行写操作后,转入直接下载模式,向加载器发送数据文件。
控制模式下下载:总线配置初始化为自动上传或自动下载,目标机发送控制模式命令,进入控制模式。在控制模式下,目标机控制整个数据传输过程,打开文件后向加载器写入文件数据。
2 跨总线加载方案设计
跨总线加载方案定义了一种基于AFDX的加卸载方法,其加载端基于AFDX通信协议运行,目标机基于ARINC429协议运行。
跨总线网络协议栈如图1所示。加载器与目标机端之间通过数据网关连接,数据网关完成ARINC664协议到ARINC429协议的转换。加载器端底层基于ARINC664总线,通过协议映射层完成AFDX数据到ARINC429数据的转换,以支持ARINC615协议加载端的运行。数据网关实现了ARINC664协议和ARINC429协议的双向转换工作,定义了数据转换规则。在数据网关上需维护(AFDX发送端口号,AFDX接收端口号,429设备标号)的映射关系表。当数据网关收到一个AFDX数据包时,利用AFDX接收端口号查找映射关系表,可以取得这个AFDX数据的目的429设备,数据网关解析AFDX数据包,进行相应的转换为429数据,发往目的429设备。而当数据网关设备接收到一个429数据包时,利用429设备标识查找映射关系表,获得429设备对应的AFDX发送端口号,然后对数据进行转换封装为AFDX数据帧,通过查找到的AFDX发送端口号发送出去。
由于ARINC615交互数据及429设备数据均为32位长度,而对于AFDX网络来说,每次传输数据只传输32位有效数据,对网络带宽会造成较大浪费,因此,在数据网关设备的协议转换层需进行数据融合,即数据网关能够将多个32位429数据封装到一个AFDX数据包中进行传输,同时在接收到一个包含多个32位ARINC615协议数据的AFDX数据包时,能够将每个ARINC615协议数据解析出来,依次拆分为32位ARINC429协议数据发送出去。
3 基于有限状态机的协议实现�
在ARINC615协议的上传和下载过程中,每一时刻加载端和目标机都处于一个特定的状态,而且所有可能出现的状态是确定的,定义软件开始运行时状态为初始状态,当有输入事件时,软件整个过程按照状态机开始跳转运行,直至运行至终止状态。
因此,可以根据ARINC615协议,抽象出加载端及目标机软件运行的各个状态类型,按照表3所示的状态转移表整理协议中所有的状态及其转移流程。
表3中,当前状态指当前软件所处的状态,在输入事件的情况下,调用处理函数后运行至下一状态。一个当前状态可对应多个输入事件,分别调用对应的处理函数,进入不同的下一状态。按照表3建立ARINC615协议的状态转移表,并按照功能实现各状态在输入事件下的处理函数,软件即可依照状态转移表运行,状态机运行的接口定义如下:
其中init_state为状态机起始运行的状态,init_event为状态机初始的输入事件,exit_state为状态机的结束状态,exit_event为状态机的退出事件,session和parameter两个参数记录了状态机运行过程中的会话和参数信息。通过StateMachine接口,可完成ARINC615协议的自动运行。
4 基于ARINC615协议的应用软件
ARINC615协议定义了文件数据传输的过程,基于ARINC615协议,设计应用层软件,实现一种工程上可靠、实用的文件上传和下载功能。在应用软件中,主要的功能包括:
(1)加载端和目标机端要传输的文件名的获取,保证加载端和目标机端都能够知道要对方上传和下载的文件的文件名;
(2)文件传输最后填充字节的识别和剔除,避免由于ARINC615协议数据传输过程中为了字节对齐而填充的数据对文件正确性的影响。
应用层软件的加载端和目标机端的工作流程如图2所示。
如图2所示,在加载端,定义了CONFIG.LDR文件,在该文件中,定义加载端发起自动上传操作,且第n条总线上要上传的文件名为FileList[n],其中n代表第n条总线,其取值范围为1～8,在FlieList文件中定义了加载端要上传和要下载的文件名称,及该文件对应的属性(上传或者下载)。软件开始运行后,由加载端解析CONFIG.LDR配置文件,发起自动上传操作,加载端和目标机端进入自动上传模式,由加载端将约定好的FileList[n]文件传输至目标机端,文件传输完成后,加载端等待目标机端的控制模式命令。目标端在接收到File List文件后,解析该文件,获取加载端要上传的文件名及要下载的文件名后,发起控制模式命令,加载端和目标机端均进入控制模式。在控制模式下,由目标机端控制文件的上传和下载,目标机根据解析的要上传和下载的文件名,对于要上传的文件,目标机端发起读操作,从目标机端读取上传文件;对于加载端要下载的文件名,目标机端发起写操作,向加载端写入数据文件。对于定义了多条总线的CONFIG.LDR配置文件,加载端按照总线优先级依次进行如图2所示的文件传输流程,直至所有总线上定义的数据文件均传输完成。
ARINC615协议中每次数据传输的一个DATA命令传输两个字节的数据,在协议中规定了当文件传输最后仅剩一个字节时,需填充一个字节,然后进行数据传输,这就导致了在文件传输过程中,对于要上传或下载的奇数字节文件,在文件传输完成后,会出现多一个填充字节的问题。在应用软件设计中,利用DATA命令中协议未定义的第25位作为判断标识位,在正常的文件传输下,该位标识为0,当出现数据填充后,将该位置标识为1,在文件接收端,如果发现该位为1,则能够确认接收到的数据中有一个字节的填充,这样可以将填充的字节剔除,从而保证了文件的正确性。
5 结语
文章介绍了AIRNC615的基本原理,提出了一种基于AIRNC615的跨总线加载结构,采用有穷状态机的方法实现了AIRNC615协议的功能,从工程应用的角度,设计并实现了基于AIRNC615协议的应用软件,保证了文件传输的有效性和可靠性。
摘要：ARINC615协议定义了一种基于ARINC429总线的数据加卸载方法,在以AFDX网络为核心的航电网络中,数据加载器一般为基于AFDX通信的端系统设备,为了完成航电网络加载器对ARINC429总线设备的加载,文章提出了一种基于AFDX的跨总线加载结构,采用有穷状态机的方法实现了ARINC615协议的功能,设计并实现了基于ARINC615协议的应用软件,保证了文件传输的有效性和可靠性。
关键词：ARINC615协议,AFDX协议,文件传输,软件
参考文献
[1]Arinc Report 615-4:Airborne computer high speeddata loader[S].ARINC Airlines ElectronicEngineering Committee,2002.
【软件售后协议】推荐阅读：
软件售后服务承诺05-31
软件测试保密协议06-29
软件开发员工保密协议07-18
软件地区总代理协议书05-29
售后发言稿05-29
售后管理及制度06-28
售后人员工资政策07-04
汽车售后整改报告07-14
空调售后整改报告09-15
淘宝双十一售后总结05-24
